ietf-asrg
[Top] [All Lists]

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

2003-08-30 09:15:15
On Fri, Aug 29, 2003 at 09:23:16PM -0700, Scott Nelson wrote:
At 10:40 PM 8/29/03 -0400, Richard Rognlie wrote:
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.)

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...

There are machines that can't tell which IP address they
are connecting through.  Would you, for example, reject email
sent to yourself because it came in on 127.0.0.1, but the
HELO was for example.com? 

DRIP has the ability exempt certain IPs from testing.

127.0.0.1/32 is hardcoded as an exemption already.

What if the domain resolved to 10.1.2.3 but the connecting IP was 10.1.2.5?

If your machine can't tell what it is... I have no interest in talking
to it.  But if you do have multiple IPs for a single helohost, then
in DRIP speak, it's up to you to have DRIP records for each possible IP
that a helohost might use.

Of course, a 10.*.*.* host connecting to my MTAs would be a bad thing
(as I don't run any 10. nets, and 10. nets are unroutable).

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.

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).   

You can reject it if it's IP is a prime number if you like,
it would just mean you aren't RFC compliant.

That'd be silly.  you know you can only reject prime numbered IPs
IFF it's the 5th tuesday of the month.

8^)

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.  

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.

A server might claim that because a server has no way of knowing
what IP it's being NATed to.  Again, you can reject email 
from servers that can't figure that out, but you wouldn't
be RFC compliant if you did.

It's no worse than listening to a DUL RBL.  If you don't know
the IP you are connecting through, I don't want to talk to you.
I want to speak to *well behaved* MTAs.   If you're behind a NAT,
talk to your local provider's MTA.  

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.

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.

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.

You can reject email for any reason you like (many do),
but you may not be RFC compliant if you do.

There's the letter of the RFC, and there's the spirit.
All the things we are discussing here are intended to maintain the
spirit of a free exchange of email on the internet.  Sadly, the 
spammers are forcing us to take measures the WILL result in some
collateral damage.   But hopefully, we can minimize that and
make sure there are useful workarounds for those that ARE
legitimate emailers.

e.g.  my personal mail server recently ran afoul of rr.com anti-spam
efforts.  it seems someone on the /24 where my boxes reside sent a bunch
of bad email to rr.com, so they blocked the whole /24, not just the
single IP... their servers, their rules...  but I was able to route
rr.com mail through my ISPs mail servers until the block was lifted.  

Yahoo tempfails multiple RCPTs if the sender is <>,
that's not compliant either, but I doubt many would fault them for it.

I know I can't blame them.

Rejecting email because the HELO is wrong is likely to generate
complaints.  But hey - If you're running your own server then
it's just you that you need to please.  And if you run a server
for others, then as they're fond of saying on NANOG -
I invite my competitors to engage in such behavior.

We'll see how many complain about what's in place now.  I don't 
think I'm being draconian.  Just asking that people run their
own services well.


-- 
 /  \__  | 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