Re: RFC 5321bis / 2821ter

Paul Smith <paul@pscs.co.uk> Thu, 29 January 2009 09:00 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 n0T90LaW098106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 02:00:21 -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 n0T90LH6098105; Thu, 29 Jan 2009 02:00:21 -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 n0T909HI098092 for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 02:00:20 -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; Thu, 29 Jan 2009 09:00:04 -0000
Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Thu, 29 Jan 2009 08:59:02 -0000
Message-ID: <49816FD7.1040609@pscs.co.uk>
Date: Thu, 29 Jan 2009 08:59:03 +0000
From: Paul Smith <paul@pscs.co.uk>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Hector Santos <hsantos@santronics.com>
CC: Alessandro Vesely <vesely@tana.it>, 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> <497F7058.90109@santronics.com> <498025E0.7080802@pscs.co.uk> <49809046.101@santronics.com>
In-Reply-To: <49809046.101@santronics.com>
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>

Hector Santos wrote:
> Paul,
>
> I'm surprise you are suggesting these spoof attempts doesn't exist in
> the real world because of the simplicity or dubious nature. The fact
> is, the frequency of HELO/EHLO spoofing of all sorts is very high.
I'm not convinced that, at the moment, you can call it 'spoofing'. It is
currently extremely rare to block a message based on a bad EHLO
parameter (because RFC 2821, 5321 prohibit that), so spammers really
don't care. If lots of recipients started blocking messages based on
that, it'd take all of a couple of hours for the spammers to work around it.

In our experience of supporting small businesses' mail servers it is
actually very rare to check the EHLO parameter at all. We have customers
who have their server set to send 'EHLO server' for many years, and then
suddenly come across a recipient which requires a syntactically correct
host name (ie a FQDN). We have yet to come across a recipient where if
they change it so that it sends 'EHLO [<local ip address>]' or 'EHLO
domain.com' it won't work, even though the first is useless and the
second is strictly incorrect.

AIUI, this is what is expected from RFC 5321, and it means that spammers
haven't put any effort into what EHLO parameter to send, because it
doesn't matter what you use if the recipient is standards compliant.

If this changed, (as was suggested) so that the EHLO checking was almost
universal, then it would break lots of legitimate senders as well as
spammers, but the spammers would be able to fix it a lot easier than
legitimate senders.
>> In which case, how did the EHLO test *really* help? 
>
> To stop the obvious spoofing attempts, which do occur at a very high
> frequency.  I am scratching my head as to why you would be questioning
> it.
If you are doing this at the moment, you are breaking RFC 5321 which
explicitly says you MUST NOT block messages if the EHLO parameter
doesn't match the sender IP address.

-- 
Paul Smith

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