On Tue 16/Jan/2024 19:24:29 +0100 Murray S. Kucherawy wrote:
On Tue, Jan 16, 2024 at 2:03 AM Alessandro Vesely <ves...@tana.it> wrote:
On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote:
It appears that Scott Kitterman <skl...@kitterman.com> said:
I don't think that's sensible at all. It's not the place of a signing
filter to modify the message.
A signing filter, as part of an MSA _has to_ modify the message in order
to enhance the possibility that it is transmitted correctly. Besides
usual changes belonging to the core MSA, such as setting Date:, a signing
filter shall take care of signature breaking cases, such as lines
beginning with "from ". >
I also disagree. A signing filter (or an MSA, for that matter) can also
decline to sign a message that fails to meet certain criteria like, say,
RFC5322. I would contend that this is the right action, since what we're
doing here is securing the message, and a filter in that position shouldn't
be presuming what the author meant to say.
Since email format allows multi-valued From:, its meaning is straightforward.
As John says, it can also be the result of some kind of mistake. Yet,
presuming that a properly formatted input is correct is not such an elaborate
conjecture to put the output in jeopardy.
As I recall, with milter in particular, the MTA will add a missing Date
field, which the filter never actually sees and thus cannot sign. The
filter only sees the message exactly as it was presented to the MTA. As a
result, if the message is signed, Date is not, and any verifier that thinks
it ought to be will consider the signature invalid.
That can well be considered a flaw of the Milter architecture. To wit, I named
my filter "zdkimfilter" because Courier applies filters in lexicographic order,
whereby each filter can see any changes applied by the previous ones, as in a
pipeline.
There's another thread of concern here: For a signature to survive transit,
the signing filter needs to anticipate any rewrites that will happen to the
message. If "Date" is missing and it gets added, that's one thing; if
"From" is rewritten outbound by the MTA (which is not uncommon), say from
$HOST.$DOMAIN to just $DOMAIN, the signature may be immediately invalidated.
Yes, these are architectural problems that local implementations have to solve.
There's a lot of complexity here that I think filter authors would just as
soon leave to the MTA/MSA.
If the MSA handled DKIM natively, you wouldn't have to insert a filter to do it.
A use case is when submitting co-authored articles or notes. Yes, it is
rare to type a message four hands, but it can happen, and banning the
possibility to correctly identify the authors is harsh. >>
Thinking twice, saving the original multi-value to Author: is not enough
to have replies reach every author. Better also use Reply-To:.
This strikes me as something that needs to be codified outside of DMARC,
rather than by it.
Agreed. The problem needs to be handled on DKIM signing, one layer below.
However, since DMARC bears the blame of banning multi-valued From:, it is
appropriate for it to say something about the consequences and possible
workarounds.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
