On 3/19/23 11:57 AM, Wei Chuang wrote:
On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins <la...@wordtothewise.com>
wrote:
...
One of the panel members has shared the following from what he
said at the session:
* RFC 6376 itself says "x=" is not a viable mechanism to deal with
replay.
* There may only be a best practices solution, and not a protocol
solution.
* DKIM has since the beginning kept itself completely separate
from the message transport. Several of the proposed solutions
(including mine) take leaps of varying sizes into the realm of
DKIM knowing something about the transport; the lightweight ones
connect the message to the envelope somehow, and the more
heavyweight ones mean DKIM filters have to learn about MXes and
whatnot. We have to be absolutely certain that we want to break
that wall if we go this way, because once we do, there will be no
turning back.
Agreed for the most part. While we can get mileage with the existing
RFC6376 based tools such as header oversigning, "x=" expiry, and the
other techniques mentioned, at some point the spammers will adapt.
And as Michael and the panelist have pointed out, RFC6376 inherently
permits DKIM replay as a feature due to that separation between
envelope and message. The main thing I would quibble with the
panelist is the distinct break if we start validating parts of the
envelope or interacting with transport, as whatever technique to be
adopted will have to consider participation by unaware forwarders i.e.
some sort of gradual adoption process likely with some sort of
experiment. Also I would argue we should break that wall between the
message and the envelope and transport. From where I sit, I see mail
forwarding bit by bit breaking as spammers use forwarding as a general
technique, and the mitigations put in place using the existing
protocols are insufficient for the challenge. The evidence is
anecdotal since there aren't great tools to look at this at scale.
It should be noted that what DKIM says as a /protocol/ and what the
receiver considers as a spam filtering MTA are not the same. DKIM
rightfully has nothing to say about the envelope because it's not part
of its bailiwick. That doesn't mean a receiver can't use the envelope
for clues about spamminess. Spam filters are inherently heuristics while
DKIM is deterministic.
As far as coupling the envelope and body, that seems extremely likely to
suffer from the law of unintended consequences. Frankly, as I wrote in
my piece on throwing my hands up on mailing lists, the actual solution
is to move to a non-email protocol since email is and will be
forevermore broken wrt to authentication. It is not an eventuality that
email must be the underlying transport for forum-like messaging. There
is no particular necessity for email's distributed characteristic to run
one. Mailing lists are mainly historical, imo.
Mike
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
