Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Feb 2012 12:04:24 -0800

At 12:56 07-02-2012, spfbis issue tracker wrote:
>#1: RFC 4408 Section 2.5.6 - Temporary errors
>
>  Message from Scott Kitterman on 3 Feb 2012:
>
>  TempError is defined in RFC 4408 as:
>
>  2.5.6. TempError
>
>
>     A "TempError" result means that the SPF client encountered a
>     transient error while performing the check.  Checking software can
>     choose to accept or temporarily reject the message.  If the message
>     is rejected during the SMTP transaction for this reason, the software
>     SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
>     code.
>
>  This is further specified in the check_host() definition:
>
>  4.4. Record Lookup
>
>
>     In accordance with how the records are published (see Section 3.1
>     above), a DNS query needs to be made for the <domain> name, querying
>     for either RR type TXT, SPF, or both.  If both SPF and TXT RRs are
>     looked up, the queries MAY be done in parallel.
>
>     If all DNS lookups that are made return a server failure (RCODE 2),
>     or other error (RCODE other than 0 or 3), or time out, then
>     check_host() exits immediately with the result "TempError".
>
>  Particularly when querying for SPF records of type SPF, persistent 2
>  ServFail
>  results are not rare.  It is my impression that ServFail is a condition
>  that
>  generally will require operator intervention to correct.
>
>  The definition of PermError is (partly):
>
>  2.5.7. PermError
>
>
>     A "PermError" result means that the domain's published records could
>     not be correctly interpreted.  This signals an error condition that
>     requires manual intervention to be resolved, as opposed to the
>     TempError result.
>
>  I think that RCODE 2 replies should be considered PermError instead of
>  TempError.
>
>  The operational impact of this is that messages are deferred (4xx) instead
>  of
>  rejected (5xx) so they sit in a deferral queue and are retried for however
>  long the sending MTA is configured to attempt it.  The user of the message
>  isn't notified of the non-delivery until it expires out of the queue,
>  generally
>  after several days.
>
>  In the SPF policy server for Postfix that I maintain, I changed the
>  default
>  action on TempError from defer as a result of this issue.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html

>Ticket URL: <http://trac.tools.ietf.org/wg/spfbis/trac/ticket/1>

Issue #1 is open for discussion.  Please review the above and post 
your comments to this mailing list.  As a reminder, please keep the 
subject line so that it is easier to track the discussion.

Regards,
S. Moonesamy
SPFBIS WG Chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Feb 2012 08:02:46 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Wednesday, February 22, 2012 12:04 PM
> To: [email-masked]
> Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors
> 
> >  I think that RCODE 2 replies should be considered PermError instead
> > of  TempError.
> >
> >  The operational impact of this is that messages are deferred (4xx)
> > instead  of  rejected (5xx) so they sit in a deferral queue and are
> > retried for however  long the sending MTA is configured to attempt it.
> > The user of the message  isn't notified of the non-delivery until it
> > expires out of the queue,  generally  after several days.
> >
> > default  action on TempError from defer as a result of this issue.

I'm not sure I agree with this.  The definition of SERVFAIL (which is RCODE 2) from RFC1035 is:

                2               Server failure - The name server was
                                unable to process this query due to a
                                problem with the name server.

That's plenty general.  Absent a list of specific reasons why a nameserver might return that error, I'm left not knowing whether the error is transient (resources, perhaps) or one that does indeed require operator intervention.

So perhaps Andrew is in a good position to answer this, hatless of course: Has there ever been more specific guidance about the use of SERVFAIL, or perhaps the introduction of other RCODEs, to make this less ambiguous?

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Feb 2012 09:28:53 -0500

Murray S. Kucherawy wrote:
>> Scott Kitterman
> That's plenty general.  Absent a list of specific reasons why a 
> nameserver might return that error, I'm left not knowing whether the 
> error is transient (resources, perhaps) or one that does indeed 
> require operator intervention.

