Re: Email explained from first principles

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 <[email protected]> wrote:
> 
> It appears that Kaspar Etter  <[email protected]> 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 `"[email protected]" <[email protected]>` are displayed identically to emails from `[email protected] <mailto:[email protected]>`. 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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp