On Mon 31/Jul/2023 16:47:15 +0000 Hector Santos wrote:
- I highlighted that "SPF Comes First" before DMARC or DKIM is known. It is entirely possible that an SPF restrictive policy (-ALL, Hard Fail) can preempt the payload transfer, causing a rejection before the DATA is reached. DMARCbis does acknowledge this possibility, mentioning that receivers might process SPF rejects before DMARC is known.
Rejecting before DATA is mentioned in Section 5.8, Policy Enforcement Considerations, as well as in Section 8.1, Issues Specific to SPF. I suggest the former succinctly reference the latter.
- I mentioned using the deprecated SUBMITTER/PRA (RFC4405/RFC4407) protocols as an implementation detail to access the author's DMARC policy at the SMTP "MAIL FROM" stage. Wei expressed interest in this idea. This could also enhance the "auth=" idea to help manage local policy SPF -ALL handling. Should SMTP immediately reject? The PRA at SMTP could aid this decision for SPF -ALL policies. Based on many years of implementation, it's evident that many mailers are either identical or are using the same software that supports SUBMITTER/PRA, possibly due to ongoing support for the deprecated SenderID (RFC4406) protocol. Here is a small snippet of this morning transaction using submitter:
Appendix D of RFC 7208 suggests to use whitelisting as a general mitigation for forwarding. To delay rejection until after DKIM verification would be an even softer mitigation. Can this be mentioned in Section 8.1?
Of course, a sender doesn't know what SPF mitigations the receivers apply. Still, whitelisting oils the wheels.
Best Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
