>A test run prints something like: > >% ./test-client-same-port www.hjp.at www.wsr.ac.at www.develooper.com >=2E/test-client-same-port: www.hjp.at resolved to: 143.130.50.122 >=2E/test-client-same-port: www.wsr.ac.at resolved to: 143.130.16.131 >=2E/test-client-same-port: www.develooper.com resolved to: 63.251.223.170 >COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME >[...] >test-clie 348 hjp 3u IPv4 35579 TCP yoyo.hjp.at:18791->ashe= >rah.wsr.ac.at:http (ESTABLISHED) >test-clie 348 hjp 4u IPv4 35582 TCP yoyo.hjp.at:18791->www.= >wsr.ac.at:http (ESTABLISHED) >test-clie 348 hjp 5u IPv4 35585 TCP yoyo.hjp.at:18791->x1.d= >evelooper.com:http (ESTABLISHED) > >Both port numbers are the same for all three connections.
Thanks for clarifying this important point. It seems likely to me, offhand, that spamware exists that exploits this capability, but that plenty of (deployed) spamware does not as well. >> Anyway, bringing it all vaguely back on topic, the point of the tarpit is= > not=20 >> so much as to tie up the resources for an inactive socket, but to chew up= > the=20 >> limited upstream bandwidth of trojan DSPAM clients on asymmetric connecti= >ons,=20 > >SMTP tarpits as originally designed use very little bandwidth, and most >of that from the server to the client.=20 He might have meant TCP tarpits, but you're right about most SMTP tarpits, though some (like some of my own) intentionally let the client send the entire payload, which *does* chew up bandwidth, and then send back a temporary rejection on a delayed (tarpit) basis. For a "home-office" setup like mine, to whom spammers and vermin pay inordinate attention, and for whom chewing up some extra bandwidth in order to make their lives a little more difficult is not a problem, it's a reasonable tradeoff. But it's really only worth doing if it makes spammers' lives at least a little more difficult. Since having just my own MTA do it can't possibly hurt them, I'm interested in making it easier for lots of others to do the same. Whether one is running qpsmtpd, mailfront, qmail-smtpd, or whatever, I really appreciate the opportunity to learn about the most effective techniques that, widely deployed against spammers, won't cost individual sites much in terms of maintenance or substantially increased latencies for *legitimate* incoming email. -- James Craig Burley Software Craftsperson <http://www.jcb-sc.com>
