Fighting Spam with Qmail (part II)
Part II of the series. In this article, we replace qmail-smtpd with qpsmtpd, which is more flexible and spam-aware.
Part II of the series. In this article, we replace qmail-smtpd with qpsmtpd, which is more flexible and spam-aware.
Your article forgets to mention the major problem with doing
user lookups in qmail-smtpd.
Spammers can use this to harvest valid email addresses with
very little bandwith utilization. (which is their limiting
factor anyway)
The best technique (if your are worrried about spam server load)
would be to have a "frontline" mx box that recieves everything,
a scanner box that recives emails for valid accounts from the
mx box, and a separate storage/pop server.
The mx box in this case handles invalid email bounces for all
others.
Bob Black
Well, it's really a problem.
If I do what you propose, then when a spammer tries to harvest the addresses, he harvests some of them (the ones that take the bait), and my front server handles a bazillion deliveries and bounces.
Either that, or email for invalid addresses doesn't bounce (which is way easier to achive in other ways, too ;-)
If the smtpd verifies the user, then spammer harvests most or all of the addresses, but the server lives and my bandwidth is unused.
I think it's a better idea to let them harvest (it's gonna cost them anyway, specially once tarpitting is on, he still has to try millions of addresses), and later block the spam.
Really a lose/lose situation :-P
> Really a lose/lose situation :-P
Unfortunatley.
how is the harvesting done? by a shotgun method, ie those that dont bounce have to be valid?
William: pretty much. Now that you make me think about it... the common qmail behaviour, won't it make some naïve spammer think qmail servers have trillions of mail accounts? ;-)
Why not just use the patches for qmail-smtpd that allow for user checking, are battle tested in large production environments, retain the speed and security of qmail-smtpd, and offer integration with virtual environments like vpopmail?
Perl's a great language, and lots of cool apps are written in it, but the downsides for any sort of volume are just too numerous to contemplate. I'm sorry, but a memory footprint of several meg per smtp connection would absolutely obliterate my production environment.