Re: RFC 5321bis / 2821ter

Alessandro Vesely <vesely@tana.it> Wed, 28 January 2009 10:42 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 n0SAgZ2L036928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 03:42:35 -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 n0SAgZUw036927; Wed, 28 Jan 2009 03:42:35 -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 wmail.tana.it (wmail.tana.it [62.94.243.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SAgN3e036904 for <ietf-smtp@imc.org>; Wed, 28 Jan 2009 03:42:34 -0700 (MST) (envelope-from vesely@tana.it)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 28 Jan 2009 11:42:22 +0100 id 00000000005DC02F.000000004980368E.00001163
Message-ID: <4980368D.8040809@tana.it>
Date: Wed, 28 Jan 2009 11:42:21 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Paul Smith <paul@pscs.co.uk>
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> <49802384.6060705@pscs.co.uk>
In-Reply-To: <49802384.6060705@pscs.co.uk>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
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>

Paul Smith wrote:
> A bot could use:
> EHLO fhbdfhbeng.spammer.com
> 
> where fhbdfhbeng.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.

Uh, I may be dumb but I finally got it...

I guess that by "virtual DNS zone" you mean something where "fhbdfhbe" 
is the hex IP address of the bot (possibly obtained via traceroute 
from behind a NAT) and "ng" the bot version or whatever additional 
info is necessary for virtualizing the zone.

Apparently, that argument rules out any DNS-based validation.

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

Hm... it is useless to install an armored door in a shutterless house, 
and it is also useless to install security shutters since the door 
cannot be locked. Does that analogy fit the status quo?

IMHO, if we start designing an armored door, perhaps by the time it 
will be installed those shutters will be underway. I still like VHLO.