Counterpoint: Mailing lists often break PGP/MIME, either by eating signature attachments or by modifying the message text (e.g., by adding a mailing list footer).
This is why FreeBSD consistently uses inline signatures for release and security announcements -- it maximizes the probability that a message can be validated.
True. The email community ought to put more thought into the interaction between email auth technology and email lists or email forwarding. Lists or forwarding can break DKIM and DMARC, for example. Yahoo users ran into trouble earlier this year when Yahoo enabled DMARC strict mode [1].
Idea: perhaps a way to allow forwarders to wrap existing content with a header, footer, or quoting, such that the receiving client displays the parts consecutively, but can reason about them independently. A bit conceptually like iframes. Display the author of each part, perhaps with a visual lock and boundary if signed.
On the other hand, there are adoption obstacles to introducing new email technologies, similar to the obstacles to evolve HTTP / HTML. Furthermore, email lacks as strong a steering leadership as browser vendors provide in the website space, and the market is more fragmented than the browser market is (varieties of webmail clients with differing display and validation capabilities). Since sensitive information is sent through email less commonly than through web browsers, there appears to be less demand and less genuine interest in email security technology than website security technology, making the adoption challenge for security technologies even harder. Although support for SSL in email delivery is rising [2], most delivery connections are protected by opportunustic TLS (which has many known weaknesses). A good starting point would be a widely-adopted standard for receiving domains to declare that they support TLS and perhaps pin their certificate, so that senders can require TLS.
Mailing lists don't break DMARC: the stupid concept of DMARC breaks DMARC.
I had it going for a while and finally disabled it on my mail domain. It is useless.
I'm not going to sit here collecting DMARC reports and fiddle with mail server settings to set up exceptions for every damned mailing list so that I can one day go into strict mode.
In the end it's good for only one thing: helping to police activities between pairs parties (A and B) not related to me, with my only involvement (non-involvement, really!) being that one of them, B, is misusing my domain name (in a From: header) to write e-mail to A.
I've decided that I don't give a crap about that, and will return to concentrating on filtering spam that actually comes my way. If an actual working e-mail address in my domain is spoofed, and it generates a back-scatter reply from the victim of the spoof that is received in my domain, I will deal with that. What happens between A and B not affecting me in any way isn't my problem.
DMARC helps you most in two situations: (1) you're a person or organization with an Internet presence that's crucial to you, where it's especially harmful for spammers or phishers to trick people by impersonating you (2) You're on the receiving end of the attack.
If I recall correctly, PayPal helped put DMARC together since large numbers of their customers were being phished. "More than 25 million email messages spoofing PayPal were rejected during the 2013 holiday buying season" according to the DMARC site.
I agree that it may not be worth the bother to enable DMARC until there's a lot at stake when protecting your domain. SPF is easier to set up, offers reasonable protection, and is widely adopted. DMARC's best value comes from helping to protect large, important domains, for whom intelligence about impersonation attacks or misconfigurations can be valuable. For the domains that I've helped protect I think DMARC has been worthwhile.
It's also true that DMARC breaks compatibility with common email use-cases like forwarding. However, if we are to move forward in email security, it can't remain possible for every person to originate email claiming to be anyone else, which is what email lists and forwarding do in some cases.
We need a sensible way to take a message from Bob, validly signed by Bob, and wrap it so that I can send it on to you, perhaps with some added content at the beginning and end, or quoted, and additionally signed by me; so that you know the part claimed to be from Bob is really from Bob; and you know that I really forwarded it and wrapped it with my content. If we could solve the forwarding use-cases, I think that would remove the primary bottleneck to adoption.
The minimal bar to setting up DMARC is not high. The monitoring features are optional. A minimal DMARC setup is a policy saying that email from your domain will be authorized by SPF or a DKIM signature; a DNS record with this statement enables receivers to drop email lacking these proofs of legitimacy.
Did you know that SMTP includes no provision to determine whether a sender is allowed to send email from a domain? All anti-impersonation authorization logic has been bolted on later through protocols like SPF, SenderID, DKIM, and DMARC. DMARC is the first protocol to achieve meaningful adoption that protects the "From" address that you see in email clients from impersonation. DMARC is consequently the first protocol to provide an actual guarantee for receivers of the authenticity and integrity of email sent from your domain. Anti-spam systems predominately work around the lack of widespread adoption of these capabilities by correlating lots of factors; I suspect anti-spam would be slightly easier if strong domain-level message authenticity was common (for whitelisting if not blacklisting).
Email could use an evolution in a similar fashion to the recent standard updates for HTTP and HTML.
The information in your paragraph should be the first thing explained on dmarc.org in a FAQ item about who shouldn't bother publishing DMARC.
> We need a sensible way to take a message from Bob, validly signed by Bob, and wrap it so that I can send it on to you, perhaps with some added content at the beginning and end, or quoted, and additionally signed by me; so that you know the part claimed to be from Bob is really from Bob; and you know that I really forwarded it and wrapped it with my content. If we could solve the forwarding use-cases, I think that would remove the primary bottleneck to adoption.
Here is a system that blows away DMARC.
Let's have a DNS record, similar to DMARC's, which is keyed on the From: domain in the same way.
This DNS record provides a URL template. The verifier inserts an item taken from the e-mail into this template and performs a query on the URL. The URL responds with a 200 OK or an error.
What item is inserted into the URL template? A special token which is added to the e-mail by the originating domain in a special header.
This token is a 128 bit number (say). It can be completely random, or it can be a cookie of some kind. What it isn't: it's not a hash over the whole message. Basically what it means is up to the domain. It could contain a crypto hash over some selected headers. (The URL could include a few important headers as URL parameters, like From: and Date: to help the server: and the template language for the URL could be flexible so that the publisher can decide what headers they need in addition to the special token.)
To publish this protection mechanism, your just need this DNS record, a server for the URLs and your mail software to add the tokens to messages.
An example implementation of tokens would be: generate a
random 128 bit number, and store it in a cache that expires in one week. The server just checks whether the number is in that cache.
Numbers which are not validated in any way against headers and whatnot could be replayed by an attacker spoofing your domain. (The attacker receives a legitimate mail, and then uses the token to generate a fake one.)
Protection against this would be: 1) mix information about the additional headers into the token; don't just make it random, and then request these headers in the URL template and check. 2) expire the tokens in a timely way: don't certify stale tokens more than N days old for some reasonably small N. 3) detect abuses of a token, like too many lookups: your mail is not expected to go through 20 hops, so 20 hits on a token is suspicious, right?
> Counterpoint: Mailing lists often break PGP/MIME, either by eating signature attachments or by modifying the message text
That's not "breaking", that's PGP working as designed. The message has been modified from what the sender sent, and so the signature no longer matches, and you can tell it has been changed.
This is why FreeBSD consistently uses inline signatures for release and security announcements -- it maximizes the probability that a message can be validated.