Tim Meadowcroft wrote:
On Wednesday 24 March 2004 22:53, you wrote:
Sooo.. to spike the punch a little, I decided that, rather than simply deny hosts that have no reverse DNS, why not tarpit them? Then, if they start talking before I send them an SMTP banner, let check_earlytalker take care of them. It works beautifully. At the very least, it lets me know that I'm not just dropping poor, unsuspecting hosts whose ISP's don't care about revDNS.
So I take it you'd be in favour of a mod to qpsmtpd to add a "tarpit and DENY" return code that any plugin could easily use, with an overall user set of config options to control the tar-pit delays, a maximum simultaneous tar-pitted connection count, and other tweakable options... the point you make about revDNS users is interesting, a "decline so far, but slow down this connection" return on the basis that it might trigger further mis-behaviour... I'll bear that one in mind...
I'm in favor of such a plugin. It would be neat to see.
Valid machines are *usually* going to play by the rules... Obviously we don't make it too hard for real boxes to get email in, but it doesn't have to get there instantaneously either.
The tarpitting rules could even be tied in with graylisting, where you start off tarpitting everyone (initial 10-20 second delay, then something smaller between lines). When the remote IP has successfully delivered X number of non-spammy messages, stop tarpitting them. (Or is that the tarpitting concept already?)
I already do the exact opposite for bad hosts. If a machine hits an invalid email address on certain domains, or connects from a cable/modem network (and I don't like them), I deny them for 24 hours in tcpserver's qmail-smtpd.cdb file. If they do something wrong 20 or more times (therefore over a 20+ day period), they're permanently blocked, thus saving my server the time of spinning up qpsmtpd processes that it's just going to drop anyway.
The only downfall to the latter mechanism is when customers are infected and get their IP address perma-blocked (really bad when it's a shared IP address).
-- Bryan
