DMARC: A solution using ATPS RFC6541 extension

[Hector Santos <[e-mail]>]

Alessandro,

There is still a status quo between the two different camps; one that 
believes in a policy framework and one that doesn't. It really has 
nothing to do with technical issues because they all has been already 
worked out. But rather an unwillingness to even acknowledge policy 
existence.

That approach has not worked and it was predictable because it was 
always a fallacy to believe that strict policies were limited to 
certain use cases and certain domains. It provided a flawed rationale 
and basis to allow DKIM resigning by ignoring policy with the 
acceptability of a limited damage.

The DKIM RFC6376 preferred method of looking up the signer domain has 
simply failed to materialize in the market place.  And even if it did, 
it would still not address the filtering of the obvious protocol 
expected faults resulting from legacy mail operations and adapting 
spoofers.  In other words, via policy, if you raise the "expectation bar":

    Does this domain send any mail?
    Does this domain always sign its own mail?
    Does it allow others to sign freely?
    Does it allow authorized resigners?

The first two could be ignorant spammers who don't have a clue about 
new 5321/5322 methods. Its getting by with a legacy SMTP mode of 
operation.   The last two helps to deal with those spammers that may 
adapt and try to "fake" out the receivers with unchecked DKIM signatures.

These and other similar questions are real DKIM situations the signer 
domain trust model can not answer.  You can only get this info from 
the author.  Even if the signer domain was used, it would need to 
still reflect the author domains intent and authorization for resigning.

None is this is new. Many documents were produced. But we didn't have 
the full IETF DKIM project leaders support and endorsement to finish 
up ADSP.  Levine refused to fix/update ADSP despite all the interest 
to do so.  It was an unfortunate mistake for the DKIM WG chairs and 
Ads to allow this lack of ADSP engineering leadership situation to 
occur.  The chairs and ADs were clearly aware there was a concern and 
also the threat of appeal.

Anyway, the available solution is still very simple. Given all the 
work already explored, DMARC needs an ATPS extension.  ATPS piggy back 
off the ADSP record.  We can just update ATPS to piggy back of the 
DMARC record.  I already started this using my idsg.net DMARC record:

_dmarc TXT ("v=DMARC1; p=reject; atps=y; rua=mailto:[e-mail];" )

The atps=y tag tells the compliant DMARC+ATPS receiver to do an 
authorized third party signature check against the DKIM-Signature "d=" 
signer domain.  I have an _atps record for ietf.org:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT	( "v=atps01; d=ietf.org;" )

So in theory, when ietf.org breaks and resigns my isdg.net list 
submissions, any download DMARC+ATPS receivers can see that isdg.net 
authorizes ietf.org to resign list mail from isdg.net.  I already 
began to modify our WCADSP Wizard web site for DMARC:

      http://winserver.com/public/wcdmarc

It is pretty much done with the backend scripts updated to create 
DMARC records. I am just playing/cleaning the FORM UI, single sourcing 
it for mobile/tablet UI.

Of course, it all means nothing without further support for ATPS.  It 
provides an OUT for YAHOO and AOL to get a resigner whitelist using 
ATPS records.  If they can support this simple extension to DMARC, 
then we would be headed in the right direction for all parties.  Even 
if the certain LIST operators continues to refuse to support policy, 
at the very least, the download receivers would be able to handle it 
better by checking for the list signer domain authorization.

Without the support, you can see the attached dmarc-gmail-warning.png 
image where the GMAIL mail reader (via my iPAD) shows a warning for 
the unauthorized 3rd party signature DMARC failure.  A simple ATPS TXT 
lookup for:

     base32(sha1("ietf.org"))._atps.isdg.net

would of addressed this problem.

---
HLS

On 5/16/2014 9:48 AM, Alessandro Vesely wrote:
> On Thu 15/May/2014 17:13:05 +0200 Dave Crocker wrote:
>>

>>    2.  There is nothing that requires mailing lists to make adjustment.
>> Arguably, it is better for mailing lists NOT to make adjustments, so
>> that those affected users can consider the efficacy of their current
>> account.
>
> I'm disappointed.  I know p=reject, like dkim=discardable before it,
> was meant to be used by domains that "don't have individual human
> users".  I cannot help comparing it to SPF's -all.  In fact, DMARC's
> overview[1] suggests that the monitoring step be followed by policy
> adjustment.  Looking at DMARC reports, one can guess whether an
> authentication failure originates from abuse or from a possibly
> forwarded mailing list post.  Setting a strict policy would kill both.
>   OTOH DMARC is perfectly useless with p=none.
>
> What does it take to set up a "human" domain, then?  It's way harder
> than a web site.  Several organizations give up working out their own
> way to configuring a mail server.  Google do an excellent job at
> filtering.  Besides marking as spam and email authentication, they
> deploy literally hundreds of signals, whose relative importance is
> dynamic and determined on complex algorithms[2], which are definitely
> beyond the reach of an average company with a smallish IT dept.
>
> Now, being forced to outsource email has obvious privacy issues.  I
> want to ask whether the onset of giant, all-monitoring, central email
> plants is part of "the basic design assumptions of Internet email".
> If not, we ought to consider putting the restoring of a well-defined,
> simple email functionality among the Internet 2020 goals.  Can DMARC
> generalization be regarded as a spontaneous move in that direction?
> It requires adjustments in mailing lists and other niches such as WSJ
> send-an-article and gmail sending.  But what are the alternatives?
>
> Ale
>
> [1] How Senders Deploy DMARC in 5-Easy Steps, bottom section in
> http://www.dmarc.org/overview.html
>
> [2] summary of a talk with Sri Somanchi on Gmail's Anti-Spam Team
> http://www.campaignmonitor.com/blog/post/4196/gmail-focus-on-engagement
>
>
>