I don't agree. An allow list bypasses something -- whatever processing the list allows something past -- but not everything.
In this case, we might be talking about a list that means "If we are sufficiently certain that a message same from the entity on the list, we will not reject it even if the 'From' domain publishes p=reject." First, what that sufficient certainly means will be a matter of policy, and could well require that the message be authenticated as coming from the listed entity (via SPF or DKIM, or perhaps through some private arrangement). Second, the message might still go through other evaluation, such as normal spam filtering, and could be discarded, rejected, or quarantined on that basis. I see no reason to avoid talking about using such allow lists, and I see it as beyond our scope to say how a receiving domain decides what to put on such lists or how it assures itself that a message qualifies for the special handling the list provides (apart from saying something like the "sufficiently certain" above). Barry On Wed, Aug 2, 2023 at 9:46 PM Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote: > > 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 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
