Just working through the decision tree of when failure reporting an evaluator should or should send reports. Reputation of the recipient is an essential part of that decision.
Purpose of Failure Reports · Help senders improve their deliverability by correcting authentication problems. (This mostly applies to deliverability to others. If I want to ensure deliverability of messages from a particular sender, I can adjust my local policy faster than waiting for the sender to make adjustments.) · Provide senders with evidence they need to take down bad actors, by contacting infrastructure vendors or law enforcement. (I could do some of this on my own, but I may wish to delegate this back to the sender, to conserve my own resources. Additionally larger senders may have more options for taking down bad actors.) Decision tree for sending Failure Reports · Do I have the software tools for failure reporting? · Am I willing to commit the processing resources needed for failure reporting? · Do I have a throttling mechanism to protect against extreme volume spikes? · For each individual sender, is it in my interest to help them improve deliverability? Bad actors do not deserve help, and bad actors do not have to worry about impersonators. Good actors do warrant help and do contend with impersonators. · For senders without reputation, do I default to sending a report, default to omitting a report, or perform a reputation analysis to resolve the ambiguity prior to sending any reports? On Sun, Jun 15, 2025 at 5:35 PM Seth Blank <[email protected]> wrote: > What is your point here? Consensus has been reached on all these matters > and we’re not discussing material changes to the bis documents. > > What is under tight consideration now is the publishing or not of the > forensic reporting document and relevant edits to accomplish that and that > alone. > > If you are suggesting some hypothetical attack that no one has ever seen > before, and you think this makes forensic reporting a larger risk than > before, please quantify that problem based on operational data and explain > what decision that informs under the current scope of the charter. > > Seth, as Chair > > -mobile > > > On Sun, Jun 15, 2025 at 17:08 Douglas Foster < > [email protected]> wrote: > >> A small volume of incoming messages will be rejected because the >> recipient account is over quota, the recipient account has been terminated, >> or the sender accidentally entered an incorrect address. If the sender is >> known to be legitimate and acceptable, then the sender should be notified >> of these occurrences. >> >> However, the vast majority of rejected messages are some form of >> attack, detected because of: >> >> - negative sender reputation, >> - negative content score, or >> - incorrect recipient addresses that represent a directory harvesting >> attack. >> >> In these cases, the attacking sender's interests are in direct conflict >> with the recipient evaluator's interest. Under these conditions, >> information transfer from evaluator to sender can only help the sender at >> the expense of the evaluator. A rejection says, "This attack strategy has >> failed. To penetrate my defenses, you must use a different strategy." >> This information motivates the attacker to attack in a different way. >> >> By comparison, silent discard communicates to the sender that the attack >> succeeded, even though it did not, so the sender has no indication that a >> tactical change is needed. Therefore, the optimal security strategy is to >> only provide non-delivery information to known-good senders. For other >> senders, the optimal security strategy is to report success with 250 OK, >> and then silently discard. >> >> DMARC reporting adds another layer of risk to this process. An attacker >> can use two domains to test impersonation defenses, one performing >> impersonation and one being impersonated. The impersonated domain chooses >> different policy postures, then the impersonating domain performs attacks. >> The controller of the attack receives information from dual sources: The >> impersonation domain captures any delivery status, while the impersonated >> domain captures any aggregate or failure reporting. By combining these >> sources, the attacker is likely to find an impersonation attack strategy >> that is likely to succeed. Consequently, DMARC feedback also falls under >> the principle that feedback should only be provided to known-good domain >> owners. >> >> Doug Foster >> >> >> >> >> _______________________________________________ >> 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]