+1,  SERVFAIL is not always a "permanent" failure concept and it could 
just mean the DNS resolver was just not available for whatever 
reasons, including for smaller system being throttled by their ISP. 
It could be self-correcting as well.

But one thing I have learned (across the board for all DNS related 
application level protocols) is that results and application protocol 
translations of results was a fine tuning concept for the default 
configuration and for the most part, items initially prepared as too 
restrictive changed to a more relaxed translation.

I view this as prudent design for SPF systems deployed for SMTP level 
policy based failure detection for instant rejection.  For these modes 
of operations, it needs to be watchful of using restrictive results 
that are not really zero false positive.

I believe SPF-BIS (if not already written somewhere), it should add 
text that recommends flexibility for SPF. For example:

     SPF implementators MUST|SHOULD|MAY make the translation and 
interpretation of
     results configurable  and flexible for operators.

     SPF implementation SHOULD|MAY be watchful repeated error 
conditions from
     a domain and MAY use repeatably failure to translate temporary errors
     to permanent errors.

IMV, this issue falls in the category of Implementators design 
offerings, but I think it would not be improper to have the above like 
text added to section because I believe you will get different valid 
views on how check_host() is designed Murray.

For example, check_host() does require a internal "results" in order 
to generate the returned result. For me, because I do have a very 
strong deterministic framework philosophy looking for the definitive 
domain declared policy violation, anything less than 100% definitive 
internal results due to NXDOMAIN, SERVFAIL or other unexpected 
exception, our check_host() will basically return a "Unknown" or 
"Nothing here" translation. Hence a "I don't know" go ahead 250 for 
the most part, but perhaps even 45x - it depends.

This note, how to translated repeated errors that is was always 
something on my mind, hence why I already asked for the protocols that 
had a testing bit in its policy to either remove it in the spec spec 
or add monitoring logic semantics. I don't recall if SPF had one, seem 
to remember it did but I may be confusing that with the same request I 
did for DKIM, and why it says:

       y  .... Verifiers MAY wish
          to track testing mode results to assist the Signer.

but I wasn't thinking about assisting the sender, but assisting the #1 
victim, the receiver, in this case the SPF receiver, who would be 
getting these redundant errors, including temporary ones.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 10:33:02 -0500

On Thursday, February 23, 2012 08:02:46 AM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of S Moonesamy Sent: Wednesday, February 22, 2012 12:04 PM
> > To: [email-masked]
> > >  I think that RCODE 2 replies should be considered PermError
> > >  instead of  TempError.
> > > 
> That's plenty general.  Absent a list of specific reasons why a nameserver
> might return that error, I'm left not knowing whether the error is
> transient (resources, perhaps) or one that does indeed require operator
> intervention.
> 
> So perhaps Andrew is in a good position to answer this, hatless of course:
> Has there ever been more specific guidance about the use of SERVFAIL, or
> perhaps the introduction of other RCODEs, to make this less ambiguous?

In order to try and get a handle on this question, I asked an associate who is 
very familiar with BIND internals about when it would return SERVFAIL.  It 
turns out it is a mix of temporary (self-resolving) and permanent (needs 
operator resolution) conditions, so SERVFAIL doesn't neatly map into either 
SPF result.

Examples of temporary SERVFAIL are:

Unable to connect with the authoritative resolver due to a network outage.

A difference in TTL between glue A records and NS records in a delegation.  If 
the A records are /all/ required glue (ends with the zone name) and the TTL on 
them is shorter than the NS records, they will get flushed from cache before 
the NS records and thus give SERVFAIL until the NS records timeout.  So in 
that scenario, resolution by others will experience SERVFAIL for periods of 
time regularly.

Examples of more permenant SERVFAIL are:

Firewall misconfiguration (permanently preventing access to an authoritative 
resolver).

Name server misconfiguration (e.g. broken zone file)

Failed to pay bill for DNS services

