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

[Richard Rognlie <rrognlie@gamerz.net>]

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

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

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

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.

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


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