OK, by way of maybe tying up this thread (which has wandered OT but in interesting ways for me) I'd like to summarise what has been said and then talk about where it goes next.
But first, to tie up a loose end: <loose_end> On Sunday 28 March 2004 11:25, Peter J. Holzer wrote: > Yes, but that's only because the OS chooses unused port numbers (not > socket numbers) if left to its own devices. The application can easily > reuse the same port for all outgoing connections, if these connections > go to different hosts or ports. You are very right: as you plainly show you _can_ force reuse of port number if required in the client (perverse, but possible), but the default behaviour is that clients get a fresh transient port per connection. > It can't break anything, because the FTP protocol requires the server to > originate all data connections from port 20 (unless explicitely told > otherwise by the client). So such breakage would be detected the first > time somebody tried to implement an FTP server on that OS. I was meaning more that I've seen plenty of code that, when opening multiple client sockets (using straight socket() + connect()), keeps track of them by a data structure keyed on port number - so if a new TCP stack decided (legally, but different from "standard practice") to reuse port numbers these existing apps would break as they assume different sockets will be on different ports - the apps would be at fault, not the stack, I admit, but that's the problem with changing default or "standard" behaviour. </loose_end> So, my original question was about the wisdom and/or interest in adding a form of tarpitting to qpsmtpd to particularly punish distributed spam clients on asymmetric connections, and the consensus seems to be: - there may be groovy ways to do this already using external tools (iptables, spam-cannibal) that I should look into, and look at how any scheme can work with tcpserver, SelectServer and the like. - if I do code some suggested patches to qpsmtpd, then any system should probably be available to all plugins to both signal a tarpitting is required, and to then decide how to act if tarpitting has already been signalled - there are changes underway to the code for new configuration files which will include "notes" (presumably per message) which could make some aspects of this much easier, but this change is progressing slowly - the default config for any such tarpitting should be "turned off completely" for those who just want to reduce their "wasted bandwidth" or who, rightly or wrongly, don't believe that tarpitting will achieve much. When turned on it should include some form of limits to prevent DoS'ing yourself. - me running an SMTP host (and sending SMTP out) on a home cable connection is not the norm for the people on this list, and I should count my blessings that I'm still allowed to do it ;^) - no one should expect miraculous overnight results from tarpitting , SPF, or anything short of a wholesale change of heart by not only the existing but also all future spammers. A series of changes (legal, infrastructure, system etc.) should aim to eventually make spamming not financially viable, but this is quite some way off. Phew - did I miss anyone's point ?? Apologies if I mis-represented anything. Now I suppose I just need to start looking at the code in some more detail. I'll post to the list when I get close to having something worth discussing. Cheers, and thanks to all for all the banter.... -- Tim
