And one more important point: If failure reporting only occurs on fraudulent messages, the privacy problem ceases to be a problem.
On Sun, Jul 6, 2025 at 7:22 AM Douglas Foster < [email protected]> wrote: > 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]
