<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 1/31/2012 11:14 AM, David Woodhouse wrote:
<blockquote
cite="mid:1328026468.2046.367.camel@shinybook.infradead.org"
type="cite">
<pre wrap="">On Tue, 2012-01-31 at 15:59 +0000, Michael Adkins wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This is unnecessary. DMARC doesn't need options to disable the
consideration of individual underlying authentication technologies.
</pre>
</blockquote>
<pre wrap="">
You've trimmed and ignored the example I gave, in which it *was*
necessary. Without some way to be sure that he won't be rejecting mail
due to SPF's forwarding fallacy, Fred (my hypothetical administrator)
will not be willing to implement DMARC on the receiving side.
Yes, he can reject mail from sites which use DKIM and don't have an SPF
record at all. But if a sending site *does* have an SPF record, even
though they also DKIM-sign all their outbound email, then Fred won't be
able to reject mail that comes in without a DKIM signature.
Do not conflate the rôle of the sending domain and the receiving domain
admins. The *sending* domain may be happy to publish an SPF record
listing their own mail hosts and then '-all'. But the *recipient* may
refuse to reject on those grounds, for reasons which have been discussed
at length elsewhere.
If we want to harmonise recipient policy, surely it makes sense to find
a way to persuade those recipients (like Fred) that is is *safe* to
reject mail that fails the policy?
</pre>
</blockquote>
<br>
I believe that I understand your question/concern, but I am not
sure. Is this close?<br>
<br>
Fred uses a black box domain authentication system that returns a
simple DMARC result of pass or fail with no ability for Fred to
access the 'facts' behind the result. Therefore any pass is a pass
(in the example, SPF pass overrides DKIM fail, but Fred doesn't know
this). <br>
<br>
If that is the case, then I can certainly agree with you. Somebody
in the network room at dkimonly.com sets up an 'always true' SPF
record on a lark and all of a sudden mail purporting to be from
dkimonly.com, signed or not, can come into Fred's domain and there
would be nothing that Fred can do to stop it.<br>
<br>
Fred's customers will, naturally, blame Fred. Fred will not be a
happy camper.<br>
<br>
If Fred needs to protect his customer base to a greater degree than
the DMARC standard is calling for, then, IMO, it is incumbent upon
Fred to ensure that he retain access to all of the pertinent facts
he needs to make the pass/fail decision on his own. <br>
<br>
Assuming my re-statement of your concern is somewhere close to
correct, I believe that the first paragraph of section 7 addresses
Fred's responsibility to his customers.<br>
<br>
<pre>7. Policy Enforcement Considerations
Mail Receivers MAY choose to reject or quarantine email even if email
passes the DMARC mechanism check. The DMARC mechanism does not
inform Mail Receivers whether an email stream is "good". Mail
Receivers are encouraged to maintain anti-abuse technologies to
combat the possibility of DMARC-enabled criminal campaigns.</pre>
<br>
John Kelley<br>
AOL<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:1328026468.2046.367.camel@shinybook.infradead.org"
type="cite">
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">This body part will be downloaded on demand.</pre>
</blockquote>
</body>
</html>