On Sunday 25 March 2007 19:02, Frank Ellermann wrote:
Julian Mehnle wrote:
what's the problem with some implementations making a (potentially
bogus) TLD query (which is likely to fail), some mismatching the
mechanism, and some throwing PermError? The only real type of
case I can see is the "legit TLD used as host or MX domain name"
one, and as far as I can see, no TLD actually does it.
Besides, throwing PermError in this case is hardly justifiable
from what the spec says.
Fine, we're making progress, so you consider PermError as bad idea.
That leaves "ignore single labels" or "try to match as always".
I'm surprised this has caused so much traffic. I think that this whole issue
us reasonably clear from an SPF perspective...
SPF only has something to say if HELO/EHLO is an FQDN. The accept/reject
decision for non-FQDN HELO/EHLO is not an SPF question. If asked the SPF
result for a non-FQDN HELO/EHLO, the only possible answer is NONE.
Where things get mushy is the definitition of FQDN. We didn't define it and
we can't fix that mushiness.
Here is what I think the range of reasonable interpretation is:
musuem.123. - NOT FQDN (All numeric TLDs not allowed)
musuem - Could go either way, but unless an application is specifically
designed to need to find TLDs, NOT FQDN should be preferred, but FQDN is an
acceptable alternate.
museum. - FQDN.
I don't recall which RFC (I'm pretty sure it's the same one that says no all
numeric TLDs), but applications are specifically discouraged from hardwiring
the current list of actual TLDs and so for an implementation, I think this is
the best we can do. Anyone actually wanting to put a TLD in an SPF record
would be well advised to include the trailing dot.
Scott K
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735