Re: [Asrg] Greylisting BCP

"Peter J. Holzer" <hjp-asrg@hjp.at> Thu, 20 October 2011 07:22 UTC

Return-Path: <hjp-asrg@hjp.at>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To: asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38BF21F84BB for <asrg@ietfa.amsl.com>; Thu, 20 Oct 2011 00:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.13
X-Spam-Level:
X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e49KF3MhO6U9 for <asrg@ietfa.amsl.com>; Thu, 20 Oct 2011 00:22:46 -0700 (PDT)
Received: from zeno.hjp.at (ns1.hjp.at [212.17.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id E9C9C21F84BD for <asrg@irtf.org>; Thu, 20 Oct 2011 00:22:45 -0700 (PDT)
Received: by zeno.hjp.at (Postfix, from userid 1000) id DB91C4042; Thu, 20 Oct 2011 09:22:41 +0200 (CEST)
Date: Thu, 20 Oct 2011 09:22:41 +0200
From: "Peter J. Holzer" <hjp-asrg@hjp.at>
To: asrg@irtf.org
Message-ID: <20111020072241.GC21602@hjp.at>
References: <F5833273385BB34F99288B3648C4F06F19C6C14AC6@EXCH-C2.corp.cloudmark.com> <alpine.LFD.2.00.1110181539140.27058@nber7.nber.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.00.1110181539140.27058@nber7.nber.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [Asrg] Greylisting BCP
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2011 07:22:46 -0000

On 2011-10-18 15:42:24 -0400, Daniel Feenberg wrote:
> On Tue, 18 Oct 2011, Murray S. Kucherawy wrote:
>> After some chatter inside MAAWG and on the ietf-smtp mailing list, I’ve started an
>> outline for a BCP on the practice of greylisting.  The main purpose is to explain
>> what it is, discuss the pros and cons of its variants, and give some recommendations
>> for implementation and configuration for a few example installations and policies.
>>
>> The draft (which is currently only an outline) is here:
>> https://datatracker.ietf.org/doc/draft-kucherawy-greylisting-bcp/
>>
>> Comments welcome.
>
> Where should comments go? I have a question really, though it might be  
> construed as a comment. Why do greylisters match on the (sender,  
> receipient, MTA) triple rather on just the MTA? Isn't it nearly certain  
> that if an MTA returns for one sender/receipient pair, it will return for 
> any pair?

Yes, but how do you determine that the MTA returned for one
sender/receipient pair? For that you need the whole tripel. Once you
have established that the MTA does queue, the IP address is sufficient
(this wasn't in Harris' original proposal, but it is a common
optimization).

Actually, the tripel (ip address, envelope sender, envelope recipient)
is just an approximation. What greylisting really tries to establish is
whether a particular /message/ is queued. To do that right you would
have to compare the whole message, but that would be expensive. So
greylisting assumes that if there is a second delivery attempt from the same IP
address with the same sender and recipient within a certain time window,
then it is a second delivery attempt for the same message, not an
independent message. We all know that this assumption isn't always true
(and I've occasionally advised users to just send two mails within a few
minutes to get through greylisting) but its a reasonable heuristic.

There is also an argument for always using the whole tripel: It guards
against bots on the same IP address (e.g., an MTA and an infected
workstation behind a common NAT, or a reassigned IP address).

	hp

-- 
   _  | Peter J. Holzer    | Web 2.0 könnte man also auch übersetzen als
|_|_) | Sysadmin WSR       | "Netz der kleinen Geister".
| |   | hjp@hjp.at         | 
__/   | http://www.hjp.at/ |  -- Oliver Cromm in desd