Re: [Shutup] [ietf-smtp] Levels of proposals

Russ Allbery <> Fri, 04 December 2015 03:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8B3ED1B2C8B; Thu, 3 Dec 2015 19:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yfHyh-5uZBX4; Thu, 3 Dec 2015 19:48:55 -0800 (PST)
Received: from ( [IPv6:2001:470:30:84:e276:63ff:fe62:3539]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A25B61B2C89; Thu, 3 Dec 2015 19:48:55 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE9C81186F0; Thu, 3 Dec 2015 19:48:53 -0800 (PST)
Received: by (Postfix, from userid 1000) id 598B7B40739; Thu, 3 Dec 2015 19:48:52 -0800 (PST)
From: Russ Allbery <>
To: Ted Lemon <>
In-Reply-To: <> (Ted Lemon's message of "Fri, 04 Dec 2015 02:39:35 +0000")
Organization: The Eyrie
References: <> <> <> <> <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Date: Thu, 03 Dec 2015 19:48:52 -0800
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
X-Mailman-Approved-At: Fri, 04 Dec 2015 00:11:43 -0800
Subject: Re: [Shutup] [ietf-smtp] Levels of proposals
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Dec 2015 03:48:57 -0000

Ted Lemon <> writes:

> I am still a bit puzzled: how does increasing the number of attackers
> help to bypass the throttling mechanism?  Why isn't the throttle per
> id/password pair, rather than per ip-address/password/id triple?

Why would you throttle per id/password pair?  The attacker doesn't try the
same pair more than once.  That would be pointless.

Let me try explaining this from a different direction.  Suppose you are an
attacker.  You have a list of 10,000 common account names, and a list of
10,000 common passwords.  You want to try each of those passwords with
each of those account names and try to find a combination that works.

If you connect from your compromised host and start plowing through the
100 million combinations, after the first few thousand that you try from
that host any decent authentication system will go "hey, there are tons of
failed authentications from this one IP address" and block all further
attempts, successful or not, from that IP address.  That's pretty easy to

So what the attacker does instead is use their botnet of a million
compromised personal computers (that's sadly not really an exaggeration),
and has each one of those hosts try 100 combinations and then disconnect.
This is now below (or at least near) the threshold for an actual customer
typoing their address or password or something, and rate limiting becomes
fairly useless as a defense.

> Secondarily, if distributed processing makes throttling per id/password
> pair difficult, why is it hard to do the botnet IP address matching at
> the authentication point?  This seems like it would avoid a _lot_ of
> extra processing.

Chris addressed this quite well in his message.  I don't really have much
to add to what he already said.

The TLDR in case something about that message was confusing is that only
the authentication point can block the IP addresses at the authentication
point, but you can analyze Received headers to do a bunch of other things,
such as determine compromised botnet IP addresses that someone else
*didn't* block but that you *do* want to block for *your* service.  It
improves the scale and flexibility of what you can do by basically giving
you more threat intelligence.

Russ Allbery (              <>