This conversation went off on a tangent, but I also want to comment on a couple
of things:
On 24 May 2021, at 16:03, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
It appears that Kaspar Etter <kaspar(_at_)ef1p(_dot_)com> said:
2. List-Name header field: Mailing lists shouldn’t rewrite the messages of
others and break DKIM signatures in the process.
Sorry, but this shows some serious misunderstandings about both DKIM and
mailing lists.
DKIM is a transport signature, which in this case shows that the message was
sent from the author
to the mailing list system. List apply their own DKIM signature on the mail
they send.
Mailing lists have been editing messages for 40 years, long before anyone
ever thought of DKIM or DMARC. It is a well known DMARC failure that it
doesn't work with mailing lists.
Some people have tried to rewrite history and claim that it is the lists'
fault but they are wrong.
The whole point of ARC is to provide recipient systems with info to help
recognize when they should
ignore DMARC and deliver mail from lists and other legitimate senders that
don't happen to match the
assumptions that DMARC makes.
I disagree. My impression is that some people think that the world can be
divided into good guys and bad guys and that email is supposed to work as a
cooperation among well-intended postmasters. I respect this view, but I also
think it’s naive and outdated. IT security is about minimizing trust and attack
surfaces. Domain authentication with SPF, DKIM, and DMARC is an important step
in this direction. Domain authentication isn’t enough to prevent phishing, of
course, since homograph attacks and malicious display names are still possible,
but it allows mail clients to put only messages from approved senders into the
user’s inbox. HEY is the only mail client I know of which does this (see
https://www.hey.com/features/the-screener/
<https://www.hey.com/features/the-screener/>), but I’m confident that we’ll see
similar features in other clients in the future. I believe that mechanisms like
this and showing only the display names of approved senders would go a long way
in fighting phishing – but only in combination with domain authentication.
Other efforts to curb phishing, such as BIMI, also require domain
authentication. (BIMI also addresses homograph attacks with verified mark
certificates.)
One of the nice things about DMARC is that it makes domain authentication
opt-in for those who want this (even if the reason for this feature is mainly
backward compatibility). I’m honestly surprised to see that almost no one here
uses DMARC with a policy of reject or quarantine, but I don’t mind this because
it’s your call. What I do mind is when people deny the legitimacy of other
viewpoints. I don’t care whether it was a conscious design decision that the
sender of a message can be spoofed. “It appears that someone said” is simply
not how I want to use email, and given that email is an open system which I’m
forced to use, I think that I should be allowed to have this view.
Making it easier for mailing lists to keep DKIM signatures intact wouldn’t
force anything upon anyone. If mailing lists prefer to rewrite the sender
address, they’re free to do so. (I acknowledge that a DMARC policy other than
none forces mailing lists to do something, but backward compatibility shouldn’t
be sacred and this ship has sailed anyway.) ARC, on the other hand, subverts
the little progress towards trust minimization that some of us gained with
DMARC. For my email addresses, I’m the only legitimate sender. I don’t want to
be obliged to trust people I have no business with not to impersonate me. If
ARC gains adoption, the servers of reputable mailing lists will be a prime
target for scammers. ARC only makes sense with a good guys versus bad guys
mentality in a world with no IT vulnerabilities but not with a security
mindset. Introducing a DMARC policy of “reject-unless-arc-trusted”, as
mentioned by Bron Gondwana, might be a good compromise between the two camps.
For the reasons I just mentioned, I wouldn’t use this policy on my domains,
though.
On a different note, the problem with malicious display names is much worse
than many people are aware: Most of the mail clients which display only the
display name do so even if the display name is itself an email address. Emails
from `"bob(_at_)example(_dot_)com" <alice(_at_)example(_dot_)org>` are
displayed identically to emails from `bob(_at_)example(_dot_)com
<mailto:bob(_at_)example(_dot_)com>`. See
https://explained-from-first-principles.com/email/#malicious-display-names
<https://explained-from-first-principles.com/email/#malicious-display-names>
for more context.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp