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

[Jesse Thompson <[e-mail]>]

On 9/28/20 10:35 AM, Kurt Andersen (b) wrote:
> On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman <[e-mail] <mailto:[e-mail]>> 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