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 '> '.
> |[.] 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.
> 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.)
* 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).
* This _could_ be used by senders to avoid the following situation:
* 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).
* 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.
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.
