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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
