Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Hector Santos <[e-mail]>]

On 6/12/2019 9:37 AM, Laura Atkins wrote:
>
>> On 12 Jun 2019, at 14:28, Hector Santos
>>
>>  (o) Reject with 55x before DATA state
>
> Given that the 5322.from is crucial for DMARC, and the 5322.from is
> transmitted after DATA, how can you evaluate DMARC before DATA?
>

When SPF is taking into account.  But yes, overall, my comment was 
more about the whole "rejection" issue whether it was with SPF or with 
the DATA payload technologies since MARID; SenderID, Domainkeys, DKIM, 
  then ADSP, now DMARC.  The "To Reject or Not Reject" question was 
always there.

With SPF and DMARC, for example, if the receiver was made aware of the 
5322.From before the DATA state, this would preempt the need to 
receive the payload in order to get reporting information or perhaps 
get DMARC overriding deposition, i.e. p=quarantine overrides SPF -ALL 
rejection.

How?

Well today, we had the PRA/SUBMITTER protocol used to pass the 
Purported Responsible Address via MAIL FROM:

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

Many clients do use SUBMITTER. Enable it and they will pop up.  Since 
we deprecated submitter when SPF was made standard track, imto, it may 
be a good idea to explore leveraging this protocol to support DMARC at 
SMTP.

I know this is just an optimization. But I would prefer this 
optimization over the idea of accepting a potentially large payload of 
a SPF -ALL failure just to find out if there is a DMARC record because 
the operator may want to see such SPF only failures.


-- 
HLS