IETF Logo Mail Archive

Re: RFC 5321bis / 2821ter

Paul Smith <paul@pscs.co.uk> Wed, 28 January 2009 09:30 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0S9UU68032858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 02:30:30 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0S9UUaR032857; Wed, 28 Jan 2009 02:30:30 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from mail.pscs.co.uk (mail.pscs.co.uk [77.240.14.73]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0S9UIkg032845 for <ietf-smtp@imc.org>; Wed, 28 Jan 2009 02:30:29 -0700 (MST) (envelope-from paul@pscs.co.uk)
Received: from lmail.pscs.co.uk ([62.3.195.6]) by mail.pscs.co.uk ([77.240.14.73] running VPOP3) with ESMTP; Wed, 28 Jan 2009 09:30:15 -0000
Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Wed, 28 Jan 2009 09:21:08 -0000
Message-ID: <49802384.6060705@pscs.co.uk>
Date: Wed, 28 Jan 2009 09:21:08 +0000
From: Paul Smith <paul@pscs.co.uk>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Alessandro Vesely <vesely@tana.it>
CC: ietf-smtp@imc.org
Subject: Re: RFC 5321bis / 2821ter
References: <4979D903.1060705@pscs.co.uk> <E5EF288BD222F5BA20C735BD@PST.JCK.COM> <497980AA.2060706@es2eng.com> <C4ZHRHThnSMjwwDOZ03z0w.md5@lochnagar.oryx.com> <4979B5F2.9010102@pscs.co.uk> <WBwvOp9JIdw2SWc1HYscRg.md5@lochnagar.oryx.com> <4979D903.1060705@pscs.co.uk> <5.2.1.1.0.20090123140212.03ed3fb0@plus.pop.mail.yahoo.com> <51104ACCD26E8167A1B3981E@PST.JCK.COM> <497D8756.5030306@pscs.co.uk> <alpine.LSU.2.00.0901261913140.4795@hermes-2.csi.cam.ac.uk> <497ED51D.9040407@pscs.co.uk> <497EE0EA.6080704@tana.it> <497EEB01.8060300@pscs.co.uk> <497F41FB.7060101@tana.it> <497F4765.6070109@pscs.co.uk> <497F5468.1030608@tana.it>
In-Reply-To: <497F5468.1030608@tana.it>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V2.6.0e - Registered
X-Organisation: Paul Smith Computer Services
X-Authenticated-Sender: Postmaster
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

Alessandro Vesely wrote:
>
> Paul Smith wrote:
>>> Spammers are welcome to use their own domains: that puts the spam
>>>  problem at the relevant ISPs.
>> Not sure I understand that.
>>
>> It is totally valid to do:
>>
>> EHLO mail.spammer.com
>
> I assume that the EHLO parameter corresponds to the IP address of
> the sending host.
Yes

>> MAIL FROM:<me@mycompany.com>
>>
>> The EHLO name bears no resemblance to the sender's email address.
>> Doing an SPF on the EHLO name is pointless, as all that tells you is
>> that the sending host is 'mail.spammer.com'.
>
> Yes, and spammer.com is where recipients should complain or claim any
> damage that the transmission might have caused. More likely, the IP of
> that transmitter will be blacklisted soon. I guess that's why spammers
> use zombies or bots.
A bot could use:
EHLO fgbdfhbeng.spammer.com

where fgbdfhbeng.spammer.com resolves to the IP address of the bot. The
spammer can trivially set up a virtual DNS zone with all valid IP
addresses in it, and the bot just chooses the appropriate one.

Complaining to spammer.com won't do any good, and they'll create new
'spammer.com' domains faster than you can block them.

How does it help?

>
>> You have to do the SPF check on the MAIL FROM address, and test it
>>  against the IP address of the sending host.
>
> If the MAIL FROM is given and mycompany took care of setting SPF
> properly, the receiver can reject the message. More often, the MAIL
> FROM address consists of an invalid user at a valid domain without SPF
> records.
Exactly, so how does having a 'correct' EHLO parameter help?

I can see that having an incorrect one can be used to block mail, IF
(and this is a big 'if') you can be sure that legitimate senders set up
things correctly. However, if this becomes a standard check, then it is
trivial for a spammer to get around it. And, all that has achieved is
another useless check, which makes life harder for the good guys.

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

v2.23.0 | Report a Bug | By Email