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 - 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. 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. 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. 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. 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. 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. 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. 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. Since any unauthenticated message carries risk of an impersonation attack, regardless of DMARC policy, every unauthenticated message should be assessed for impersonation risk. I keep raising issues that some consider out of scope because I want the DMARC specification to actually help protect people from attacks. Doug Foster On Wed, Sep 13, 2023 at 5:29 PM Hector Santos <hsantos= 40isdg....@dmarc.ietf.org> wrote: > On Sep 11, 2023, at 9:24 AM, Dotzero <dotz...@gmail.com> chastised > Douglas Foster > > Absolutely incorrect. DMARC is a deterministic pass|fail approach based on > validation through DKIM or SPF pass (or if both pass). It says nothing > about the acceptability/goodness/badness of a source. > > > So why are we here? > > Correct or incorrect, a published p=reject has to mean something to the > verifier who is doing the domain a favor by a) implementing the protocol > and b) the goal of eliminating junk. If there are false negatives, whose > fault is that? The Domain, The Verifier or the Protocol? > > I think it’s the protocol but thats my opinion as one of early DKIM POLICY > adopters and an advanced and costly implementation. If policy does not help > protect a domain and also the receiver with failure hints or better said > negative classification of a source per the domain policy, then what is the > point of the work here or lack of there? > > Same is true with SPF. > > Please try to be more civil with people’s views or position with this > problematic protocol. > > Thanks > > All the best, > Hector Santos > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
