Re: Input on identities

["Philip Miller" <millenix@xxxxxxxxx>]

Alan DeKok said:
>
> Philip Miller <millenix@xxxxxxxxx> 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.

I interpreted that to mean that an EHLO cannot be rejected on the basis of
the EHLO argument not resolving to the peer IP address.

>   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.

I think implicit in that text is that the address literal sent would
actually somehow represent the client host. By that criterion, if it
doesn't have a FQDN or a meaningful IP, it should send [127.0.0.1], so as
not to commit forgery.

>   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.

As I recall, SMTP servers are free to reject (at any point in a
conversation) for any local operational or policy reason. That would
include validation of the sort we're discussing.

>   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.

That's how I'm looking at it. There are flaws in RFC 2821 that prevent
accountability and allow harmful forgery of various protocol fields. We're
here to fix that.

-- 
Philip Miller
millenix@xxxxxxxxx
"Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former"
-- Albert Einstein