On Thu, Aug 28, 2003 at 03:34:05PM -0400, Hector Santos wrote:
We found rDNS checking on HELO/EHLO to be unreliable due to
mis-configuration of smtp servers, in particular those systems who prepare a
send-only or routing server, which from my last reading of the RFC (a few
years back), need to be prepare as sub-domains. Because they are not, it
is not possible to do reliable checking.
Recently, we added logic to check for the bracket DOT format, i.e,.
HELO/EHLO [X.X.X.X]
We found those servers using this format to be spammer servers and they are
using it incorrectly, providing the literal IP without the brackets, i..e,
HELO/EHLO X.X.X.X
So we reject the HELO/ELHO state when
a) The literal IP does not have brackets, or
b) The provided bracket IP does not match the connecting peer IP.
We have rejected on average about 125 per day using this scheme.
Incidentally, before this logic was added, the average about 80 attempts
per day. Hence, the rejection is causing some senders to try again more
often. We are sending a 5XX response code (permanent error, don't try
again) but some are ignoring it of course. :-)
Based on the logs I'm maintaining as part of my DRIP Milter development,
I see ~20% of all HELO/EHLO requests are either...
a. an IP. But worse... it's *MY* IP. not theirs.
b. An unqualified "hostname" (e.g. BIZ3)
I am preparing to add an option to the DRIP milter which will treat
either of those cases (IP (with or without []s) that does not match
the connecting IP) and unqualified hostname as invalid DRIP records
(vs. unknown DRIP host as the probably do now)
I'm curious about Brad's contention below...
Since RFC2821 explicitly prohibits you from checking the domain
literal claimed in EHLO/HELO and rejecting the message if the reverse
DNS doesn't match that domain, then I submit that your tests are at
least violating the spirit of RFC2821 in a similar manner.
Section 3.2 states
In the EHLO command the host sending the command identifies itself;
the command may be interpreted as saying "Hello, I am <domain>" (and,
in the case of EHLO, "and I support service extension requests").
Section 3.6 states
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.1.1 states
The argument field contains the fully-qualified domain name of
the SMTP client if one is available. 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
(see section 4.1.3), optionally followed by information that will
help to identify the client system.
Section 4.1.4
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.
It says we can't use the IP as a basis for rejection. I'm wondering
why not...? Yes, if only an IP is presented, I can envision that it
was presented by a machine behind a NAT... so it presents 192.168.x.y
but the connecting IP is God knows what... But do I want to accept
that mail?
And certainly... if a machine presents *MY* IP addr as the connecting
info... but the connecting IP does not have anything to do with my
network... Bzzzzt! Next player!
or when they say "EHLO gamerz.net" but again are NOT on my network.
Bzzzzt!
The DRIP logs have been very interesting in that regard. I'll post
them to ftp://ftp.gamez.net/pub/dripmilter.log shortly.
Richard
--
/ \__ | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
\__/ \ | http://www.gamerz.net/rrognlie/ <rrognlie(_at_)gamerz(_dot_)net>
/ \__/ | I can only please 1 person per day. Today is not your day.
\__/ | Tomorrow doesn't look good either.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg