Re: RFC 4408 Errata - PermError on invalid domains after macro expansion

Alessandro Vesely <[email protected]> Tue, 25 Oct 2011 20:33:41 +0200
Newsgroups gmane.mail.spam.spf.discuss
Message-ID <[email protected]>
On 25/Oct/11 15:08, Frank Ellermann wrote:
> On 25 October 2011 14:39, Scott Kitterman wrote:
> 
>> That's a confirmed errata (see the previous
>> paragraph on TempError). When the spec was written,
>> the intent was to reject on PermError as well.  You
>> may not agree with it but your characterization of
>> the intent when it was written is not correct.

Yes, I don't agree with that.  That's why I surmised it wasn't the
intent of the spec.  It would have made sense if it had specified,
say, StaticPermError (the RR) and DynamicPermError (the ids).  I don't
think we can revert to such state now.

> The main thing is to _document_ the correct SMTP code
> IF something is rejected.  The spec. does nowhere say
> that rejecting is REQUIRED, and IIRC it only goes so
> far to say that rejecting FAIL is RECOMMENDED.

Because "RFC 4408 deliberately steered clear of trying to specify
receiver policy", considering the possibility to reject is tantamount
to suggesting such behavior.  I'd agree if it were documented clearly
and without false idiosyncrasies what is the intended semantics.  For
example, the text could say

   If the message is rejected during the SMTP transaction because of
   this reason --which is NOT RECOMMENDED-- then the software SHOULD
   use an SMTP reply code of 550 and, if supported, the 5.5.2 DSN
   code.

Better yet, I would add to /each/ subsection 2.5.1..7 a pedantically
prominent statement of the form

   The checking MTA <RFC 2119 KEY WORD> reject an SMTP transaction
   based [solely] on this result / unless there are other reasons.

I'd propose to check what's the consensus on this.  Just how far we
are from one another, after six years[*].  Obviously, it would be much
better to know how actual MTAs are configured, but I have no idea how
to run such survey.  The following are IMHO-values (that is, how I
think they are in the wild --not how I'd like them to be documented):

       2.5.1.  None . . . .  MUST NOT
       2.5.2.  Neutral  . .  MUST NOT
       2.5.3.  Pass . . . .  MUST NOT
       2.5.4.  Fail . . . .  SHOULD
       2.5.5.  SoftFail . .  SHOULD NOT
       2.5.6.  TempError  .  MUST NOT (but MAY reply 4xx)
       2.5.7.  PermError  .  SHOULD NOT

Section 1.3 mentions 10 key words, so there are 10^7 total
possibilities, but I'd expect no more than two or three will be upheld
by multiple participants.

-- 
[*]
http://www.gossamer-threads.com/lists/spf/discuss/19770?do=post_view_threaded