Michael Fair wrote: > If you do it any later then the initial attempt to > send mail into the users inbox you have not gained > anything as the mail has already gone through the > pipeline.
This is exactly right in a sense... but it's OK to _catch_ it later in the pipeline, and then as soon as some 'probable abuse' threshold is hit, add the user name to the check_client_access table. This can then be used to restrict RCPT TO. > <...> you will want > to hack the Postfix daemon to check/update a counter > and timestamp associated to the email address each > time it receives the SMTP RCPT TO command. This > integration would actually be really useful for > stopping delivery for over quota users as well. > Well, since I posted my plea for help, I've had a few beers with our webmaster and we've come up with a compromise which is lower resource usage but stops the worst of the abuse. Basically, the plan is to run a cron job (or daemon that sleeps for a few minutes after each loop) that checks for which accounts have been updated since last run (a quick hack is to look at the last update time of the directories in the imap message folder, although I'm sure others can suggest better ways), and do an IMAP STATUS on each to check for new messages, storing the result in a table and checking the delta against the last run to see whether the number of new messages is over a reasonble-use-threshold. We'd run this with a low 'nice' priority to ensure that it doesn't get lost if a mound of spam is arriving. > Otherwise, I would either pass it off as anomolous > hardly worth the resources and engineering efforts > to defend against, and then wait to see if this > practice actually became a larger nuisance than a > one time event. Michael--many thanks for the thoughtful response. Interesting to hear that this behaviour is anomolous in your experience--we've only recently started publicising our system after 2 years beta testing with a hand-selected group, so we don't really know what level of abuse to expect now that we're out in the big wide world. I'm going to at least put in place the basic response outlined above--even if it is not really necessary; our users were subjected to a few hours of very patchy response from our server, so the least I can do is to show that they shouldn't have to put up with this again... > For good measure, now that his account > has been blocked I would send him an email threatening > with abuse of resources and a more stringent quota > as a result and request a response informing me of > the correction within 72 hours. Check the logs > every so often to see if the end user logs in to > receive the warning and if not, nuke the account. > Since the case tends to be that once you are on > the spam list, you aren't getting off of it, there > will most likely be nothing the end user can do > about it and therefore have their account nuked for > abuse anyway. > Yeah, I've already sent him a message to his alternate account, but I didn't directly threaten him but rather offered help in case he's just been an unlucky target (I don't want to offend someone and just end up on the end of a DOS attack). But now that I've built a little Perl script to scan the received email headers I see that they were sent to over 500 yahoogroups mailing lists, with names like '[EMAIL PROTECTED]' and '[EMAIL PROTECTED]'... It makes me wonder if this guy was actually maintaining these lists as a way to get cheap mass mailings, and subscribed himself through his account on my system as a way of checking that they were all running smoothly. I've sent this list to abuse@yahoogroups which hopefully they'll find handy... Heh--our T&C has a clause saying that damages for SPAM are assumed to be $5 per message, so we could make a good profit from this ;-) I think I've got better things to do than to get involved in this nasty business though...
