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:dmarc-rua(_at_)isdg(_dot_)net;" )
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
dmarc-gmail-warning.png
Description: PNG image
dmarc-gmail-warning.png