Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

["Douglas E. Foster" <[e-mail]>]

For incoming mail, you determine what constitutes legitimate mail.    You choose whether to enforce DMARC generally.  If you enforce DMARC at all, you also choose what exceptions to apply.

But outgoing mail is different.   The sender has no guarantee of delivery.   The sender has to convince the recipient that the message is legitimate and desirable.  (Plenty of advertising messages are sent legitimately, but still get blocked by my spam filters.)

For mailing list mail, there are two messages.   The first one goes from your user to the mailing list.  The mailing list has various rules about whether the message is acceptable or not.   For openers, the sender must be a registered subscriber to the list.   Additionally, there may be limits on attachments or limits on swear words.    The subscriber knows these rules, or learns them quickly, and complies.

The second message is from the mailing list to the subscribers.   As with every other message, the mailing list sender needs to determine host to satisfy the requirements of the recipient system.   Maybe the recipient system has a longer list of swear words.   Or maybe the recipient system enforces DMARC.   Whatever the rule, the burden is on the sending mailing list to get the message delivered by satisfying the screening criteria of the recipient systems.

One important way to demonstrate legitimacy is to provide a verifiable identity.  Verified identity allows a reputation to be assigned, which then determines which content filtering rules will (or will not) be applied.   If a mailing list knows that the recipient requires a verified identity, but fails to provide a verifiable identity, whose fault is it when the message does not get delivered?

The working assumptions are that a mailing list must alter the received content, the mailing list must not reformat the From address, and nonetheless the recipient system must assume, without supporting evidence, that the message is legitimate.   

Assuming that mailing lists deserve a privileged role, we still need a way to demonstrate that any specific message deserves that role because it is from a trusted mailing list and not from an attacker.

Doug Foster

----------------------------------------
From: Joseph Brennan <[e-mail]>
Sent: 8/19/20 8:07 PM
To: "[e-mail]" <[e-mail]>
Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

I've been running email servers for 25 years. My number 1 priority is that legitimate mail gets through. Stopping the bad stuff is very important but not number 1. Does DMARC causes legitimate mail to fail? Yes, so to me it's a fail.

I can understand the transactional mail case, as I stated in previous messages. The burden is on the businesses implementing DMARC protection to inform customers to give their real end-point email addresses and not any vanity forwarding services. Any two sides can agree between them on some optional additional security measure. It's a good thing.

For general end-user mail? It's a bad thing. It will cause email to fail, and it will cause people not drinking the DMARC kool-aid to implement crazy non-standard things with From headers to make email work the way it should work without crazy workarounds. I see no reason that the DMARC standard should not spell out explicitly the use case that it is intended to meet, and recommend against using it for other use cases.

I realize that this was said ten years ago (or whatever it was) when yahoo/aol began abusing DMARC. But see how that went. The problem was not really DMARC at all, it was abuse of DMARC.

-- 

Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology