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

On 10/25/2011 07:57 AM, Alessandro Vesely wrote:
> On 24/Oct/11 22:37, Scott Kitterman wrote:
>>
>> My preference here would be to treat these as PermError since an empty
>> domain-spec is not useful to the protocol and should be an error.
>
> Then PermError can result from both an incorrect SPF record and a
> macro expanded illicit sender identity.
>
>> My solution (note: different than RFC4408 already due to other,
>> non-controversial erratum):
>>
>>>          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.   If the message is rejected
>>>          during the SMTP transaction for this reason, the software SHOULD
>>>          use an SMTP reply code of 550 and, if supported, the 5.5.2 DSN
>>>          code.
>
> I don't think it may gain wide consensus to reject on PermError.  It
> can result from inadvertently getting the syntax wrong, which is
> totally unrelated with a third party acting maliciously.  By removing
> the last sentence above, it is more likely that the intended meaning
> of the spec --reject on Fail-- will be conveyed.

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.  In any case it does not 
advise rejection, just gives advice about how to handle it if you do.

RFC 4408 deliberately steered clear of trying to specify receiver policy 
(there is only one exception to this in the RFC).  The receiver policy 
(reject/don't reject) is a matter for local decision based on local 
policy, but specifying how to handle such a rejection if such an option 
is chosen is perfectly appropriate in the RFC.