On Fri, Nov 14, 2025 at 5:57 PM Douglas Foster < [email protected]> wrote:
> Now that the documents are complete, some feedback: > > DMARC is designed to protect domain owners and their brands from > impersonation. It does not attempt to solve the Recipient's problem, > which is to detect and block all impersonation. RFC 7960 documents some > of the problems that have occurred because this difference has not been > well understood. > > When authentication results are matched to an omniscient viewpoint, we > observe four possible outcomes: > > 1. Correct authorship and Verified result > 2. Correct authorship with Unverified result > 3. Fraudulent authorship with Unverified result > 4. Fraudulent authorship with Verified result > > DMARC detects the first case. The fourth case is rare and will be ignored > for the purposes of this document. The middle two cases represent the > core weakness of DMARC, because DMARC cannot distinguish between these two > outcomes. > > While addressing the ambiguity caused by unverifiable authorship, it is > useful to segment the mail stream into these groups: > > 1. Messages where the Mail From domain and the From domain are > aligned. This represents the vast majority of all incoming mail [In my > mail stream, about 90%] > 2. Messages where the Mail From domain and the From domain are not > aligned. [The other 10%] > > Messages with Aligned Domains > > When the two domains are aligned, both addresses are verified at the same > time, whether the verification method is SPF Pass on the Mail From domain, > or aligned DKIM Pass on the message From domain. Because the vast > majority of senders implement SPF, the volume of unauthenticated messages > is surprisingly low. If these messages are routed to quarantine, the > authentication problems can be quickly resolved: > > - If the authorship is judged to be correct and the mail stream > represented by this message is judged to be acceptable, then future > messages can be given alternate authentication using an SPF-like rule, > based on verified host name or IP address, plus the Mail From domain. > - If the authorship is judged to be correct but the mailstream > represented by this message is judged to be unacceptable, the author or his > domain is given a block rule. > - If the authorship is judged to be fraudulent, the identifiers which > are responsible for the fraud must be inferred, so that those identifiers > can be given a block rule. > - If the message source is determined to be a forwarder that does not > rewrite Mail From addresses, the forwarder is handled similarly to > auto-forwarders who do rewrite Mail From. > > Messages with Unaligned Domains > > A message containing unaligned domains is an implicit assertion that the > Mail >From domain is authorized to act as agent for other domains, of which > the current message's From address is only an example. Therefore, the > evaluator needs to focus on the question of whether the agent is acceptable > or unacceptable, before considering the disposition of any specific > message. These types of agency are known to occur in a typical mail stream: > > - Email Service Providers (ESPs) send messages on behalf of clients. > - Software-As-A-Service (SaaS) providers are a special category of > Email Service Provider, where many clients share one application platform, > and the platform sends email on behalf of its clients. > - Mailing Lists > - Automatic Forwarders > > The reputation and operating practices of the agent become very important > for disposition of its messages. Consider the expected characteristics of > each type of agent: > > - ESPs and SaaS providers can generally be trusted to present correct > From addresses, because their operating practices require a transaction to > be authenticated before any email is sent as a result of that transaction. > This operating practice is necessary for correct billing and to sustain > the trust of their clients. DKIM signing practices will vary widely among > agents; some ESPs will only accept clients who provide a DKIM signing > scope, others will use a DKIM scope if provided, and some will never > request or apply a client signature. > > - Mailing Lists typically restrict posting to authorized accounts, so > the risk of impersonation is low, even if the list does not perform full > authentication of each posting message. An impersonator would need to > know the identity of an account that is allowed to post, and perceive the > list subscribers as desirable targets. List feedback is likely to limit > the ability to launch more than one attack, further limiting the > attractiveness of the list as an impersonation target. > > - Automatic Forwarders have the least basis for trust. An evaluator > can assume that the forwarder makes some attempt to filter out unwanted > messages, which will include some impersonated messages. The actual risk > will depend on the filtering skills of the forwarding organization, which > may vary widely. > > Regardless of the operating practices of the agent, the evaluator's > options are limited. > > - He can block all messages from the agent, after determining that > both past and potential future messages are expected to be unwanted. > - He can accept all messages from the agent, with or without verified > authorship, then rely on content filtering to catch unwanted messages. > - He can quarantine any message from the agent which fails > authentication, knowing that this strategy is likely to impose an excessive > workload onto the quarantine review process. > - He can attempt to parse the email header chain to assess whether the > message was verifiably authentic when it was presented to the agent. This > may be feasible in specific cases, particularly when the agent applies an > ARC Set or other headers to document the prior state of the message. > Unfortunately, this technique is expected to be infeasible in the general > case. > > Finally, we need to consider whether attackers are likely to use a > configuration where the domains are unaligned. > > - If the attacker has full control of the server, he has no incentive > to identify himself accurately in the Mail From address while fraudulently > impersonating the message >From address. Operational experience has > confirmed that these attacks use a single impersonated domain for both > addresses. > > - If the attacker is using an email hosting service which requires him > to be identified correctly in either address, he will typically have > difficulty using a fraudulent From address as well. Experience has shown > that these attacks use fraudulent content and fraudulent Friendly Name, > rather than fraudulent From addresses. > > Collectively, this analysis indicates that evaluators should concentrate > their efforts on messages which cannot validate the Mail From domain. > Doing so will maximize filtering of fraudulent identities, minimize > quarantine review effort, and minimize harm to mailing lists and ESPs. > > Your initial premise is incorrect. DMARC does not protect the domain/brand so much as it protects recipients from receiving emails claiming to be from the exact domain and using that domain but which do not validate. The "aggressiveness" of the domain in making a request to mailbox providers/validators is represented by the choice of p=none|quarantine|reject on the part of the domain owner/administrator. The idea is to push potential malicious actors away from using this particular vector. It does not stop phishing, spam, etc.and this sort of claim is only made by those who don't understand DMARC.Validators do not only use email authentication in determining disposition of a given email message. You have presented this or similar analysis multiple times in the past. Your analysis lacks meaningful nuance. For example, a financial being abused by malicious emails with fake login links may prefer to see potentially legitimate emails discarded because of the risks to their customers. A different type of domain may have a different risk profile. There is no one size fits all. Michael Hammer
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
