[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Input on identities


--Alan DeKok <aland@xxxxxx> 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@xxxxxxxxxxxx>