spf-discuss
[Top] [All Lists]

Re: Possible SPF machine-domain loophole???

2004-02-29 08:59:14
-----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-----