Subject: Re: [Asrg] 0. General - Administrative - for M. Wild

From: Scott Nelson <[email-masked]>
Date: Fri, 29 Aug 2003 02:09:18 -0700

At 09:35 PM 8/28/03 -0400, Richard Rognlie wrote:
>
>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!
>

I think the point of 4.1.4 is that you can't expect the HELO to
resolve to the ip that's connecting to you.  (In some cases,
it's not even possible to pick a HELO that works.  A machine that
hosts 70 domains on a single IP for example.)
However, a lot of machines out there don't use even remotely "correct" 
HELO arguments.  For example, a lot of machines use unqualified 
host names ("bob" instead of "bob.example.com").
If you block because the HELO is not a FQDN, you're going to
block a fair amount of legitimate mail.

However, your IP address is very different.  That can't reasonably
be the result of stupidity - it's almost certainly done on purpose.
Likewise your domain can't reasonably be acidentally chosen as a
HELO argument either.  
You might be able to add other domains to the list, like yahoo.com,
but that's a little dangerous unless you can be very sure of
/all/ the IPs that are assigned to yahoo.com.

In the long run, blocking based on these things is self limiting.  
Once enough people do it, spammers will stop.  
You'll catch a small amount of spam, and a small amount legitimate
mail, then everybody fixes the bugs and you're right back where you
were before.

Scott Nelson <[email-masked]>

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Richard Rognlie <[email-masked]>
Date: Fri, 29 Aug 2003 22:40:41 -0400

> hosts 70 domains on a single IP for example.)

Can't I?   I don't expect the MTA to identify itself as one of the
domains it hosts.  I expect an MTA to identify itself as who *it*
it...

> block a fair amount of legitimate mail.

If a host does not identify itself, I don't want it's mail.  RFC2821
clearly says that it should identify itself with its FQDN.  so the 
lack of a '.' in the HELO argument is enough to cause a rejection
(if I wanted).   

> Likewise your domain can't reasonably be acidentally chosen as a

Right.   The only problem I can envision is if you're behind a NAT,
and you claim to be 192.168.x.y.  *why* you;d claim that instead of the
IP of the NAT... or better the hostname that the NAT represents... 
I have no idea...   Besides... shouldn't NATed boxes send mail to their
*local* outbound MTAs first?   So, you know what...?  I don't care.

If the box connecting to me claims EHLO 192.168.x.y, but the connecting
IP is 234.123.4.65.   That's enough reason to block it for me.

> mail, then everybody fixes the bugs and you're right back where you

The DRIP milter   ftp://ftp.gamerz.net/pub/dripmilter.pl

has been tweaked to think that non-FQDNs (that do not match after
even doing a resolv.conf "search") or IPs (that mismatch) are
enough cause to FAIL the DRIP test.

The only way I will accept mail from a host that fails the DRIP test
is if the connection SMTP AUTHs.

-- 
 /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/    <[email-masked]>
 /  \__/ | I can only please 1 person per day.  Today is not your day.
 \__/    | Tomorrow doesn't look good either.

---

From: Brad Knowles <[email-masked]>
Date: Sat, 30 Aug 2003 18:03:05 +0200

>  lack of a '.' in the HELO argument is enough to cause a rejection

	You can do whatever you want for your own e-mail.  However, we 
are not here to discuss solutions that individuals can apply to their 
own mail systems.  We are here to discuss solutions that we can 
recommend to everybody else in the world should apply to their e-mail.

	As such, we can be as draconian as we want with our own e-mail, 
but our recommendations as to what others should do must be much more 
conservative.

>  *local* outbound MTAs first?   So, you know what...?  I don't care.

	Feel free to block whatever you want.  But don't expect us to 
take your own personal restrictive policies and recommend that others 
also implement them, or be forced to implement them.

>  enough cause to FAIL the DRIP test.

	If you want to run an ISP or business this way, all I can do is quote:

		"I invite my competitors to design their networks this way"
			-Randy Bush

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)