[dmarc-discuss] RFC5322.From different from sender domain
dotis at mail-abuse.org
Thu Mar 29 17:52:24 PDT 2012
On 3/29/12 4:13 PM, Elizabeth Zwicky wrote:
> We seem to have lost a lot of context here. The original context was that somebody pointed out
> that you could, from almost any provider, send mail from an email address at another
> provider and the result was a legitimate message that
> passes DKIM and fails DMARC, how could that be fixed? (The DMARC answer to this
> is that it’s a problem DMARC isn’t trying to address, don’t turn on enforcement for
> domains containing real users.)
> Somebody else suggested that it could be fixed with RFC 6541, which would allow Provider A to say
> “Why yes, if Provider B signs a message with our domain on it, you should treat it just as if we signed it.”
> Or vice versa. To which I replied, expressing a non-official opinion that voluntarily airborne pigs are
> just as likely a solution to this question. I did not express an official or non-official opinion that
> Google/Yahoo/your favorite provider was going to refrain from sending mail with the other’s
> From: addresses. Or that 6541 was in any way deficient as an idea in itself. Or, in fact, that the
> existence of legitimate mail that passes DKIM and would fail DMARC if you turned it on is bad.
> Yes, Yahoo! will sign mail with Gmail addresses on it. No, Google did not certify that such mail
> was just as good as mail from Google with Gmail addresses on it, nor do I think they are likely to.
> Yes, there are other questions which 6541 would answer. It’s not clear to me what DMARC
> should do about that; 6541 changes what you consider to be a DKIM pass/fail, DMARC only
> cares after you’ve decided whether DKIM passed or failed.
Please allow me to disagree with these statements. DMARC imposes
_additional_ requirements on valid DKIM signed messages beyond just
signature alignment with domains seen in the From header field.
The impact of ATPS is to mitigate false positive spoofing detection
issues that may cause large providers to ignore DMARC results. When a
domain imposes restrictive DMARC records and then also decides to send
messages through mailing lists, some may expect such use will not cause
problems. With restrictive DMARC in place, it will.
ATPS does NOT alter validity of first party (Provider A) signatures.
ATPS offers a means to authorize specific third-party signatures to
mitigate cases where message acceptance is desired, but problematic as a
result of DMARC assertions. ATPS can be as broad or as selective as
senders desire. Senders expecting strict enforcement of DMARC must be
pragmatic and ensure actions of their users will not trigger support
calls for domains they expect to enforce their DMARC policies. Using
ATPS to authorize a different domain will not obfuscate who signed the
message, unlike the only other method available.
Including a visible method for domains to assert affiliations should
also provide significant advantages.
Imagine how recipient perceptions could change when they know DMARC is
enforced by their provider and that it permits multiple From email
addresses as a method to assert affiliations.
From: accounts at big-bank.com, big-bank.com at members.fdic.gov
In this case, big-bank.com DKIM signed the message, and members.fdic.gov
authorized their signature. For DMARC both addresses should be valid.
Intelligent filters and users will soon understand the meaning of this
affiliation assertion that can be ushered in by DMARC. ;^)
More information about the dmarc-discuss