Re: RFC 5321bis / 2821ter

Paul Smith <paul@pscs.co.uk> Wed, 28 January 2009 09:40 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 n0S9eHsi033324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 02:40:17 -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 n0S9eH4Z033323; Wed, 28 Jan 2009 02:40:17 -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 n0S9eGDp033317 for <ietf-smtp@imc.org>; Wed, 28 Jan 2009 02:40:16 -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:40:13 -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:31:12 -0000
Message-ID: <498025E0.7080802@pscs.co.uk>
Date: Wed, 28 Jan 2009 09:31:12 +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>
In-Reply-To: <497F7058.90109@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 Smith wrote:
>
>> Not sure I understand that.
>>
>> It is totally valid to do:
>>
>> EHLO mail.spammer.com
>> 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'. 
>
> hmmmmm,  if an incoming client issues
>
>    EHLO mail.winserver.com
So, why would a spammer do that? All they need to do is use a EHLO
parameter that is valid for that IP address, and all your fancy tests
are defeated with 10 seconds work by the spammer. This might be
EHLO bibblebobble.spammer.com
or
EHLO adsl-153-34-125-62.isp.com
or whatever

If all you are doing is checking that the EHLO name matches an IP
address (which is all you CAN do), it tells you nothing except that the
EHLO name matches an IP address. Once they have done that, they can
trivially send mail from <user@winserver.com>, and there's nothing
stopping them, unless you have SPF or something set up. In which case,
how did the EHLO test *really* help? The SPF test on its own would have
achieved the same.
>
> which is our domain and its not part of our IP network, its a clear
> LMAP DOMAIN::IP violation, thus rejectable with 100% no false
> positions (or true negatives depending on your POV).
No, what if someone else has the 'winservers.com' domain, and mistyped
it into their server, or what if you gave your server to someone else,
and they didn't change it (YOU probably wouldn't do this, but other
companies might give a server to a sister company for instance), or what
if that was an example in documentation somewhere, and so on. You get
false positives. You only get 100% no false positives if you can be 100%
sure that (a) everyone else knows what they are doing, and (b) no one
else makes a mistake. Good luck with that.

If (as is more likely) a mail server is set up to send EHLO
server.company.local, and you reject it (against RFC 5321) then you will
get lots of false positives, just because a 5 user company with SBS
doesn't understand SMTP.

-- 
Paul Smith

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