Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Hector Santos <[e-mail]>]

> On Apr 13, 2023, at 3:13 PM, Hector Santos <hsantos=[e-mail]> wrote:
> 
> On 4/13/2023 11:21 AM, Barry Leiba wrote:
>>> Anyone who does forwarding is damaged by DMARC because there are a lot of
>>> people who do DMARC on the cheap with SPF only.
>> This brings up another issue, I think: that there should also be
>> stronger advice that using DKIM is critical to DMARC reliability, and
>> using SPF only, without DKIM, is strongly NOT RECOMMENDED.
>> 
> Keep in mind, there are implementers of SPF that act at SMTP before DATA and reject hard failures with 55z errors.  In other words, no payload is transferred.
> 


Let me expand on this:

First, SPF predated DMARC. 

DMARC as a payload protocol, like any other payload protocol have high overhead associated with it;  DKIM, ADSP, ATPS, DMARC processing.  

Nothing to worry about at low scale and nothing to worry about at high scale if optimized correctly, and that is by allowing SPF to pre-empt payload processing when there is a hard SPF failure.  That’s good. Not Bad. In 18 years of SPF,  I maybe had 1 false positive.

But even then with introduction of DMARC, I recognized the domain policy may be p=none or p=quarantine.

Therefore I propose RFC 4405 SUBMITTER protocol to pass the PRA at MAIL FROM

C: MAIL FROM:<return-path> SUBMITTER=pra

Where the PRA is the 5322.From address.

The allow SMTP to check the DMARC policy at SMTP. helping it how to handle SPF rejections.

Please let’s make this Protocol Complete.   If DMARC requires SPF to be delayed until the DATA state, then you are talking about an anti-scaling feature. Use SUBMITTER to pass the PRA.

—
HLS