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

On 10/26/2011 12:14 PM, Alessandro Vesely wrote:
> On 25/Oct/11 21:21, Frank Ellermann wrote:
>> On 25 October 2011 20:33, Alessandro Vesely wrote:
>>
>>> Because "RFC 4408 deliberately steered clear of trying to specify
>>> receiver policy", considering the possibility to reject is
>>> tantamount to suggesting such behavior.
>>
>> Any step with long threads on this list.  The RFC doesn't exactly
>> tell you what to do with SOFTFAIL, TEMPERROR, PERMERROR, or NEUTRAL
>> (of course you're free to reject SPF PASS if it's a known spammer
>> or similar, and you are also free to accept FAIL [...])
>
> This somehow assumes that "receiver policy" and "sender policy" are
> two unrelated areas.  Yes, it is a recurrent topic.  Some time ago
> Julian wrote
>
>     The problem with mandating receiver policy is that receivers are
>     going to ignore it at will.  Receivers will always do what they
>     think is best for them.
>
> That is obviously true of any IETF standard.  However, in order to let
> senders know whether they're safe using macros, in case we happen to
> know that senders should not reject on PermError, we'd better document
> that.

We need to be careful not to over-specify.  The RFC needs to focus on 
the bits needed for interoperability.  It is not a full implementation 
spec (although RFC 4408 manages to come close to this).

For the question of what to do with invalid domains after macro 
expansion, for purposes of interoperability, we ought to specify the SPF 
result that is appropriate.  What receivers do with that result is not a 
matter of interoperability, but of local policy.

We went through this repeatedly in 2004 - 2006 and came to a rough 
consensus that specifying receiver policy would be a mistake.  I don't 
think that is going to change.

Senders are never 'safe'.  There is never a guarantee that receivers 
will accept their mail, so trying to bend the standard in this one case 
doesn't help.

In the pre-MARID specs what is now known as permerror was simply called 
unknown.  In the work that was done in MARID and after there was a 
deliberate design choice to call this permerror and that rejecting based 
on it was a possibility.  Right or wrong, I think your ship sailed 5 
years ago.  The fact that the sentence about exactly how to reject if 
one chose to do so was a simple editorial mistake.

>> For the more interesting cases the spec. tells you how to reject it
>> *IF* you reject it, for FAIL, for SOFTFAIL, and for TEMPERROR.
>> Omitting this only for PERMERROR always was an error.
>
> It is an ambiguous way to tell which cases are interesting.  And
> "MAY", "SHOULD", or "MUST" are much clearer than "interesting" anyway.
> (Or perhaps we could explain in greater detail how to reject for the
> cases that are more interesting :-)

Paragraph 2.5.4 already covers the more interesting reject case.

Scott K