Re: [dmarc-ietf] Objections to Sender header as override

[Dave Crocker <[e-mail]>]

On 9/29/2020 5:54 PM, Brandon Long wrote:
> Ie, a mailing list that adopts the Sender header still won't know when 
> it can do that over rewriting.

That's correct.  It won't.  But no alternative does, either.


>  I agree with others who have said that adding this makes DMARC not 
> DMARC,

As with so many comments, from quite a few people, it's a good catch 
phrase, but it does not come with any technical detail to give it 
substance and credibility.

So the fact that I disagree with the assertion, about what adding this 
feature does, highlights disagreement, rather than understanding.

So, please explain what DMARC is -- yes, I know that sounds silly, but 
it appears to be necessary for this discussion -- and how the proposal 
makes it not DMARC. That's a request for technical detail, not quick 
opinion.

I'll put this meta-problem a bit differently:  People are locked into 
very narrow and mechanical views of the DMARC work.  We need, instead, 
to be thinking in pragmatic terms of threats, mitigations, effects and 
side-effects, and we need to be doing this with technical detail, not 
facile catch phrases.


> though I'm willing to explore that in more depth.  I understand Dave's 
> points regarding user level signals, but I think alignment benefits in 
> other ways.

Please enumerate those.


> If you instead wanted to add it as a separate thing, I don't think it 
> should be couched as overriding DMARC like it does, but as the same 
> way we expected ARC to override DMARC, as a well defined local policy 
> override.

The word "override" does not appear in my draft.  Nor should it. Nor 
should it appear in these discussions.  Its use is a fundamental 
misrepresentation of what DMARC does.

If you are going to the grocery and I say you should buy healthy food 
and you come back with tasty, unhealthy food, did you "override" me?

If I am a passenger and you are driving and I say turn left here and you 
don't, did you "override" me?

The answer in both cases is no.  Advice was offered and ignored. There 
was no "override" of the advice.

That's DMARC.  The receiver has no obligation, nor even an expectation, 
of following the domain owner's request.  So "override" fundamentally 
misrepresents the role and authority of the domain owner (and of the 
receiver).


> Really bad third party signing:
> I've objected in the past to various third party signing approaches as 
> being non-starters for high value domains. Google does not use SPF's 
> include mechanism, and is not going to list hundreds of possible third 
> parties as "ok" for signing to cover all possible mailing lists that 
> are employees work on.

What does Google see as the long-term role and use of ARC?

Isn't it to allow From: field DMARC failure but still permit delivery of 
the message?


> In some sense, the Sender override is basically third party signing 
> without any actual relationship...

From: field re-writing is also a form of third-party 'override'. It's 
merely uglier, with significant recipient side-effects.

That is, it seeks to give the recipient -- the actual user -- something 
akin to what they would have gotten from the original From: field, but 
in a way that breaks assorted recipient handling benefits.


BY THE WAY...

It appears you are working from the original version of the 
specification and not the current one.

The current one treats the Sender: field enhancement as an ADDITION, not 
an ALTERNATIVE.

d/

-- 
Dave Crocker
[e-mail]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[e-mail]