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

From: Scott Nelson <[email-masked]>
Date: Fri, 29 Aug 2003 21:23:16 -0700

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?  What if the domain resolved to
10.1.2.3 but the connecting IP was 10.1.2.5?

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

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

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

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

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.

Scott Nelson <[email-masked]>

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

---

From: Richard Rognlie <[email-masked]>
Date: Sat, 30 Aug 2003 09:42:43 -0400

On Fri, Aug 29, 2003 at 09:23:16PM -0700, Scott Nelson wrote:
> 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).

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

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

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

> that's not compliant either, but I doubt many would fault them for it.

I know I can't blame them.

> 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/    <[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 22:25:31 +0200

>  talk to your local provider's MTA.

	This doesn't work if people start adopting RMX-like solutions, 
and I have a dozen e-mail addresses.  Or .forwards.  Or 
/etc/alias-based mailing lists.  Or other reasons for attempting to 
use legitimate third-party relays.

>  rr.com mail through my ISPs mail servers until the block was lifted.

	How many people have the knowledge and skills necessary to do 
this sort of thing?

>  think I'm being draconian.  Just asking that people run their

	But how many complaints are you not getting?  For example, I 
don't ever talk to anyone who uses a TMDA/ASK-like system, not even 
to complain about their anti-spam measures.

-- 
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(+++)

---

From: Richard Rognlie <[email-masked]>
Date: Sat, 30 Aug 2003 19:46:02 -0400

> use legitimate third-party relays.

My measure has nothing to do with email addresses.  Only the HELO/EHLO
argument.   I'm asking that if you are not going to conform to the 
standards of the net, please relay your mail through a host that does
and does not mind you not doing so (use your local ISP's mail server
as a smart host)

I did discover my NAT/router was getting blocked by the filter when it
tried to send me alerts ( ... "hey!   here's a spoofing attempt from
IP x.y.z.t on the WAN" ... )  So I added that IP to the exemption list
for the drip milter  (-x xx.yy.zz.tt/32).  

> 	How many people have the knowledge and skills necessary to do 

True.  I'm a bit of a sendmail snob, but that's mostly because I can
beat it into submission (regardless of what that stupidity I need to
make it do... can you say "99 bottles of beer" in .cf?   I can... 8^)

> to complain about their anti-spam measures.

For now, I'm still getting all the mail being submitted to me by
"real" MTAs (as opposed to spamware/malware).  That's due to my
dripmilter returning the error on the MAIL FROM:, not the RCPT TO:.

So, the mail fails over to my backup MS host...  And I'm seeing a
LOT more mail coming from him that I used to.

The proof in the pudding is to count how much "legitimate" mail is 
how showing that host in the Received headers.

(Just what I need... another task to do...)

---

From: Brad Knowles <[email-masked]>
Date: Sun, 31 Aug 2003 02:18:56 +0200

>  and does not mind you not doing so (use your local ISP's mail server

	Right, but if lots of people use RMX-type solutions, then my ISPs 
mail server is almost certainly not going to be on the list of 
"approved" sending mail relays for most of those domains.  So, I have 
to use different mail relays, one for each domain that I send e-mail 
from.  Moreover, each of those has to be configured with SMTPAUTH, 
TLSSMTP, POP-before-SMTP, or whatever.

	And all of that still breaks with /etc/alias-based mailing lists 
and .forwards (or alias-based forwarding).

>  make it do... can you say "99 bottles of beer" in .cf?   I can... 8^)

	I've been a bit of a sendmail snob since ~'91-'92, when I was 
forced to learn it based on the only published material available at 
the time, which was a single chapter in Craig Hunt's book _TCP/IP 
Network Administration_.  I've been a fan of postfix since early '98, 
back when Wietse was still calling it VMailer.

	But I still see serious problems with recommending this type of 
solution to anyone outside that rarified type of atmosphere.  If you 
haven't written your own sendmail.cf or your own anti-spam m4 macros 
and submitted them to Eric/Greg/John (back before Klaus was on the 
scene), what are your odds?

>  LOT more mail coming from him that I used to.

	Lots of spammers don't bother trying to send directly to the 
primary MX.  They automatically assume that many sites will do what 
you have done, where you protect the primary MX more than you do any 
of your others, and will automatically contact them first.

	This is a trick they were using back in '95-97, when I was 
hip-deep in this stuff at AOL.