Vocabulary: When I said "Insufficiently authenticated", I was thinking of messages that originate with SPF PASS, but arrive with DMARC Fail, for either of the common reasons:
- A message with aligned SPF Pass was forwarded, or - An email service provider message lacks alignment. But to the main point: Here is my case for changing the status quo. It is inspired by John's observation that all of his incoming failure reports are useless. Failure Reporting has two potential purposes: - Detect abuse, in the hope that the abuser can be taken down by some method. - Detect configuration errors at origination, that the domain owner can alter, so that future messages originate with dual authentication. Failure reports on mailing list messages do not facilitate either of these goals, so they are noise. Noise creates multiple problems: - Direct cost: Processing any message incurs direct cost, at least in processing resources and usually in people resources. - Opportunity cost: If I am hunting for threats in the wrong place, there are threats that I may be missing as a result. - Sedative effect: Once I learn that failure reports are consistently unimportant, they lose importance. When they do report an actual threat, the warning is likely to go unnoticed. - Non-participation: Once I learn that failure reports are a waste of time, I stop asking for those reports because I have found them to be consistently useless. In short, failure reports on mailing list messages is just another form of backscatter. Every post to a mailing list with N participants could produce up to N-1 failure reports back to the author domain, and the messages are repeated to every participating author domain after every post. The magnitude of the problem depends on the rate of participation in failure reporting, but we should not write a specification that depends for success on low usage rates. For other legitimate messages, the question is really whether failure reporting is a useful and appropriate vehicle for reporting domain owner configuration errors. I am leaning to the position that it is not. Domains that want to detect unsigned message sources should be able to do so with aggregate reporting. If a domain cannot or will not begin signing messages, notifying them of signature problems is a waste of effort for the sender and a nuisance to the recipient. Finally, this involves a bit of a personal agenda. I want to break the presumed linkage that DMARC Fail equals Abuse. I want to highlight to implementers and administrators that the two are not equivalent, and that a correct implementation of DMARC requires an evaluation of what a DMARC Fail really means, so that wanted messages are not blocked. Doug Foster On Sun, Jul 6, 2025 at 1:31 AM Steven M Jones <[email protected]> wrote: > On 7/5/25 10:46, Dotzero wrote: > > > On Fri, Jul 4, 2025 at 3:01 PM Douglas Foster < > [email protected]> wrote: > >> Authentication problems can be put into these categories: >> - Messages with malicious impersonation. >> > > Yes, a failure report should be sent. > > >> - Legitimate message with insufficient credentials at origination. >> > > ... Yes, a failure report should be sent. > > >> - Legitimate message whose credentials were lost in transit. >> > > Yes, a failure report should be sent. ... > > >> - Legitimate message from an entity sending on behalf of a domain member >> but outside of domain owner control. >> > > Yes, a failure report should be sent. ... > >> >> If an evaluator determines that a message is legitimate, should he send a >> failure report anyway? Or should the failure be considered a false >> positive that can and should be ignored? >> > > Yes, a failure report should be sent. ... > > > I agree - if the message receiver is participating in failure reports and > the domain owner has requested them, then send them when there's a failure. > > There is always the caveat of local policy, but that is out of our hands. > The focus of the document should be on how those parties choosing to > participate should interoperate. > > --S. > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
