On Monday, December 22, 2014 12:40:36 PM Franck Martin wrote: > ----- Original Message ----- > > > From: "Scott Kitterman" <[email protected]> > > To: [email protected] > > 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." Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