Based on that feedback, I don't think it's appropriate to call SERVFAIL a 
permanent error on a general basis as I originally proposed.  OTOH, the 
operational problem with permanent (long term) SERVFAIL is a real one.

I don't know what the best solution is, but perhaps it can be addressed.

My initial thought is to allow (but not require) receivers to track SERVFAIL 
based temperrors and if they persist for more than $PERIOD (let's start the 
bidding at 24 hours) then future consectutive SERVFAIL responses for that 
domain MAY be considered permanent errors.  

I would also say that receivers that are going to defer message acceptance 
based on SPF temperror SHOULD do this (the spec should not take a position on 
the decision to implement defer on SPF temperror or not, just on how to do it 
if that's the receiver policy).

I propose it as a MAY because I think it's only really important for the defer 
on temperror case and I don't think we want to force additional complexity 
into the mandatory parts of the protocol without a strong reason.

If this (or something like it) were included in 4408bis, I would implement it 
because it would allow me to restore defer on temperror as a system default (I 
disabled it by default in 2007 after user complaints about long duration 
temperrors due to SERVFAIL).

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 11:33:17 -0500

No hat.

>                                 problem with the name server.

I agree with Murray: RCODE=2 is not a permanent error in the DNS.
 
> So perhaps Andrew is in a good position to answer this, hatless of
> course: Has there ever been more specific guidance about the use of
> SERVFAIL, or perhaps the introduction of other RCODEs, to make this
> less ambiguous?

The reason it's not specific is because there could be just about
_any_ reason why you get RCODE=2.  

Scott mentioned downthread the case where you have an in-cache NS set
and no glue records to get you there.  But there are lots of other
cases.  For instance, some authoritative servers will respond SERVFAIL
while loading a zone.  Different implementations respond with SERVFAIL
for different reasons.  A validating resolver will respond with
SERVFAIL if the DNS response is not validatable and CD=1 is not set on
the query.  And so on.  Some of these could be transitory (many are)
and some could be permanent (the server is broken, for instance).

When dealing with DNS, I'm usually very reluctant to call an error
permanent.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Feb 2012 12:29:29 -0500

> When dealing with DNS, I'm usually very reluctant to call an error

+1.

Yet, for the same reasons why SMTP outbound mail queuing and retry 
methods vary to a wide agree, the translation of all result should be 
a local policy and IMV codified in the SPF-BIS spec as an item for 
flexible configuration for implementation to consider.

A principle reason is the idea of controlling redundancy. i.e. a 
domain is exhibiting a history of perpetual temporary errors. At some 
point, a local policy may include a rule to translate this to to a 
permanent condition.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Feb 2012 20:29:48 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Friday, February 24, 2012 7:33 AM
> To: [email-masked]
> My initial thought is to allow (but not require) receivers to track
> SERVFAIL based temperrors and if they persist for more than $PERIOD
> (let's start the bidding at 24 hours) then future consectutive SERVFAIL
> responses for that domain MAY be considered permanent errors.

Given that the IESG recently approved publication of the V6OPS working group's draft known as "Happy Eyeballs", which provides guidance for an application to remember the results of simultaneous IPv4 and IPv6 operations and optimize based on that, this seems like something worth considering.  I don't know about normative guidance, but an informative-only appendix might be useful.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Feb 2012 20:47:15 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Murray S. Kucherawy
> Sent: Friday, February 24, 2012 12:30 PM
> To: [email-masked]
> Given that the IESG recently approved publication of the V6OPS working
> group's draft known as "Happy Eyeballs", which provides guidance for an
> application to remember the results of simultaneous IPv4 and IPv6
> operations and optimize based on that, this seems like something worth
> considering.  I don't know about normative guidance, but an
> informative-only appendix might be useful.

In case someone wants to see what I'm referencing:

http://datatracker.ietf.org/doc/draft-ietf-v6ops-happy-eyeballs/

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Feb 2012 07:24:15 +0000

> [...]

Happy eyeballs aside, has anyone in the SPF community, or any similar application for that matter, tried something like this?  Any results from which we can learn?

If so, it seems like we should consider adding some informative guidance based on experience.  I contend that's within charter, because it's not changing the specification itself, and is aimed at providing improved interoperability.

If not, then perhaps the collected experience about this and the RR type discussion might be input to an applicability statement that someone writes somewhere down the road, either individually or after a re-charter.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 25 Feb 2012 02:29:50 -0500

On Saturday, February 25, 2012 07:24:15 AM Murray S. Kucherawy wrote:
> > Of Scott Kitterman Sent: Friday, February 24, 2012 7:33 AM
> > To: [email-masked]
> Happy eyeballs aside, has anyone in the SPF community, or any similar
> application for that matter, tried something like this?  Any results from
> which we can learn?
> 
> If so, it seems like we should consider adding some informative guidance
> based on experience.  I contend that's within charter, because it's not
> changing the specification itself, and is aimed at providing improved
> interoperability.
> 
> If not, then perhaps the collected experience about this and the RR type
> discussion might be input to an applicability statement that someone writes
> somewhere down the road, either individually or after a re-charter.

I'm not aware of anyone trying it.

I know I got complaints about emails being stuck in a mail queue for 5 days 
when I was doing defer on temperror.  This seems like a reasonable way around 
that problem.  Due to long term temperror the general view in the community 
was that we couldn't recommend defer on temperror.

Up until this discussion, I thought the solution was treating SERVFAIL as a 
permanent error, but now I see that isn't a good idea, so I proposed this as a 
conceptually straightforward (if someone complex to implement) method for 
solving the problem.

I can take a stab at code if it would help with getting it accepted.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 29 Feb 2012 12:56:55 -0800

Hello,

I'll attempt to summarize the discussion of Issue #1.  If I 
misinterpreted or misunderstood your comments, please let me know.

Murray S. Kucherawy mentioned not knowing whether the (SERVFAIL) 
error is transient (resources, perhaps) or one that does indeed 
require operator intervention [1].

Andrew Sullivan, as a participant, agrees that RCODE=2 is not a 
permanent error in the DNS [2].  Hector Santos agreed with Andrew Sullivan [3]

Scott Kitterman mentioned that he would like to allow (but not 
require) receivers to track SERVFAIL  based temperrors and if they 
persist for more than $PERIOD (let's start the bidding at 24 hours) 
then future consectutive SERVFAIL responses for that domain MAY be 
considered permanent errors [4].  He also mentioned that until this 
discussion, I thought the solution was treating SERVFAIL as a 
permanent error, but now I see that isn't a good idea, so I proposed 
this as a conceptually straightforward (if someone complex to 
implement) method for solving the problem [5].

The issue was open based on the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html  My 
opinion is that we can come to an intermediate conclusion on this 
issue based on what we know at this point in time.  I will read the 
entire messages (some of them are not referenced in this message) 
posted about Issue #1 again and any feedback you provide before 
discussing the question with my co-chair and reaching a 
conclusion.  Any conclusion is intermediate in the sense that the 
working group will be asked to comment on the WG drafts listed as 
deliverables and there will be ample opportunity to review the conclusion.

I have been asked what "Hold for document update" means.  The working 
group does not have any WG draft up for discussion yet.  When there 
is a WG draft, the working group can discuss about the exact text 
that goes into it.

Regards,
S. Moonesamy
SPFBIS WG co-chair

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00569.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00590.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00591.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00589.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00631.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Feb 2012 21:00:57 +0000

> Sent: Wednesday, February 29, 2012 12:57 PM
> To: [email-masked]
> Cc: Andrew Sullivan

Your summary seems right to me.  I would also point out that this is probably going to be at best a MAY, and also suggest we include a reference to the Happy Eyeballs draft out of the v6ops WG because they proposed something similar to what Scott suggested, and it's in the RFC Editor queue now, so it appears to have precedent for not being a completely crazy idea.

-MSK