Re: Input on identities

--Alan DeKok <aland(_at_)ox(_dot_)org> wrote:

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

Yeah that is sort of unfortunate, if anything in RFC[2]821, that is one 
that I would like to deprecate.  HELO should be a FQDN in my opinion, and 
it should be enforced.
But this is low on my priority list:  1. MAIL FROM 2. From:/Sender: 3. HELO.



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

If they HELO with my own name, or my own IP, I can probably safely reject 
them... they are "provably wrong".  Checking to make sure the FQDN they 
give us is "good" is probably hard, but checking to make sure it's not 
provably forged should be easier.  By that I mean, if I publish 
"appropriate use of my own domain in HELO" and enforce it, then I 
automatically get "known bad" result for intentional bad behavior, and that 
has an immediate payoff.  The vast majority of HELO names will still be 
"unknown" and converting those to "known good" will be a long road.  "Not 
known bad" pays off now, "known good" pays off much later, but I would like 
to get the ball rolling on both.  (This can apply to HELO, MAIL FROM, or 
From:/Sender: as well)


>   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.
Agreed.  Some minor changes of /MUST/MAY/ or /SHOULD/MUST/ may go a long 
way to changing the tenor of 2821 without losing the spirit :)
A larger issue is the shift from "laissez faire" to "paranoid" in a lot of 
areas.  In the happy, free, wild days of the Internet, a lot of specs were 
written (like HTTP) that said "Be strict in what you send, but be tolerant 
in what you accept".  I am now starting to question whether this is a 
desirable model anymore.  I would rather see more strictness in what a 
server will accept, given that any wiggle room might be abused by someone, 
somewhere.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>