On Wed, Sep 13, 2023 at 9:01 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> Let's analyze the problem Jim raises, using it to answer Hector's question > about where responsibility lies. > > Our assumed reference model is a fully automated, by-the-spec > implementation of RFC 7489. In particular, this means that: > - when p=none, unauthenticated messages are never obstructed, for fear of > hindering a wanted message > I do not see the word "fear" anywhere in the specification. When p=none, the sending domain is not asking the receiving domain to do anything but report the observed results of validation, assuming that a report receiving address(s) is provided. - when p=reject, unauthenticated messages are never allowed, in the blind > faith that such messages are always unwanted > - when p=quarantine, automation will break down, so the policy is > recategorized as either none or reject. > > This raises a coverage problem. > Not really. > A huge volume of traffic will not be protected by Sender Authentication, > so the evaluator becomes entierly dependent upon content filtering to > protect himself from attacks that impersonate unprotected domains. > By your logic, all sending domains should be forced to implement DMARC p=reject. Nothing is further from the truth. A domain may choose to only publish only an SPF record. A domain may choose to only use DKIM. A domain may choose to implement DMARC. A domain may choose to implement none of these. A domain may choose to only emit PGP signed messages. A domain may choose to use S/MIME signing. Note that NONE OF THESE approaches offers universal or even majority coverage of the global messaging corpus. In the unlikely case that a content filtering implementation is sufficient > for non-DMARC domains, it is likely to be sufficient for DMARC domains > also, making DMARC unnecessary. > One need only look at spam folders to see that content filtering to see that it does not provide a comprehensive solution. By your logic above, perhaps we should jettison content filtering as a tool. > > The coverage problem is aggravated if we assume rational attackers. With > a plethora of domains available for impersonation, attackers are least > likely to use domains that are protected with p=reject. Therefore the > reference model implementation protects an evaluator where attacks are > least likely, and fails to protect an evaluator where attacks are most > likely. > Again, you are asserting a "coverage problem" when none exists. If a sending domain chooses not to participate in DMARC, that is a choice on their part, not a problem. If a receiving domain chooses not to validate, that is a choice, not a problem. Again, applying your logic as expressed above, should we discard SMTP based messaging because organizations choose to use other forms of messaging for their communications? > > Now consider the mailing list problem. > > The mailing list owner should assume that all evaluators will enforce > DMARC according to the reference model, regardless of the receiving > domain's published DMARC policy. This means that every subscribing domain > SHOULD create a DMARC exception for traffic coming from the list's MAILFROM > address. > This does NOT mean that every subscribing domain should create an exception for traffic coming from the list's MAILFROM address. > However, we assume that this does not happen for one of these reasons: > (a) the list owner does not ask for the exception, > (b) the subscriber fails to forward the exception request, > (c) the email system administrator refuses the request, or > (d) the email filtering system provides no mechanism to implement the > request. > > Then subscribers join from one or more domains with p=reject policy, and > the problems start. When a subscriber gets disenrolled because his domain > enforces DMARC without exceptions, he screams at the mailing list operator, > who then points his finger at the p=reject domain. Alternatively, the > domain gets munged and the subscribers fuss for that reason instead. Faced > with this peer pressure, the p=reject subscriber complains loudly to his > mail system administrator. In the hoped-for-case, the domain owner caves > under this internal pressure and changes his DMARC policy to p=none. One > of the odd things about this result is that the characteristics of the > incoming messages remain unchanged. Instead, it is the risk tolerance that > has been increased. > A list owner may choose not to accept subscriptions/messages from a domain participating in DMARC and publishing p=reject. > > In the simpler solution, subscribers would accept impersonation from one > account in one domain, so that both subscriber and non-subscriber domains > are protected from impersonation attacks using the p=reject domain from any > other source. In the hoped-for solution, all Internet participants become > vulnerable to impersonation attacks using the no-longer-reject domain. > However, everyone is already undefended against impersonation attacks using > an untold number of unprotected domains, so how much does it matter if a > few more domains are made available to the attacker? Besides, evaluators > are responsible for being able to protect their networks using content > filtering only, so the change in DMARC policy is unimportant because DMARC > itself is not really important when implemented using the reference model. > You totally ignore that DMARC is about direct domain abuse and NOT random domain abuse. If I, as a user, receive an email falsely claiming to be from MY bank, I am significant risk. If I receive an email falsely claiming to be from RANDOM bank I am likely to ignore it and I am at minimal risk. > > The problem is the reference model. DMARC is not amenable or appropriate > using a fully-automated implementation. Domain owner policies of "p=none" > or "no policy" SHOULD NOT cause the evaluator to ignore Sender > Authentication considerations. > Evaluators will do what evaluators choose to do. Evaluators choosing to do some sort of authentication attempts absent a sending domain publishing a p=reject/quarantine policy is that evaluator's perogative but that IS NOT DMARC. It is outside the scope of DMARC. > Since any unauthenticated message carries risk of an impersonation attack, > regardless of DMARC policy, every unauthenticated message should be > assessed for impersonation risk. > That IS NOT DMARC. > > I keep raising issues that some consider out of scope because I want the > DMARC specification to actually help protect people from attacks. > You keep on raising (the same) issues despite the Chairs ruling them out of scope (the only opinions that matter regarding in or out of scope). The Chairs apparently are exercising an amazing tolerance in not following up on their publicly stated decisions regarding things being repeatedly brought up which they have ruled out of scope. This has contributed to the working group not moving forward and completing the work specified as in-scope in a timely manner. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
