A nit on whitelisting. I suggest that we use the term "Alternate Authentication" rather than "Whitelisting". In my experience, whitelisting often implies exemption from both authentication checks and content checks. When an administrator simultaneous disables both types of defenses, his environment depends entirely on the hope that malicious impersonators will not stumble on the vulnerability. The correct solution for failed authentication (on wanted messages) is to provide an alternate authentication implemented as local policy. Our document should make this clear.
Doug On Wed, Aug 2, 2023 at 6:34 AM Alessandro Vesely <ves...@tana.it> wrote: > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
