Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01.txt

"John Levine" <> Sat, 21 January 2012 04:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1FB821F8700 for <>; Fri, 20 Jan 2012 20:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -108.338
X-Spam-Status: No, score=-108.338 tagged_above=-999 required=5 tests=[AWL=2.861, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ERSM8OWTFama for <>; Fri, 20 Jan 2012 20:45:02 -0800 (PST)
Received: from ( [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by (Postfix) with ESMTP id 9920221F8552 for <>; Fri, 20 Jan 2012 20:45:01 -0800 (PST)
Received: (qmail 62482 invoked from network); 21 Jan 2012 04:44:59 -0000
Received: from ( by with QMQP; 21 Jan 2012 04:44:59 -0000
Date: 21 Jan 2012 04:44:37 -0000
Message-ID: <20120121044437.94978.qmail@joyce.lan>
From: "John Levine" <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Jan 2012 04:45:02 -0000

Based on my experience, here's some advice for how to make greylisting
work.  My goal is to use it to recognize broken mail clients that
don't retry.  Once a client has shown that it knows how to retry,
there is no further benefit from greylisting it.  (It may be sending
spam, but you'll have to recognize it other ways.)

* Greylist on the triple [IP, MAIL FROM, RCPT TO].  After a successful
retry, whitelist all further mail from the IP.  I don't feel strongly
whether you should put just one RCPT TO in the triple or wait for DATA
and put all of them.

* The greylister should have a time window within which retries will
be accepted.  On mine, the minimum is one minute, the maximum is 24
hours.  I think those are reasonable.  You want a minimum because some
spamware retries immediately, you want a maximum both to keep the
retry table from filling up with junk and so two spams sent a week
apart aren't interpreted as a retry.  Some people set their minimum
much longer, several hours, but I don't see any benefit to that unless
you believe in the blacklist theory.

* Whitelist entries should time out eventually.  I delete them when
there's been no mail from the IP for a week.

* If you have multiple incoming servers at the same MX distance, they
should share a single greylist database.  This handles the case where
the retry goes to a different server, and lets all the servers share
the IP whitelist.  I do this by making the greylister a standalone
daemon, and use a very simple UDP protocol to query it.  If you're
Google or Yahoo and have multiple server pools all over the world,
I suppose a database per pool would do.

* Since some senders have multiple outgoing servers, allow approximate
matches on the retry IP.  I take anything in the same /24 which seems
to work OK.  I only whitelist the IP that retries, but I should
probably whitelist both.

* The greylister MUST have a manual whitelist.  Some legit senders
just don't work with greylisting for a variety of reasons, most of
which are not in conflict with RFC 5321.