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

"Paul E. Jones" <> Fri, 20 January 2012 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9B2D21F8650 for <>; Fri, 20 Jan 2012 10:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LCugV2y4npd3 for <>; Fri, 20 Jan 2012 10:55:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DABBA21F8646 for <>; Fri, 20 Jan 2012 10:55:27 -0800 (PST)
Received: from sydney ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id q0KItPBr004448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Jan 2012 13:55:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1327085725; bh=m/IgvSnZGrwJSo/8mOYfr5ZHH5Ke/hYli0c92Dhu5so=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=sYi3fki+VYbnyqeoXqnyPidpmxVdU3arTgUVigdXor2mnEjkrLJ/He3GE3If1QnlI nKHLEoslJelVbE07bXzO4Oe3iAJuGSnJRSeCXra3NB+DRP6JkmffVJxHYR0QibrRkV NlIEX/Mp7OoUVX+JICVJg3gVAcrXvwIYgyED1XBo=
From: "Paul E. Jones" <>
To: <>
References: <>
In-Reply-To: <>
Date: Fri, 20 Jan 2012 13:55:04 -0500
Message-ID: <02e501ccd7a5$05a0c620$10e25260$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQGBk2W8BNUlxQseu0YFp/ty1I18TpasEHSA
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: Fri, 20 Jan 2012 18:55:29 -0000


I did seen this previously, but it is interesting to see it appear

I am one of those who implement greylisting.  I have experienced the
negative aspects you describe in the document.  Perhaps the most frustrating
is that I have found two service providers that do not properly deal with
greylisting, or perhaps I don't deal with them properly.  These service
providers apparently have a fairly large array of mail servers and they
appear to select an IP address randomly when they re-try.  On my server,
that just imposes more delay. In some cases, messages do not get through
until I whitelist their server address ranges.

Quickly grabbing some statistic on my server for this week, the different
approaches have blocked the following percentages of mail:

Greylisting 16%
SPF         38%
Spamhaus    40%
RDNS         4%
Own RBL      2%

These numbers are not exact. I would estimate a margin of error of not more
than 1% on greylisting, SPF, and Spamhaus.

Our own RBL blocks very little right now, as I changed the algorithm to be a
bit more forgiving.  It now only blocks those who tend to be serious "repeat

I suspect if I turn off greylisting, Spamhaus and SPF will likely catch the
bulk of the spam blocked by greylisting.  What these two services do is
catch senders who are "out of policy" and who are known spammers.  I hate
being forced to blacklist domains, IP addresses, etc., but it is extremely
effective and has proven to be necessary.

I think it's useful to document greylisting for information purposes, but do
we want to make it a BCP?  The reason I ask is that longer-term, I would
think we'd want to recommend policy-oriented solutions (e.g., SPF or DKIM).
If policies were strictly enforced and properly implemented, machines
controlled by bots would not get past the policy enforcement.

I also question whether greylisting would be effective long-term.  I
actually have seen some machines re-send email.  You are right that many
just "fire and forget", but that would change if required.  So, elevating
greylisting to BCP might just force a change in spammer tactics, thus
rendering greylisting completely ineffective.

The reason I am supportive of documenting as informational is that servers
should consider such implementations and that it has utility today.  But,
calling it a "best" practice seems to be a bit much.  It's a practice driven
out of necessity, mainly because we do not have all of the kinks worked out
of policy-based solutions.


> -----Original Message-----
> From: [mailto:apps-discuss-
>] On Behalf Of
> Sent: Friday, January 20, 2012 4:22 AM
> To:
> Cc:
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-
> 01.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Applications Area Working
> Group Working Group of the IETF.
> 	Title           : Best Current Practices for Email Greylisting
> 	Author(s)       : Murray S. Kucherawy
> 	Filename        : draft-ietf-appsawg-greylisting-01.txt
> 	Pages           : 10
> 	Date            : 2012-01-20
>    This memo describes best current practices for the art of email
>    greylisting, the practice of providing temporarily degraded service
>    to unknown email clients as an anti-abuse mechanism.
> A URL for this Internet-Draft is:
> 01.txt
> Internet-Drafts are also available by anonymous FTP at:
> This Internet-Draft can be retrieved at:
> _______________________________________________
> apps-discuss mailing list