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

From: Dave Crocker <[email-masked]>
Date: Thu, 1 Oct 2020 05:47:49 -0700

On 9/30/2020 9:37 PM, Seth Blank wrote:
> Hector, the chairs hear your frustration, thank you for not escalating 
> further, and would be happy to speak with you off list on the matter.

Seth,

Please reread the post you responded to.  It is, in fact, an 
escalation.  The tone you've set with your response  fully undermines 
the necesary firm, direct, disciplinary action.

And yes, I intended this note to go to the list, since my private note 
to you apparently was not sufficient.

There is a long-standing pattern of behavior here.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Thu, 1 Oct 2020 06:32:21 -0700

Seth,

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Seth Blank <[email-masked]>
Date: Thu, 1 Oct 2020 06:56:21 -0700

Dave, disengage from this thread. Continuing to publicly attack a
participant who's been asked to disengage and so far has done so is not
acceptable. This is a formal warning.

The chairs and ADs will be in touch. Feel free to reach out to us directly
in the meantime if you so wish.

Seth, as Chair

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 1 Oct 2020 06:58:32 -0700

On 10/1/2020 6:56 AM, Seth Blank wrote:
> and so far has done so is not acceptable.

He didn't.

d/

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 5 Oct 2020 18:57:48 -0500

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

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 5 Oct 2020 22:13:45 -0400

>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=[email-masked]
Sent: 10/5/20 8:22 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Jesse

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 6 Oct 2020 09:23:36 +0200 (CEST)

> Il 06/10/2020 01:57 Jesse Thompson <jesse.thompson=[email-masked]> ha scritto:
> 

>From a policy standpoint, it is troubling to imagine that each email system would define their own list of trusted ARC intermediaries. This is a recipe for centralization and oligopoly, as most people would just create a shortlist of a few well known big intermediaries, and any smaller entity trying to compete with them (including non-profit operations, community servers, self-hosted mailing lists etc) would be at a serious disadvantage. There is also the problem of keeping these lists up to date once installed. It would be much better if there were a few professional/community efforts to build reliable and complete lists of good and bad ARC intermediaries, like for spam.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2020 11:20:41 -0400

In article <[email-masked]> you write:
> It would be much better if there were a few professional/community efforts to build reliable and complete lists of good
> and bad ARC intermediaries, like for spam.

Having tried and failed to build a whitelist for Spamhaus, I can tell
you that it's hopeless.

The bar for ARC to be usable is pretty low. It's not "doesn't send
spam" or even "knows who its users are." It's only "doesn't lie about
where mail came from."  I expect that in practice the usual DNSBLs
will be good enough.

R's,
John

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 6 Oct 2020 13:59:13 -0500

> where mail came from."  I expect that in practice the usual DNSBLs

Is the assumption with ARC, when it reaches some point of "production" status, that intermediaries will be able to look themselves up in the usual DNSBLs to see if they are trusted so they know that they don't need to rewrite the From?  Sorry, that's going down the rabbit hole...

I only brought up ARC as one example of local policy overrides that an ISP-hosted receiver might want to have mechanics to control.  Even with ARC being adequately managed by the usual DNSBLs, I could imagine that I would want to have some control over the edge cases.

Surely there are other examples...

* This is probably the most common one, based on personal experience: Allowing a 3rd party to send inbound mail to your organization "From" your own domain, but not allowing that 3rd party to use your domain to send outside of your organization (hence, not authorized by DMARC).  Ideally I would want a solution that keys off of multiple signals (SPF result, DKIM result, DKIM domain/selector, etc) rather than something crude, like "trust all mail from these IPs".

Again, my larger point is that if we want "filtering signal" to be the primary value-add for DMARC, then I'm suggesting that we may need to ensure that receivers actually have the ability to invent filtering signal mechanics in order to be "using DMARC".  If the receiver's ISP is preventing that, then perhaps there needs to be a way for ISPs' customers' to measure their ISP's DMARC capabilities/maturity in this regard.

> 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. 

Yes, this is what we do, but it's not common.  Microsoft occasionally tries to convince us to point MX at them, and I sympathize with their motivation to put all of their customers in a consistent configuration.  On the other hand, there are some local policy mechanics that we currently rely on which they don't provide.

Jesse

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2020 16:41:03 -0400

In article <[email-masked]> you write:
>Is the assumption with ARC, when it reaches some point of "production" status, that intermediaries will be able to look themselves
>up in the usual DNSBLs to see if they are trusted so they know that they don't need to rewrite the From?

No, not at all. ARC puts a chain of signatures on a message, but the
final recipient can only verify the most recent one and has to trust
the previous ones for ARC to be useful. So is the chain real, or just
a bunch of garbage invented by spamware, like the long chains of
Received headers they used to add?

You only have to trust the most recent signer, since each link in the
chain says whether the prior links were valid and a legit signer will
note that the previous seal didn't verify if that's the case.

R's,
John