Oh, you didn't mean throttle by id/password pair. You meant throttle
purely by user ID.
An important reason not to have a pure user ID block is it provides an easy way
to block someone's access to their email: Simply set up a system to constantly
bang on their account with the wrong password, and they're effectively locked
An alternative is a pure user ID slowdown (as opposed to a complete block),
but there are limits to how effective this can be. Bad guys can afford to be
patient whereas legitimate clients time out pretty quickly, turning a
slowdown back into a block.
There are two reasons (well, at least -- maybe more) why this doesn't help
as much as it sounds like it would, particularly in the case of SMTP AUTH.
One is that the attacker just changes the pattern of their brute force
search to distribute it across more known accounts or across more time, so
they just probe more accounts with fewer passwords. It's all the same to
them; they're just doing a combinatoric search, and varying parameters
that way doesn't have too negative of an impact on their ability to
Another reason is more specific to SMTP AUTH: dozens of incorrect login
attempts for the same username is a common *legitimate* pattern for users
who have a single misconfigured device (a typo in their password, for
instance. (And thanks to cell phones, those failed logins often come from
a huge variety of IP addresses.) SMTP UAs often retry authentication
pretty aggressively and will happily look like an attacker. If you lock
an account for that pattern, you can lock out that user's other legitimate
devices. Web sites usually don't have to worry as much about automated
incorrect legitimate login attempts.
I note that this also applies to IMAP and POP3. In fact the most common
case is probably going to be legitimate IMAP clients banging on the door.
Sometimes a single client even does it from multiple threads.
ietf-smtp mailing list