Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

>From Rewrite
------------------
The need for From rewrite was predictable, based on the experience with SPF.  It should have been included in the original specification.

SPF says that "The last domain to handle this message must authenticate itself."   If the message is sent directly, this is achieved by the domain owner's server identity, SMTP MailFrom identity, and SPF policy.   If the message is relayed for any reason, the SMTP MailFrom must be rewritten while also protecting the Return-Path.   SRS is the most common implementation for doing this, but there are other possibilities.

DMARC says that "The last domain to alter this message must authenticate itself."   If the message is sent without modification, the domain owner's DKIM signature authenticates the message whether it is sent directly or relayed.   If it is altered in transit by a mediator, the mediator must rewrite the From address while protecting the recipient's perception of authorship and also protecting the Reply-To.    The most common method seems to be user=domain@listdomain, but there are other possibilities, including my suggestion of useralias.listname@listdomain.

These requirements are inevitable consequences of the criterion being imposed.    So an important question is whether the end-user's dislike of From rewrite is sufficient reason to ignore the security benefits that DMARC provides.

Exception Mechanisms
-------------------------------
Both SPF and DMARC are subject to configuration errors by the domain owner, as well as abuse by "essential" sources of incoming mail.  Therefore implementations SHOULD provide an exception mechanism which does not create side-effect risks.   I have major grievance with commercial products that do not provide safe and sufficient exception mechanisms.  I would like the specification to document exception handling as a requirement.

ISP Limitations
--------------------
I am told that Office365 allows clients to place their own email filter in front of the one provided by Microsoft.  I don't know whether that solves the black box problem that Jesse raises. 

Consensus
---------------
I thought the group had informally agreed that none of the alternative authentication mechanisms had a reasonable expectation of widespread implementation.   If so, the discussion comes down to those who believe DMARC is a disaster that needs to be undone, and those who believe that DMARC is a good thing that needs to be formalized.   I see no available path to consensus between those two positions.

Doug Foster

----------------------------------------

From: jesse.thompson=40wisc.edu@dmarc.ietf.org
Sent: 10/5/20 8:22 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/28/20 10:35 AM, Kurt Andersen (b) wrote:
> On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman <sklist@kitterman.com <mailto:sklist@kitterman.com>> wrote:
>
> On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote:
>
> Agreed.  Maybe it would help if someone who takes the latter view would
> explain what they think RFC 7489, Section 6.6.2, Step 6 is for:
>
> >    6.  Apply policy.  Emails that fail the DMARC mechanism check are
> >        disposed of in accordance with the discovered DMARC policy of the
> >        Domain Owner.  See Section 6.3 for details.
>
> I don't think that says "then toss the results into your classifier".
>
>
> You completely ignored section 6.7 (Policy Enforcement Considerations) which states:
>
>> Final disposition of a message is always a matter of local policy.
>
> Local policy could be considered "the output of some classifier" or other mechanics left to the invention of the receiver.
>
> This is a part of the documented DMARC spec, not a change.

Reading this thread, it comes to my mind that the "fundamental disconnect" that John raises is partly caused by an externalized factor: the shift to cloud mailbox hosting. The roles, responsibilities, and assumptions have changed.

The receiver, who is now a customer of an ISP, does not have the ability to "invent mechanics" because the tools aren't provided by the ISP. The ISP, of course, has a good reason to K.I.S.S. for support.

It means that the ISP takes over responsibility for local policy mechanics to a greater extent. Falling short of providing their customers a platform to invent mechanics the ISP will just implement the none|reject|quarantine mechanics and say they "support DMARC".

Even if the ISP has proprietary local policy mechanics that they apply to all of their customers' inbound mail, they aren't likely to document it in great detail or offer many exemptions. It's a black box.

e.g. I find it hard to imagine that an ISP would have the willingness to exempt a boutique MLM for all of their customers, so ARC, in and of itself, doesn't really help MLMs move away from From munging. Does it make sense to suggest that in order for ARC to succeed, then ISPs need to offer a way for their customers to define their trusted intermediaries? What if the ISP chooses not to offer that? Do they "support ARC" in a meaningful way?

For the "filtering signal" viewpoint to succeed, I would ask: is there a need to define some local policy mechanics into the spec so that the ISP can be held to account by customers to "fully support DMARC". If the ISP offers no adequate mechanics to do signal filtering, then that ISP's hosted receivers cannot realistically support DMARC based on the assumption baked into DMARC that receivers can and will implement override mechanics.

The roles have changed, which has diluted the "filtering signal's" value mostly to the ISPs, and the benefit to receivers is metered by the extent to which the ISPs are willing to build a platform for their customers to invent mechanics.

If the shift to cloud is incompatible with "filtering signal" mechanics for local policy overrides, is DMARC's only value left to receivers "what users see" and the simplistic none|quarantine|fail mechanics, as defined?

Jesse

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc