On 12/22/2014 08:02 PM, Scott Kitterman wrote:
On Monday, December 22, 2014 12:40:36 PM Franck Martin wrote:
----- Original Message -----
From: "Scott Kitterman" <skl...@kitterman.com>
To: dmarc@ietf.org
Sent: Monday, December 22, 2014 7:44:04 AM
Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote:
Colleagues,
draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's
been
pointed out that a review from back in April has not been properly
attended
to.
Could I get the WG (forgive me, co-chairs!) to comment on this so that I
can see what changes might be appropriate here? Having this resolved
before the telechat in the first week of January would be truly
delightful.
Note that some amount of this may have already been addressed (it was
about
-04; -08 is current, and at least the ABNF issue Jim raises will be
handled
in -09), so please at least check -08 when considering your responses.
The posting:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html
There was a recent thread on postfix-users about DMARC rejections when
there are DNS errors that caused me to review -08 to see what it says on
the matter.
At the end of section 5.6.2, it says:
Handling of messages for which SPF and/or DKIM evaluation encounters
a DNS error is left to the discretion of the Mail Receiver. Further
discussion is available in Section 5.6.3.
My reading of 5.6.3 though is that it only discusses DNS errors in the
context
of failing to retrieve the DMARC record. Any discussion about handling
DNS
errors for SPF/DKIM seems to be missing.
I had a few issues with a large sender, which had their TXT record
overloaded (not uncommon, this is where google analytics and other wants to
prove who you are). Combined with a low TTL, it would happen rarely, but
frequently enough that an SPF could not be assessed and DMARC would fail.
The fallback mechanism in bind is slow when you have edns issues.
1) I wished that SPF record location would have been _spf.<domain name>
2) may be here the recommendation, is that with DMARC it is best to tempfail
an email if you can’t get an SPF result due to DNS (same with DKIM), rather
than carry on and pass the result to higher policy layers.
The underscore location was considered at the time, but in 2004 we believed
that it would have created a significant barrier to deployment since many
tools/service provider control panels at the time didn't allow it. It would
certainly be better now, but as with type SPF, there's no transition
mechanism. If we were going to transition SPF records anywhere, it would have
been better to do it to the new RR type.
Both SPF and DKIM do have a temporary error state, so it's certainly possible
to include this. I think it's totally up to the receiver if they choose to
defer (45X) or choose not to use DMARC in case of a temporary error in one of
the underlying protocols (i.e. SPF or DKIM) making it impossible to make a
complete DMARC evaluation.
Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a
temporary error in SPF or DKIM processing prevents a full evaluation."
+1
/rolf
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
