On Mon, Mar 29, 2004 at 09:18:41PM +0000, Tim Meadowcroft wrote: > On Monday 29 March 2004 16:11, Bryan Scott wrote: > > There are some portions of the thread that suggest doing a little more > > damage by using up bandwidth and letting the remote end send the entire > > payload (with multiple resets/retries to really waste resources). That > > wouldn't be something SpamCannibal or any other iptables-only > > implementation could do. Hence the idea to make some kind of broken > > vaccuum plugin to which we direct all junk connections. > > > > One question that didn't get touched on is how to determine who to add > > to the tarpit. Is that something generally left up to the individual > > mail admin, or would/should it be keyed off other plugins (perhaps via > > transaction notes)? Once it's created/tested/working, I would assume it > > would end up in the main distribution of qpsmtpd, and those who aren't > > as into programming wouldn't want to have to go into each plugin and > > add/enable support for it. (If I were to write it, for example, I would > > want to make it as flexible as possible and easy to implement; heaven > > knows my other stuff is so entangled into my own setup. ;)) > > I anticipated adding a new plugin return code (cf DENYSOFT, DECLINE etc.) of > DENYSOFT_AFTER_TARPIT (or some snazzy name) which would, depending on a > master tarpit config, do one of the following: > > - do no tarpitting and act as if DENYSOFT was returned (this is the default) > > or > > - continue as if DECLINE was actually returned, but let each subsequent > plugin know that tarpitting has been requested, so if the plugin knows how to > react it can do so (sleep between input, spurious responses, spamassassin may > decide to ignore the message as we know we're going to discard it, > qmail-queue for example would just discard the message if it got that far,). > Any actual DENY from these plugins would act as normal, but if they DECLINE > then we continue tarpitting.
Let's not overload return codes if we can avoid it. I'm not sure whether the return code can be changed in a DENY plugin, but ideally your tarpit code should just live there - catch the DENY, and if your tarpitting according to your tarpit config add a tarpit connection/transaction note and change the return code to a DENYSOFT if you want. > I could then patch existing plugins (especially those early in the > conversations) to replace selected DENY returns with the tarpitting option > (recall that under the default master config these will act as before in that > they DENY immediately), and write an extra tarpit plugin that does the real > DENYSOFT of any tarpitted mail after the data_post is complete. The master > config may also say which plugins are allowed to tarpit (so you can decide to > only tarpit selected types of spammers), again any plugin that returns > DENYSOFT_AFTER_TARPIT but isn't, according to the master config, supposed to > tarpit will instead be considered to have returned DENYSOFT etc. And ideally, don't change existing plugins at all. Isolate your tarpit magic to a special tarpit plugin, and register it first for all hooks, and do whatever you want at each stage if your tarpit notes are set, returning OK to skip all remaining plugins for each hook. Or just pass off to spam cannibal instead if you don't want to go the smtp tarpit route. I think adding tarpitting changes to the qpsmtpd core is more dubious - is the additional benefit really worth it? Maybe if you want more serious SMTP-aware tarpitting than you're going to get from plugins it's time to build a separate daemon altogether? qpsmtarpitd anyone? :-) Cheers, Gavin
