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:
Connecting IP is a public address, 126.96.36.199, and the client issues a
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.