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