Re: [dmarc-ietf] Overall last-call comments on DMARC

[Alessandro Vesely <[e-mail]>]

Let me add a few comments that seem obvious to me.

On Mon 01/Apr/2024 04:00:03 +0200 Jim Fenton wrote:
> In addition to the editorial review I have provided, I have significant 
> concerns regarding the standardization of DMARC-bis. I do not expect that the 
> working group rough consensus will necessarily agree with these concerns, but I 
> want to state them for the working group and will probably restate them for a 
> different audience at IETF last call.
>
> I like to use the health care industry “safe and effective” analogy here.
>
> ## Safety
>
> Deployment of the first iteration of DMARC has resulted in significant 
> deployment problems, interfering with the delivery of some email from domains 
> with a p=strict or p=quarantine policy. Examples are:
>
> * Inappropriate use of p=reject and p=quarantine — Many domains publish 
> restrictive policies in an effort to suppress misuse of their domain names, 
> without regard for usage patterns. A number of online tools warn users and 
> domain administrators that their domains aren’t fully protected if they don’t 
> have a restricted policy, without regard to how the domain is used. Blanket 
> policies, like DHS [BOD 
> 18-01](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security), require restrictive policies for a wide range of domains (in this case for all US Government agencies). It is unlikely that the publication of DMARC-bis will rectify either of these things.


This topic is treated very well in Section 8.6, Interoperability Considerations.


> * Mailing lists — Mailing list operators, including ietf.org, have had to 
> implement rewriting of From addresses such as [e-mail] becomes 
> user=[e-mail] when a p=strict or p=quarantine policy is in 
> place. This works to some extent for IETF, but there is an enormous number of 
> mailing list operators, each of whom would need to implement address rewriting. 
> While address rewriting is not the recommended solution, it is widely used 
> because of the widespread inappropriate use described above.


By now, most mailing lists arranged to either rewrite From: or not break DKIM 
signatures.  We all hope those hacks are temporary.  ARC provides a protocol 
whereby a mailing list can certify its behavior to an end receiver. 
Unfortunately, we are still missing a protocol whereby trusting an ARC sealer 
can be established by a receiver for each mail stream.  We are halfway across 
the ford.


> * Receive-side forwarders — Many receive-side forwarders (e.g. alumni and 
> organizational domains providing affinity email addresses) preserve the 
> integrity of DKIM signatures, but not all do. This is similar to the mailing 
> list problem, except that it is more likely to occur even with domains used 
> only for transactional email, which is otherwise one of the more promising use 
> cases for DMARC.


Same as above, although most forwarders don't break DKIM signatures.  Whether 
to rewrite the bounce address is still debatable.


> ## Effectiveness
>
> There are also factors that call into question whether DMARC(-bis) does what it 
> purports to do (protecting the domain name), or whether that is valuable:
>
> * Visibility of domain names — One of the justifications given for DMARC 
> deployment is to protect the sender’s domain name: to prevent attackers from 
> spoofing the From address of addresses in that domain. But many mail user 
> agents (an increasing number, it seems) do not display the sender’s email 
> address, only the friendly name. In some cases, the recipient can request to 
> see the message header or source, but this requires specific effort and would 
> normally only be done when the user considers a message to be suspicious. I 
> regularly receive messages claiming to be from a bank, a well-known brand ,or 
> even from myself, but with a completely unrelated email address. These messages 
> pass DMARC (because the domain in the From address is controlled by them or has 
> no DMARC record) but are still effective as potential phishing messages. These 
> are considered out of scope for DMARC.


Yes.  In addition, it seems that even if a MUA were able to prominently display 
that a message is scam, average users would not notice it.

Presumably, we need domain reputation to address that.


> * Normalization of rewriting — The rewriting of From addresses described above 
> might serve to accustom users to From address rewriting. Messages with email 
> addresses that look like they have been rewritten can easily be used by 
> attackers to bypass DMARC policies and reporting.


Yes.


> ## General
>
> In 2013, a similar protocol, ADSP [RFC5617], was 
> [changed](https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/) from standards track to historic, citing limited use and harm caused by incorrect configuration very similar to the inappropriate use of p=reject described above. While DMARC has had considerably more use than ADSP, the harm that has been caused is correspondingly higher.


Most ADSP issues were addressed by RFC 7489.  DMARC works for transactional 
mail sites.  If we can fix forwarding (including mailing lists) it will work 
for all mail.


> Based on the above problems, I do not think DMARC-bis should be published as a 
> standards track document by IETF.


I think the whole WG disagrees on that.  Standard track is useful to mark the 
way forward.  Domain-based authentication is the best the whole community has 
come out with to combat email abuse.  I wouldn't suggest giving up.


Best
Ale
--