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
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
