On Monday 29 March 2004 16:11, Bryan Scott wrote: > 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. 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. The main loop to read the bulk of the message (Qpsmtpd::SMTP::data()) should be able to slow down reading input if tarpitting is active, activated, and a slow-down reaction has been configured (and if this isn't done by some other method) - we probably want to explicitly reduce the size of any buffers here too to make sure a slow-down is actually effective. The main body of the system (and this is where the interaction with tcpserver and the like gets interesting), meanwhile, will also have to know how to monitor the amount of active tarpitting and to kill off tarpitted connections when the anti-self-DoS limit is reached (remember, the default setting is "limit = 0" so this kills each tarpit as soon as it is requested, so no tarpitting occurs). Extra tarpit-reacting plugins could then be written by anyone to perform whatever actions they want to perform for tarpits. Hopefully the "notes" changes will make some of this easier, but I think the tcpserver interaction is where it will be tricky... In short, each user should be able to simply enable/disable/limit tarpitting from config files only, and at the same time anyone writing plugins can extend the tarpitting behaviour as they see fit. Cheers -- Tim
