Re: [dmarc-ietf] Header Rewriting

[Alessandro Vesely <[e-mail]>]

On Wed 06/Jan/2021 13:52:33 +0100 Laura Atkins wrote:
>> On 6 Jan 2021, at 12:29, Douglas Foster <[e-mail]> 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 <[e-mail]>" <[e-mail]>

DO:
From: "Someone via devil" <[e-mail]>
Reply-To: Someone <[e-mail]>


It seems Mailman is careful enough when it rewrites entries like:
From: "[e-mail]" <[e-mail]>

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