2007 (C) Jos Boersema, released under the GPL3, see This is free software, copy and distribute at will. No warranty. Bugreports, ^H^H make that corrections, ... Only tested on Debian/GNU/Linux.

 Put mail-files into a anti-spam delay spool: 
 This has to be called per mail-file. It tries to find out how
 many recipients the mail-file has, see source to configure.

 Spool mail-files back into the normal mail spool:
 This is a cron job. You can specify a spool speed, and you can
 specify privileged users in /etc/maildlay, that experience no
 anti-spam delay. See source to configure.

 Report on bulk-mail from unprivileged users, sends warning, creates
 This is a cron job.

 These scripts could be used to for instance slow down mail for new
 and non-paying users, or all users. A paying user could be made a
 privileged user automatically after 1 year, or on request sooner,
 then its mail is not slowed down as much.

 Normal users usually neither send a lot of e-mail, and would not be
 bothered much with a relatively small delay, since the recipient may
 not even look at its new mail for hours. If the scheme reduces bulk
 spam significantly, the cost in running the mail delay software, not
 relaying as much spam, and less time for users deleting spam, could
 make it worthwhile in total. Obviously a re-implementation in C
 would be useful (more tweaks/features).

 The system is basically a revolving door, only allowing so much mail
 to pass through from each user. Bulk spam just won't get through
 fast enough before it is noticed, low volume mail only has to wait a
 short time, since it is always in the front of its own row.
 It is basically a security feature for credible service providers,
 illegitimate spam providers are not caught. I don't see an easy
 way to do the same for mail-relay from site to site, the problem
 being you may not know the sender, the mails may not arrive quickly
 enough to build up a line, the mails may not arrive through the
 same path (?), legitimate (bulk) mail would be delayed too much.
 It is probably only useful at the point where the mail enters, for
 the rest of the route something like this is problematic.