Crystal Kolipe via Mutt-dev wrote in <[email protected]>: |On Tue, Feb 17, 2026 at 02:25:31AM +0100, Steffen Nurpmeso wrote: |> Crystal Kolipe via Mutt-dev wrote in |> <[email protected]>: |> ... |> |> (murderer style citation skipped.) | |I have, and always have, posted using the standard and widely-accepted \ |quoting |format of '> ' at the beginning of each line. | |Please do not imply otherwise. | |The ridiculous citation style was introduced by _you_ in a previous \ |message to |this thread, which _I_ then quoted using '> '.
I meant truncation of (belonging) context. (To mention that my "citation style" starts with whitespace, which is the oldest email "citation style" that ever existed.) |>|[.] although that seems like a niche case. |> |> Must be said though that dkim is per-domain, so you seem to |> support "the other approach" that seems to have the desire to add |> support for forbidding "explosion" meaning mailing-list targets? | |I have no idea what you are referring to by, "the other approach". | |If this matters, and you want a response about it, please explain what you |mean. It seems to me we talk by each other thus. I was talking about the development path that DKIM has taken. (Aka is currently taking.) |> I for one am totally against this, the "iterated DKIM" should not |> introduce anything like that. It should be a cryptographic helper |> of SMTP that allows to link a message to a domain, no tracking, no |> flow control, nothing. Only being able to crypt-verify, however, |> up to the original sender, which is new (anyway). | |All I said was: | |* Signing a non-existant field with DKIM is permitted by RFC 6376. | (You implied that it was not, or that it was discouraged.) I have never said something like this -- quite the opposite!! |* The effect of doing that is that DKIM verifiers will fail the message if | that header is later added, (unless it is added with null content). Exactly. I said ||Anyhow posters can cause verifier hiccups unless the used ||mailing-list software is smart enough for "graceful" decisions, what you stripped off. |* This _could_ be used by senders to avoid the following situation: The given example that you responded to was a direct post to a mailing-list. So how come you to, and what is the intention of your carefully layed out construct below thus? And also to say again that DKIM is about domains, not individual senders? | * Compose a private message, with visible To: and Cc: which do NOT \ | include | any public or private lists, just individual accounts, with the \ | intention | that the message was delivered only to those accounts, and not | bounce-forwarded, (re-mailed to a public list with the original visible | From: header). The described message replay is addressed as such by other means by "the next" aka iterated DKIM. | * One of the recipients does exactly that, re-sends the message to \ | a public | list with the original From: intact. | | * This will pass SPF validation on the listserver, (as long as the \ | sending | MX has a valid SPF record for it's _envelope_ from). It will also pass | DKIM if and only if the original message body has not been modified and | neither have any of the signed headers. | | * Just because the list server address does not appear in the visible To: | or Cc: headers does not matter, it could have been Bcc'ed. | |There is not much, if anything, that the original sender can do to \ |avoid the |message content being re-posted to a public mailing list. | |However, they _can_ take steps to ensure that the message, (with the \ |original |and unmodified From: header, fails DKIM verification for anyone receiving \ |it |via a list that inserts a known header. (wow what a construct.) |The mechanism to do that is to sign the non-existant header field at \ |the time |of sending. | |What I described is just regular use of DKIM, albeit a use that most \ |people do |not care about, or have a use for. Hence, 'a niche case'. | |It does not create any incompatibility, nor is it any kind of "other \ |approach" |whatever that means. | |It _might_ cause problems if people are signing non-existant headers \ |for mail |that is intended for public lists. But in that case, the user's system is |mis-configured, and they are responsible for correcting it. And again to note that replay as such is addressed by other means by the next DKIM, whereas "explosion" how they call it can be disabled as such. Which would mean, if i understand this right (i have not read it in full for concrete reasons for quite some time), that a domain can disable mailing-list posts for all what you call senders. Given that thing practically adds cryptographically verifiable tracking facilities, again as i understand it, i do not follow your careful construct at all. --End of <[email protected]> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
