On 3/23/21 4:34 PM, Grant Taylor via NANOG wrote:
On 3/23/21 4:16 PM, Michael Thomas wrote:
But they still have the originating domain's From: address.
My opinion is that messages from the mailing list should not have the
originating domain in the From: address. The message from the mailing
list should be from the mailing list's domain.
This has the unfortunate downside of teaching people not to pay
attention to the From: domain. For mailing lists maybe that's an OK
tradeoff, but it definitely not a good thing overall. I noticed that the
IETF list does From re-writing for DMARC domains that are p=reject.
Don't try to graft "can I trust what the mailing list purports or not"
question onto the problem. Simplify it to "does this message (from
the mailing list) pass current best practice security tests or not".
Notice how the second question is the same question that is already
being posed about all email (presuming receiving server is doing so).
That is the essence of the problem and always has been. If somebody
resigns an altered message, does that change my decision of what to do
in the face of DMARC p=reject? That means I need to know something about
that mailing list if the answer is yes. Best practices have nothing to
do with it. It is all about reputation. A message mangler can be Lawful
Evil, after all.
Since Google participated in ARC, that is a pretty tacit admission
they don't know how to do mailing list reputation either.
IMHO ARC has at least a priming / boot strapping problem. How does a
receiver know if they can trust the purported information they receive
from the sending system or not. Simply put, it doesn't. Hence why I
think that ARC, as I understand it, is going to fail to thrive.
I went back to the DMARC mailing list wondering what magic that ARC
provided that we didn't think about 15 years ago only to be disappointed
that the answer was "none". I really don't understand how this got past
IESG muster, but it was an experiment.
I personally believe that the mailing list manager, or better it's
underlying SMTP server infrastructure, should uphold strict
requirements on the incoming messages. Only clean messages should be
emitted from the mailing list manager. Further, those messages should
themselves adhere to the same high security standards.
Yes, I think that's a given and feeds into their reputation.
Think about it this way: Is there really anything (of significant
value) different between a mailing list manager and a person (or other
form of automation) receiving a message from a mailbox, copying and
pasting it (work with me here) into a new message and sending it
$NumberOfSubscribers times per message to the mailing list? -- I
don't think there is.
From the standpoint of the receiving domain, it has no clue who mangled
the original message. The only thing they know is that there isn't a
valid signature from the originating domain and what the originating
domain's advice is for that situation.
What would you want SPF / DKIM / DMARC to do if I took a message from
you (directly vs passing through the mailing list manager) and changed
the recipient(s) and re-sent it out to one or more other people? --
I'd wager a reasonable lunch that most people would want SPF / DKIM /
DMARC to detect and possibly thwart such forwarding. -- So why is a
mailing list held to different (lower) standards?
This is the so-called replay attack. It's nonsense. Email has always
been essentially multicast.
An unsigned message is treated the same as a broken signature. That
doesn't help from the From: signing policy standpoint.
The original From: signature should have been validated, weighted, and
judged /before/ it made it to the mailing list manager. Further, the
mailing list manager should have removed any reference to the original
signature. <full stop>
Signatures shouldn't be removed: a broken signature is identical to a
missing signature security-wise, but broken signatures can be used for
forensics. I, for example, could reconstruct a very large percentage of
mailing list messages to unbreak signatures. It was to the point that it
was quite tempting to use that approach to deal with MLM traversal.
Mike
