-----BEGIN PGP SIGNED MESSAGE-----
I think that this disagreement is confused. No one is undervaluing
checking the EHLO/HELO argument (or at least they shouldn't be). The
argument is if and why it belongs in SPF.
[RFC 2821]
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system.
Basically, this illustrates that the EHLO argument is "unreliable" at
best.
o Many legacy systems do not use FQDNs, but local labels.
o many use names with underscores
o some send IPs purposefully as they don't believe (or want) their
FQDN to be meaningful.
SPF's goal it to prevent fraud by interpreting the policies of the
sending domain. So, any decision to refuse the message based on that
is a _local_ policy decision and doesn't fit "well" in SPF -- hence all
of these arguments.
Additionally, I think it is perfectly safe it implement SPF checks on
receipt right now, because you know, with no uncertainty, that any mail
you reject is done so based on the published wished of the owner of the
sending domain. It can't get "safer" than that (safe: no legitimate
mail lost).
Implementing stringent checks on EHLO arguments is valuable to some and
costly to others and takes away much of the safety of current SPF
implementations.
Making a policy decision based on EHLO arguments is also against the
RFC:
[RFC 2821]
4.1.4 Order of Commands
[Paragraph 6]
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
Note the MUST NOT actually means a lot here. I personally think it
should be a "SHOULD NOT", but I didn't write the scripture. So, adding
this into SPF would make SPF explicitly break RFC 2821 which I don't
believe it currently does.
Again, I am not devaluing the approach of pedantic EHLO validation.
SPF uses EHLO arguments as the return path domain for null envelope
senders simply because it has nothing else to use (which I also don't
like). EHLO checking can be performed outside of SPF at the whim of
the receiving end. I think that EHLO processing is a _local_ policy
decision and should not be placed in SPF.
I spent a few hours on friday figuring out why our someone in
management couldn't get a contract via email. It was due to a screwy
EHLO argument from the remote end -- entirely non-SPF related. In my
opinion, this approach deviates from the spirit of RFC compliance -- be
conservative about what you produce and liberal about what you accept.
I also don't understand what we loose by leaving this out. I think
that SPF should _not_ be the end-all, be-all of a mail validation
system. It will ultimately be used in conjunction with a variety of
other tools and domains will still implement arbitrary ad-hoc policies
that suit them -- pedantic EHLO checking is one of those.
I could be convinced that it would be a "good thing" to include in the
SPF draft that implementations should or must ensure that the EHLO
argument supplied does not spoof a local domain. That would at least
make it deviate less from the LMAP specs. But still, I'd rather SPF
just say we do XYZ and we do XYZ well and safely and happily go on
living without completely fulfilling LMAP. I could, as an email
administrator, trivially enforce EHLO arguments to be domains outside
of my local domain list without the use of SPF.
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iQEVAwUBQEIMWFwyh8czExtlAQGUUQf/QieKycH++unXnNU2ARHVecG7PDnCYUUe
/Bj6bIxUVETVqsafrXmMOnfMjXVkGggWmRutNbFL+sCz/ZM7ySvff9VsqkQCLVXg
7m12Q6ZkuWOdzchf3t6D1uAJD6k+NOeI23UNSABV4kNQX2Ka1xvd3h5BS3oT/IWs
OiOr16m7+LhWvM4/1nzXAPdISe8io/XXde8hCppHwyKks35qLB9fyK9hVr2ODQHC
jInhJlpuf4DvJakbyraob8x/8zllFXMcXz9lubSiRh5bcgF6g2oH69tFWjWK8oVu
n8JTgXp0KPKtH+M8wHY8WveAG53rXewN5nJRU33jkQrsMcPiRirbdQ==
=b3Mw
-----END PGP SIGNATURE-----