On Wed 06/Jan/2021 13:52:33 +0100 Laura Atkins wrote:
On 6 Jan 2021, at 12:29, Douglas Foster <[email protected]>
wrote:
I am no fan of header rewrite, but...
If you are going to talk about "Trust Indicators", we need to define terms,
which has not been done. Here are my definitions:
- The From header is an Identity Assertion.
- DMARC is an Identity Verification technique.
- A text message saying, "This message verified by DMARC", is a Trust Indicator.
My definitions are consistent with the way that that one study used a trust
indicator. Using these definitions, From rewrite has nothing to do with Trust
Indicator research. If anyone wants to assert different definitions, please
get them on the table.
The fact that users complain about From rewrite is proof that they look at the
information. This is because it is an Identity Assertion, not a Trust
Indicator.
The header rewriting being proposed - that is header rewriting by the ESP so
that the messages that go through their system are rewritten to point to the
ESP and not the author of the message - means that the identity assertion is
disconnected from the context of a message.
Want to know what mail goes through ESPs? Bank mail, social media mail,
marketing mail. Billions of emails a day go through ESPs that you have and have
not heard of.
The proposal at issue is that these ESPs be allowed to rewrite the From
address any message they handle to point to an email address they control. This
disconnects the identity in the 5322.from address from the actual sender of the
message.
Most users may know who constantcontact are or mailchimp because they advertise
widely. Some might have heard of GoDaddy but do you know what the company name
of the GoDaddy ESP is? I don’t off the top of my head.
The options we have depend on both identities, the ESP customer, be it a bank
or a girl scout trooper, and the ESP itself. If the customer avails itself of
a free-mailbox provider, the options depend, in turn, on what ancillary
services does the latter provide.
Ancillary services may include publishing external selectors on behalf of the
ESP, and authorizing an ESP to use submission on behalf of its customer. They
both result in better authentication than From: rewriting. To cope with girl
scout troop at a free-mailbox provider, an ESP could also get itself an account
at that provider and gain DMARC authentication that way.
For cases where the above options don't apply, From: rewriting is an
established workaround. We ourselves are using it on this list. Its
effectiveness depends on the reputation of the ESP domain. It might be better
known than the customer domain, in which case the customer itself may prefer it
for increased deliverability.
I accept that actual Trust Indicators have a small effect, but rounding down
to zero seems like an overstatement. When fighting malware, I will take all
the help that I can get, even small help.
And now we have a malware company that rewrites headers to point to a domain
they own and it passes DMARC and is given a Trust Indicator. Recipients are
used to seeing domains they don’t know or understand send trusted mail from
their bank, or their girl scout troop, or their social media company. They have
no reason to distrust the unfamiliar identity assertion in the from address.
Phishing happens irrespective of our recommending From: rewriting or not.
If we do specify it, we could say something like:
DON'T:
From: "Someone <[email protected]>" <[email protected]>
DO:
From: "Someone via devil" <[email protected]>
Reply-To: Someone <[email protected]>
It seems Mailman is careful enough when it rewrites entries like:
From: "[email protected]" <[email protected]>
The latter is an example of bad display names. It can be accepted, as it's
sadly so common, as long as the addresses match. Mismatched addresses like in
the first example should be interpreted as a sign of phishing, and hence
trigger filtering or distrust indicators as needed.
Can we say that?
Would such kind of normative help to improve filters and trust indicators?
Domain administrators are within their rights to block any incoming message for
any reason. Users routinely work with their domain administrators to ensure
that the messages that they want get accepted and messages that they do not
want get blocked. If users and domain administrators cannot solve their
differences, the user can communicate using a different domain. If DMARC
produces false positives that cannot be resolved by this process, we would do
well to ask why.
Header rewriting doesn’t solve false positives, it increases the chances of
them. Header rewriting for commercial messages by ESPs means that folks
attempting to masquerade as a legitimate company have a RFC recommended way to
evade DMARC and pretend to be the company they’re attacking.
People cannot pretend /to be/ another company, they can only pretend to /be on
behalf of/ it. Shouldn't we train users to look at the name after the strudel?
Web browsers came to the conclusion of highlighting the organizational domain
part of URLs. (It is one of PSL's uses.) Do we have data on the effects of
doing so?
This isn’t random speculation, this is what is going to happen. We've spent the
last 20 years watching spammers and phishers do everything they can to get mail
out. If the DMARC RFC says ‘ESPs should rewrite headers to avoid DMARC policies
on mail going through the ESP’ then we’ve just made DMARC utterly worthless.
We’ve also set up every company that is currently using DMARC p=reject to be
attacked in ways they cannot tract.
Keeping in mind that that attack path is here to stay anyway, we can choose to
either content ourselves with mentioning it in the Security Considerations, or
also suggest to use it as a legitimate workaround.
CON:
DMARC may seem to be utterly worthless, since it can be circumvented so easily.
PRO:
The workaround increases deliverability of mail flows from domains with strict
policies.
IMHO, there is value in certifying DMARC's main identifier. Increasing the
deliverability of strict policies will invite more domains to get beyond
p=none, especially if, eventually, mail from domains with p=none or without
DMARC record at all is going to be treated with some suspicion.
Mailing lists are going to stick on From: rewriting for the foreseeable future,
and not standardizing that workaround while we're using it is somewhat
schizophrenic of our stance. Undoubtedly, mailing lists are doomed to
disappear, in the long run. Meanwhile, they have full citizenship in the email
panorama.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
