ietf-smtp
[Top] [All Lists]

Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]

2007-03-26 03:51:56

Arnt Gulbrandsen wrote:

Hector Santos writes:
Case in point, The Thunderbird MUA violates the EHLO [literal] when the client is residing on a private address behind a NAT. TBird attempts to get the FQDN and if not available, it uses the domain literal for the client machine. If a server is checking for strict IP correctness, it might fail this transaction.

I was blacklisted last week for doing the opposite - figuring out the correct IP address used and using the DNS name corresponding to that (dhcp-3424234.aconferencedomain.org). Seems ten million botnet members do that at the moment.

Not sure if we talking the same thing:

Example:

Connecting IP is a public address, 1.2.3.4, and the client issues a private address:

   EHLO [192.168.1.122]

Technically, this is an violation of the specs.

This is happening more and more with the growth of SOHOs (Small Office/Home Office), home users with a single NAT machine or router and private network with multiple machine, one for Daddy, Mommy, Billy and Sally. SMTP client software typically do not give users the option to set the client domain name (HELO/EHLO), so you have an automatic violation of the SMTP specs. Clients like Outlook use the NETBIOS name for a reason if there is no FQDN for the machine. Servers, if they have checking enabled, typically only attempt to check a client domain name for syntax only and iff the client provides a FQDN. Since NETBIOS name is not valid (not fully qualified), the checking is typically ignored. So its not because MS are BAD people, they are doing it for a reason.

The SMTP client who tried to follow the rules suffers the consequences.

So perhaps a long-lived document like 2821bis had better not speak too much or too loudly on this subject. Whatever it were to say might just be obsolete in two years. The mail system is long-lived and changes slowly, each spam filter is short-lived and quickly replaced.

The point is valid, but in my view, and if I was the author, I would probably inject some comment about the reality for SMTP developers to be very aware of the situation.

- Reality:  Servers are increasingly rejecting at HELO/EHLO. Thats
            a given, and there is no turning back the clock here.

- Reality:  Unfortunately, quite often in violation of x821.

The issue in general, which means nothing, is that the state machine is sequential and validation is done sequentially. Delay considerations are now more often required to get 2-3 state points before making a valid decision. i.e, we don't check MAIL FROM until we know that RCPT TO is valid thus given MAIL FROM validation a higher payoff with lesser overhead. This concept is actually method in 2821.

| 3.3 Mail Transactions
|
|    .....
|
|   .............  Despite the apparent
|   scope of this requirement, there are circumstances in which the
|   acceptability of the reverse-path may not be determined until one or
|   more forward-paths (in RCPT commands) can be examined.  In those
|   cases, the server MAY reasonably accept the reverse-path (with a 250
|   reply) and then report problems after the forward-paths are received
|   and examined.  Normally, failures produce 550 or 553 replies.


We need more of this level of insight. We just added another similar delay consideration where we don't check EHLO/HELO under the SUBMIT protocol to help address the situation described above. By using SUBMIT we lower any security impact of not checking the EHLO/HELO since an authentication is required by SUBMIT.

--
HLS