ietf-mxcomp
[Top] [All Lists]

Re: Input on identities

2004-04-08 10:41:12

Philip Miller <millenix(_at_)zemos(_dot_)net> wrote:
Verifying HELO provides the following benefits, in no particular order:

  I'll bite.  What, exactly are you verifying?

  RFC 2821 Section 3.6 says:

     -  The domain name given in the EHLO command MUST BE either a primary
      host name (a domain name that resolves to an A RR) or, if the host
      has no name, an address literal as described in section 4.1.1.1.

  Section 4.1.4 has similar text.

  But many mailers will accept unresolvable names in EHLO.  And
Section 4.1.4 says

    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.

  So you're not supposed to validate the EHLO field.

  Further, Section 4.1.1.1 allows for something *other* than primary
domain names or address literals:

    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

  Ok, that's a SHOULD, not a MUST.  So if there's no primary domain
name, and the client doesn't want to send an address literal, what
does it send?

  And what address literal does it send?  [127.0.0.1] seems to be OK.
Many spammers send an address literal of the IP of the recipients MTA.

  Section 4.1.4 says:

    If the EHLO command is not acceptable to the SMTP server, 501, 500,
    or 502 failure replies MUST be returned as appropriate.

  OK, so why would it not be acceptable?  Is it up to the
implementation to decide?  Apparently so, but the implementation is
forbidden by 4.1.4 from using the argument to EHLO for any kind of
validation.

  It's a catch-22.  Servers are given data in a field, told it means
something, but are forbidden from doing anything to verify that the
data is meaningful.

  What does that data mean, then?  So far as I can tell, nothing.

  We can look at EHLO argument verification as fixing a design flaw in
RFC 2821, where the protocol description contradicts itself, and makes
compliant implementations impossible.

  Alan DeKok.