[dmarc-discuss] RFC5322.From different from sender domain

[Douglas Otis]

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.
Dear Elizabeth,

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.

See http://dmarc.org/draft-dmarc-base-00-01.html#receiver_domain

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.

For example,
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. ;^)

Regards,
Douglas Otis