IETF Logo Mail Archive

Fixing graylisting [was TBR]

John Leslie <john@jlc.net> Tue, 13 November 2007 16:02 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lADG2ANR022508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Nov 2007 09:02:10 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lADG2AaB022507; Tue, 13 Nov 2007 09:02:10 -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 mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lADG29Rl022497 for <ietf-smtp@imc.org>; Tue, 13 Nov 2007 09:02:09 -0700 (MST) (envelope-from john@jlc.net)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 2F72523F0CC; Tue, 13 Nov 2007 11:02:08 -0500 (EST)
Date: Tue, 13 Nov 2007 11:02:07 -0500
From: John Leslie <john@jlc.net>
To: Tony Finch <dot@dotat.at>
Cc: ietf-smtp@imc.org
Subject: Fixing graylisting [was TBR]
Message-ID: <20071113160207.GF61984@verdi>
References: <20071112150954.GB61984@verdi> <Pine.LNX.4.64.0711121633040.24448@hermes-1.csi.cam.ac.uk> <B19A0F32-9FC0-4D62-88B1-2E53200EF9E8@mail-abuse.org> <Pine.LNX.4.64.0711130943270.29574@hermes-1.csi.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0711130943270.29574@hermes-1.csi.cam.ac.uk>
User-Agent: Mutt/1.4.1i
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>

Tony Finch <dot@dotat.at> wrote:
> 
> I agree that it is a worthwhile goal to reduce the interop problems of
> greylisting, and I agree that delaying email from unknown sources might
> give blacklists time to make a decision about the source.
> 
> I think it would be more useful for you to try to fix greylisting than to
> redesign IM2000 yet again.

   An interesting challenge!

   I quite agree that graylisting needs fixing (and Doug and I did try
to sneak some fixing into TBR).

   Graylisting, IMHO, started with a simple observation that many botnets
would only try once; thus giving 50% temporary errors (blindly) would
reduce botnet spam by 50%. Obviously, spam increased to fill the vacuum,
proving that a 50% solution is effectively no solution at all.

   Graylisting progressed to a realization that botnet spammers didn't
keep state, while genuine MTAs did. Thus graylisters now try to notice
which incoming emails are the result of running the queue of previous
tries which you gave temporory errors to. This is much better, but it
is difficult because the SMTP protocol does nothing to help.

   I look upon graylisting as a temporary measure to gain time for
better information about the sender -- not just whether they keep state
and run the queues.

   We could in principle accomplish that by keeping the SMTP connection
open for however long that takes; but this feels wrong to me: it's
probably cheaper for the spammer to keep a botnet connection open than
it is for me to keep TCP state for a million spams.

   The "fix" Doug and I put into TBR is to extend the time to formal
handoff, by any amount the receiving mail system may choose, which
accomplishes much of what keeping the TCP connection open would -- at
a far smaller cost (the queue of URIs could be written to disk, for
one example).

   A part of the problem which remains unfixed is how long the sender
should expect to wait. Doug and I despaired of fixing this.

   We did add an error message saying, in essence, "You are being
graylisted." We're of the opinion that any further information should
be out-of-band (or at least not part of protocol).

   What would others like to see in a fix for graylisting?

--
John Leslie <john@jlc.net>

v2.23.0 | Report a Bug | By Email