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

[Scott Nelson <scott@spamwolf.com>]

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 <scott@spamwolf.com>

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg