[Discuss] DMARC issue, Yahoo and beyond

[Tom Metro]

Edward Ned Harvey (blu) wrote:
> Apparently yahoo recently set their DMARC policy to reject...
> 
> It seems, the solution is to enable "from_is_list" so the message
> will actually send "From: Edward Ned Harvey via The List" and
> "Reply-To: Edward Ned Harvey <myemail at nedharvey.com>" 

Richard Pieri wrote:
> Insert "Reply-To Munging Considered Harmful" rant here. Not that the
> folks at DMARC.org care; they're a rogue body.

So the gist of the problem is that DMARC is asserting that mail from a
particular sender should be originating from certain servers, and unlike
SPF (also part of DMARC, but not the part causing problems), this looks
not at the envelope sender address, but the RFC822 message headers.

Certainly mailing lists weren't an unheard of concept for the DMARC
designers, so what provision did they have in mind for dealing with this
situation? Rewriting the From address sure seems like a clumsy and
antiquated way of addressing this.

Probably as far back as the first revision of RFC822 there has been a
provision for a Sender header to identify relaying parties. Is it not
possible for the mailing list to generate new DMARC headers (DKIM
signature) that are tied to Sender, leaving the original From untouched?


Some of this seems to come down to philosophy: do you consider a mailing
list to be a transparent relay, like any other SMTP relay server, or as
a first-class sending party?

If it is a relay, then it should pass on the message with the absolute
minimum modification (like adding some Received headers and a List-ID
header). It should take ownership only of the envelope, and not the
contents. And when you receive such relayed mail, you are limited to
anti-spam measures that only link the envelope to the sending server.
You can't try and correlate the message headers to the sending server.

If it is a first-class sending party, then the list server takes
responsibility for the message. That includes doing adequate anti-spam
filtering before accepting it. And that means signing the message. I'm
extending trust to the list server and I want assurance that the
messages came from the list server.

I'm not following why there isn't a DMARC provision to address this
latter case that doesn't require altering the user-visible appearance
and behavior of the message.


According to:
http://dmarc.org/faq.html#s_3
the answer seems to be, sadly, no. They proposed an
Original-Authentication-Results Header:
http://tools.ietf.org/html/draft-kucherawy-original-authres-00
which was never widely adopted, and the above FAQ suggests would likely
be used as a loophole for spammers.

DKIM has provisions for specifying the headers that are covered by the
signature, such as:
    h=Received : From : To : Subject : Date : Message-ID;
but regardless of that it seems like DMARC mandates that "the domain in
the From header must match the domain in the "d=" tag in the DKIM
signature..." if "DKIM alignment" tag is set in DNS.

Generally, DKIM seems to offer lots of flexibility. Who signs the
message and what headers are signed is up you. In contrast, when you use
DKIM to comply with DMARC, it seems like most of that flexibility is
taken away.

I gather the thought process behind this is that they want DMARC to be
able to assert that the From address isn't forged and was handed to your
MTA by a server authorized for originating mail for that domain,
connecting not just the envelope, but the message body to the server.
Although this could trivially be applied instead to the Sender header,
the contents of the Sender header isn't shown in mail clients, and I
suppose they are trying to look out for neophyte users who can't examine
headers. A way to prevent phishing.

But DMARC is the wrong tool for providing assurances to the end user of
authorship. (This seems to be exactly what Yahoo is attempting to do
with their recent policy change.) That's far better handled by an
end-to-end tool like S/MIME.

If there are many legitimate reasons for a From header to be different
from the message sender, does it make sense to design a system that
assumes any mismatch represents a forgery?

Looking at the problem from the DMARC designer's perspective: if you
permit list servers to sign a Sender header, while passing on a "forged"
from header, how do you distinguish that from a regular forged message
from a spammer?

Any spammer acting in compliance with DMARC - even if they are sending
forged messages - is going to be doing a lot more work (setup, and
signing messages) and exposing a lot more information through DNS (DMARC
and SPF records), so at minimum you have more tools to identify and
block a bad actor. (The same rationale applied to SPF and even more so
here.)

But it seems like what they really want is a way to put an intermediary
envelope around the message. Something that permits mailing list
managers to alter subject lines, add footers, and sign the container,
while leaving the contained message unaltered, with a signature that
validates not only some headers, but the body of the message as well.
Accommodating this would require altering mail clients.

(There may be intermediary compromises. Have DMARC only require the
originating DKIM signature cover the body and From, but not tie it to
the envelope. Have a separate sender DKIM header for that, which could
be replaced when a list server processes it. The sender would be
permitted to add additional MIME parts, leaving the original body
unaltered, and rewrite headers not covered by the originating DKIM
signature. The sender signature would cover the Sender header, which
would "align" with the envelope, and the original and additional body
parts. That way the worse a spammer could do (acting as a sender) is
take an existing message and tack advertising or fraudulent attachments
onto it.)


Here's a work around: modify Mailmain to send all list messages as
digests. Digests containing only one message. Providing you have a mail
client that automatically "explodes" digests, you convey the DMARC
failing message past the MTA checking the DMARC validity. Once received
by your client and "exploded" out of the digest, it's just an ordinary
message.

 -Tom

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/