None of this is in scope. We’re deciding whether to publish the document or not.
Please keep your comments within chartered grounds. Seth, as Chair -mobile On Mon, Jun 16, 2025 at 18:28 Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 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 <s...@sethblank.com> 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 < >> dougfoster.emailstanda...@gmail.com> 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 -- dmarc@ietf.org >>> To unsubscribe send an email to dmarc-le...@ietf.org >>> >>
_______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
