Doug, this is the same argument that you've been making for a very long time. DMARC has never made any claims about malice, capitalized or not. DMARC does a specific thing and neither tries to do more nor pretends to. You want it to do more. The working group does not. You are in the rough.
Stop arguing this now, and stop wasting the working group's time by goading its members into repeating the same answers to the same arguments. Barry, chairing On Fri, Dec 6, 2024 at 7:21 AM Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote: > > The mailing list problem exists because DMARC promulgated a lie that some > forms for FAIL mean MALICE. Lies have no place in a Standards Track > document. The group has tunnel vision defined by RFC 7489 language rather > than trying to achieve the RFC 7489 goal. There is no theoretical or > operational justification to block based on sender authentication alone. > The current document is contradictory by preserving p=reject as an actionable > result and then inserting weasel words to say that it is really not > actionable. The truth is that it is not actionable and p=reject should be > repudiated, deprecated, and when observed in a policy it should be treated as > p=quarantine. The mailing list problem, which has probably consumed a full > year on this list, is solved by deprecating p=reject as illegitimate. > > Email Filtering begins with content filtering, which is and always will be an > essential part of the defenses. > The purpose of Sender Authentication is to offload content filtering to allow > reputation to be assigned to mail streams and their originator instead of to > individual messages. > Both techniques may produce false positives that may lead to a need for > bypass, leaving four possible flow paths for accepted messages: > > Authenticated and passed by content filtering - The preferred route > Authenticated and highly trusted and bypasses content filtering - The > whitelisting route > Authentication bypassed but passed by content filtering - The fallback route > Authenticatation bypassed and content filtering bypassed - The suicide route > > The suicide route should be registed with MITRE as a CCE, because it should > never be used. Nonetheless, it is an available and almost necessary option > in many filtering products. > > Content filtering bypass becomes necessary when an important message cannot > be allowed without weakening defenses against other messages. Therefore, > the need for mandatory authentication is not determined by the sender, it is > determined by the recipient's need to bypass content filtering. > Fortunately, because FROM authentication is entirely based on proxy > authentication, every wanted message can be given an alternate configuration > rule that distinguishes it from other messages. > > Rather than sending unauthenticated messages through the fallback route, a > safer strategy is to send them to quarantine, if the quarantine can be worked > in a timely manner. This becomes progressively easier as the percentage of > authenticated messages increases and the volume of blocked spam increases. > > For unauthenticated messages, whether the current message is sent through the > fallback route or quarantine, the objective should be to evaluate the message > for acceptability so that all subsequent messages from that mailstream are > either authenticated or rejected using an updated local policy. > > This process can get you to 100% authentication. The worst possible delay > to wanted messages is 1 quarantine delay, but even that delay can be avoided, > if desired, by using the fallback route. > > RFC 7489 makes the recipient dependent upon that sender's participation in > DMARC. This is unacceptable. No stranger should be given the authority > to lower my security defenses. > > Doug > > > On Thu, Dec 5, 2024 at 11:02 AM Al Iverson > <al.iverson=40valimail....@dmarc.ietf.org> wrote: >> >> I disagree with the conclusions drawn here. >> >> This frankly feels like the old chestnut, how does DMARC protect >> anything at all, since a domain owner can only protect their own >> domain against spoofing and the bad actor will simply choose another >> domain? My response to that is that I still wish to lock my car and >> secure it even if people are stealing other cars. At my personal >> level, I start by protecting my domain. I help the ecosystem by >> helping others to protect their domains, through specifications such >> as this. >> >> I also disagree that only god can see the global threat situation. >> Every mailbox provider and spam filter MX has a varying level view of >> the threat situation and information on the global threat situation is >> compiled from that data and comparing notes between providers and >> filterers. >> >> None of this seems like actionable feedback on how to improve the >> specification. >> >> Regards, >> Al Iverson >> >> On Thu, Dec 5, 2024 at 6:28 AM Douglas Foster >> <dougfoster.emailstanda...@gmail.com> wrote: >> > >> > Example.com sends 10,000 messages per day, of which 100 (1%) produce DMARC >> > Fail, so they publish a policy with p=none. >> > >> > Attackers send 1,000,000 messages that impersonate Example.com. On a >> > global basis, messages claiming to be from Example.com are 99% Fail, and >> > the Fail are 99.99% true spam and 0.01% false positives. >> > >> > In response, Example.Com changes its policy to p=reject. The spammers >> > mostly switch to impersonating Example.Edu,leaving only 100 attacks per >> > day on Example.Com. The Fail rate is now down to 2%, of which 50% are >> > true spam and 50% are false positives. >> > >> > >> > But nobody but God sees the global threat situation. An evaluator who >> > sees 50 messages per day may see 50 PASS, 50 False Positives, 50 True >> > Spam, or any mix of the three. Additionally the mix may change over time. >> > >> > Responses: >> > Some evaluators will see 50 true spam with p=none, conclude that DMARC is >> > useless, and unconditionally block Example.com. When the mix changes, >> > legitimate messages will be blocked. >> > >> > Some evaluators will see 48 pass, 2 false positives, and conclude that >> > DMARC needs an override. They use the only override offered by their >> > filtering product, which is to exempt Example.Com from authentication. >> > When the mix changes, attack messages will be allowed. >> > >> > Because neither of these evaluators have learned anything about the >> > attackers, they are not prepared to defend themselves when the same >> > attackers change from impersonating Example.Com to impersonating >> > Example.Edu >> > >> > Conclusion #1: Sender disposition policy has no relationship to either >> > global threat risk or personal threat risk, and SHOULD be ignored unless >> > another use can be found for it. >> > >> > Conclusion #2: Blocking unauthenticated messages creates vulnerabilities, >> > unless the cause of the authentication is investigated and traced to the >> > responsible party. The best way to do this is by sending messages to >> > quarantine, then configuring wanted message sources with alternate >> > authentication and unwanted messages sources with block rules. >> > >> > RFC7489 has misled a lot of people about the impersonation problem, and >> > DMARCbis has not fixed that. >> > >> > Doug >> > _______________________________________________ >> > 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 > > _______________________________________________ > 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
