Steve, et al,
On 8/12/2020 8:16 AM, Steve Atkins wrote:
On 12/08/2020 04:32, Dave Crocker wrote:
Here's why I think it won't: They already have From:.
The real value in DMARC is not what is displayed to the end-user but
in having a required field that cites the originating domain name.
That doesn't change if there are additional fields that might or
might not mention the originating domain.
I think we disagree on the goal of DMARC. The entire point of DMARC is
brand protection.
Yes, but...
High-level goals are fine. But then they meet lower-level technical and
operational pragmatics.
For its originally-intended use, DMARC linked high and low pretty well.
The expanded use doesn't and essentially was adopted more to do with
stemming a denial of service attack.
Control over what is displayed to the user,
I'm confused. I thought this was a technical forum, not a marketing forum.
User's typically don't see the email address and typically it won't
matter if they do. And this has been pointed out repeatedly.
So while, yes, these have driven many people's thinking, that thinking
isn't based on empirical realities.
In this forum, we should not have to constantly be reminded that, in
actual practice, none of these activities involve direct user behavior.
Operationally, they are only relevant to the receiving filtering engine.
To the extent someone wants to claim otherwise, they should produce
empirical evidence, not summaries of marketing views. (And this request
also should not need this constant repetition.)
not what's in any particular header. You could use it for other
things, but that's what informed publishers of DMARC say they're using
it for (sometimes phrased as "protection against phishing" but that
too is all about what's displayed to the recipient).
No doubt. But, really, there is no closed-loop mechanism to validate
that it is achieving what they think it is for, namely getting users to
make fewer bad decisions about their mail content.
Certainly unauthorized use of a domain name in the From: field
/correlates/ positively and perfectly with an assessment of spam, but it
correlates negatively and perfectly with authorized uses, such as
mailing lists.
So in statistical terms, folk using DMARC see utility, but that's as a
detector of some spam, and not other spam. And they are dismissive of
the negatives, because it doesn't affect /them/.
The tone that seems to permeate here is that we need to prevent any new
identity -- addressing -- fields because bad actors will abuse them.
What this misses is whether that abuse matters. I realize that it
bothers us to see such abuse, but whether the abuse matters ought to be
relevant.
If you display the contents of Author to the user, then DMARC
publishers will want to control that.
So we need to cater to folk who want to do things that have no empirical
validity? Seems a poor basis for technical work.
The reason the Author: field is being proposed is to regain
author-to-recipient MUA-level utility.
Also there's the small matter of anticipating strategic behavior of
operators without actually knowing that the anticipation is correct and
having no history of such behavior other than a single, problematic data
point. As I recall, DMARC uptake is a small percentage of the industry.
That makes invocation of a predicted industry behavior also problematic.
If MUAs will display the contents of the Author: header where the
From: header is now then draft-crocker-dmarc-author-00 effectively
moves what used to be Sender: header to the From: header and what used
to be the From: header to the Author: header.
As I keep noting, that is what DMARC has already done.
It breaks basic, author-related utility of the From: field for MUA use.
That should matter.
And the -sender- proposal can't fix that. (see below)
You could achieve exactly the same result, with much less deployment
effort, by updating DMARC to enforce the Sender header and leaving
MUAs displaying the From: header. That wouldn't be acceptable to
anyone who wants to publish DMARC, so the Author: proposal won't be
either.
It would be nice for that to be as effective as folk want to believe,
but it can't.
1. Sender is an optional field. DMARC needs something that is always
present. That's really why there was no choice other than From:, for
its original design.
2. DMARC has an installed base and the 'legacy' receiving engines need
to be able to operate with DMARC without having to convert ot use of the
Sender: field. I tried to find a way to make this work and failed,
which is why the current -sender- draft works in parallel to the From:
field, rather than taking precedence over it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
