Re: Re: domain literals

On Friday 16 March 2007 12:33, Frank Ellermann wrote:
> Roberto Alsina wrote:
> > it's understood it should do that, but it's not explicit, unless I am
> > reading wrong (or at the wrong place):
> >
> > 2.1.  The HELO Identity
>
> [...]
>
> That might be a part of "oral history" (hidden in the list archives :-)
> that you've missed.  At some point in time there was a draft saying
> that "weird" HELOs (also including domain literals) should be handled
> as PermError (or similar) because nobody wants them anyway.
>
> After some discussions that was dropped for several reasons:
>
> - The S in SPF is for "sender", not "receiver"
> - It's perfectly okay if a receiver accepts HELO [127.2.3.4] coming
>   from a client with IP 127.2.3.4
> - It's also okay if a receiver accepts domain literals where the IP
>   doesn't match
> - And some receivers claim that they're even forced to accept crap
>   like "oemcomputer"
> - As there is no "sender policy" for an IP, matching or otherwise,
>   let alone for a "domain" oemcomputer, SPF is moot about this.
> - Receivers are free to do whatever they like, but they can't claim
>   that IP literals or weirder HELOs are "SPF errors"
>
> Frank (still interested in two "HELO museum" test cases :-)

No, it's in the RFC:

 4.3. Initial Processing

If the <domain> is malformed (label longer than 63 characters, zero-length 
label not at the end, etc.) or is not a fully qualified domain name, or if 
the DNS lookup returns "domain does not exist" (RCODE 3), check_host() 
immediately returns the result "None".

So the correct SPF result for the IP literal is NONE.  I believe it's the same 
for your museum cases too.  If the test suite doesn't cover this, it should 
IMO.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007