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

[Douglas E. Foster]

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

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

[Jesse Thompson]

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

Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 4 06:00:06 2020

[Alessandro Vesely]

On Sun 04/Oct/2020 11:59:43 +0200 John Levine wrote:

Count|  Bytes |  Who
 ++---
  13 (20.3%) |  73062 (14.6%) | Dave Crocker 
   5 ( 7.8%) |  36424 ( 7.3%) | Dave Crocker 
   2 ( 3.1%) |  15742 ( 3.1%) | Dave Crocker 

   ++---
20 (31.2%) | 125228 (25.0%) | Dave Crocker

Are (signed) display names amenable to any programmatic usage?


Best
Ale
--





















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