[spfbis] Issue: "Permanent" Temporary errors

Scott Kitterman <spf2@kitterman.com> Fri, 03 February 2012 22:47 UTC

From: Scott Kitterman <spf2@kitterman.com>
To: spfbis@ietf.org
Date: Fri, 03 Feb 2012 17:47:00 -0500
Message-ID: <7863221.PHTaGIf0LX@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; )
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Subject: [spfbis] Issue: "Permanent" Temporary errors
Precedence: list

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.

Scott K

Re: [spfbis] Issue: "Permanent" Temporary errors Stuart D Gathman
[spfbis] Issue: "Permanent" Temporary errors Scott Kitterman