Ale's data settles that issue. Are you willing to tell this long list of companies that we are deprecating one of their product lines because they are taking money from customers for a "service" that adds no value, while also taking data they should not have?
If you can get a bunch of them to say that they think the service is useless but they offer it for marketing completeness, then you can consider deprecation. . On Mon, Jun 16, 2025, 6:53 PM Seth Blank <[email protected]> wrote: > 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 < > [email protected]> 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 <[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]
