On Thu, 28 Apr 2005, Frank Ellermann wrote:
neither makes it a requirement to be a domain name, much less
an FDQN.
You don't check SPF on something that's no FQDN. That was one
of the bugs in draft Lentczner, where it said "FAIL malformed
domain" to a perfectly legal domain literal.
the name following the HELO is inconsequential to the SMTP
state machine, as no decisions are made on its contents
That's not the case, the RfC 2821 syntax wants at least one dot
in an FQDN. Without this dot you have an SMTP syntax error if
you want to be strict (an MX only talking to real MTAs and not
MUAs can be strict).
Strictly speaking this is not correct (i.e. I bug in RFC2821), you
could have valid TLD domain that is a host (in fact I think one of
the TLDs is like that) and they could send email as postmaster(_at_)tld(_dot_)
What they should have said is that "domain" must exist and dns
lookup for 'domain." must not result in NXDOMAIN. This causes
local hosts (i.e. user(_at_)hostname) to be seen as invalid internet
address because adding extra "." at the end during dns lookup would
ensure the check is against internet tld tree, but if user(_at_)hostname is
such that hostname. exist, it would be valid.
Another obvious check allowed by RfC 2821: Whoever the client
claims to be, it can't be "you", because "you" (= the server)
don't talk to yourself.
Actually this is not true and would be big error to rely on such a check.
It is perfectly valid for my host to connect by SMTP and result in email
being sent to username on the same host. It happens all the time on
my servers when comment is submitted from website through cgi.
The earliest SPF version where it could be obsoleted would be
an v=spf2 or spf2.1/whatever. In that case I'd add some more
dubious features like exp= or ptr to the list.
When this comes finally up for discussion and we talk about UnifiedSPF,
I'll be strong in favor of skipping version 2 and going to 3 for next
generation of SPF.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net