Re: Applying patches from mailing list

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.