We are still trying to fix an evaluator problem by changing domain owner behavior. No harm in giving domain owners the warning, but changing evaluator behavior would be much better. Presumably, the evaluator behavior that we have today is the result of RFC 7489 wording, so we may be able to change future evaluator behavior by strategizing the language of DMARCbis.
Compare email authentication to a controlled-access building. On any given day, some employees will arrive at work to discover that their badge is back at home. How is it handled? By sending the employee to the physical equivalent of quarantine: the pass office. Most employees can be validated by another method, such as driver's license or biometrics. An employee who forgot his wallet and cannot be verified by biometrics will lose a day's work. However, a person who is identified as using a fake ID will be led away by police. Email authentication is not much different. We are judging message source acceptability, not individual messages. 100% email authentication is possible and should be the goal. Quarantine is the preferred place to send unauthenticated mail, regardless of sender policy (or lack of policy). In quarantine, acceptable messages are given alternate authentication and released, just as the secure-building employee is given a temporary badge or replacement badge. If lack of authenticated is discovered to be a fraudulent attacker, then all messages from the attacker should be blocked, not just the impersonation messages. When it seems impossible to quarantine and review every unauthenticated message, triage becomes necessary. The messages with highest perceived risk are sent to quarantine and the lower-risk messages are released and reviewed as time permits after the fact. Either way, the workload steadily decreases as message sources become permanently authenticated or permanently blocked. Doug Foster On Sun, Sep 10, 2023 at 8:46 PM Jim Fenton <[email protected]> wrote: > On 7 Sep 2023, at 9:28, Wei Chuang wrote: > > Many enterprises already have "p=reject" policies. Presumably those > domains were subject to some sort of spoofing which is why they went to > such a strict policy. > > This is not necessarily the case. For example, DHS has directed > <https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security> > all Executive Branch federal agencies to publish a policy of reject, > regardless of whether they were subject to spoofing (and with no mention of > the problems with doing so. Others have published “Email Security Best > Practices” advocating the use of p=reject. For example, one well-known > email vendor has a tool that generates a warning if p=quarantine or > p=reject isn’t configured, and says on their website, “We recommend reject, > for reasons we’ll touch on later.” > > I agree that the SHOULD language is not very useful because it’s likely to > be interpreted as only advice. Instead, I think we need a stronger > statement about the consequences of this policy. For example, “Domains > publishing p=reject MUST NOT expect mail to mailing lists and similar > forwarders to be delivered reliably.” > > -Jim > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
