On Fri, 2003-03-07 at 03:47, Brad Knowles wrote: > At 11:48 AM -0500 2003/03/06, Marty Lamb wrote: > > > A spammer can certainly open several simultaneous connections to an SMTP > > server, which is easily accommodated by enabling TarProxy to limit the > > number of simultaneous connections from any given address. > > With which MTAs can you limit the number of connections by source > address? How?
TarProxy will enable this via configuration files. I'm still working out the details so it's useful without too much scope creep. As it exists in my head, it will work in conjunction with whitelists to allow unlimited connections from certain addresses. Note however that in general you'll WANT TarProxy to accept as many connections from spammers/relays as possible. When too many connections are held open, some logic needs to be applied to decide which connections (if any) should be dropped. Perhaps we could continue this in a different thread? I'm not crazy about this thread's title. :) > > > It's been mentioned on the list already but I think it's appropriate to > > note here that open relays will NOT modify their software to increase > > the number of simultaneous connections they make. Since open relays are > > most likely the bulk of the problem (I'd love to see numbers that can > > substantiate or refute this), TarProxy might have significant impact. > > Very few open relays exist any more. See > <http://www.imc.org/ube-relay.html>. Since August 2002, less than 1% > of the tested servers are open. That's both interesting and encouraging, but there's a type of relaying it doesn't address - http form-mailers. Since I launched my website almost exactly a week ago, I've already had several http probes for /cgi-bin/formmail.pl. With my current vocabulary I can only categorize webservers that mail without restriction as open relays. > Now, one concept that I've been rolling around in my head, is > somehow using tarproxy (or something like it) to temporarily refuse > to accept a mail message, for a given period of time (e.g., a day or > three). Not only do you slow down their connection to the maximum > allowed by the spec, but you go so far as to make them keep the > message until you're ready to finally allow it through a few days > later. > > Spammers won't bother to queue the message on disk, and they'll > just throw it away. Any relays that they pay for will have some > serious disk space & disk I/O capacity issues. > > Any false positives should ultimately make it through the system, > even if they are significantly delayed -- unless they're being sent > from a mail system that has a maximum queue delay of less than the > period of time where you'd be tempfailing them, in which case they > need to get a better mail server. > > In essence, this just extends tarproxy to the logical conclusion > -- not only do we delay their connection by several minutes, we delay > the message itself by hours or days. I recently subscribed to the asrg mailing list (http://www.irtf.org/charters/asrg.html - pretty high traffic) to lurk in digest mode, and one poster suggested exactly this. His implementation tempfails the first receipt of EVERY message. I was surprised when he cited only a 20% decrease in spam as a result (it's GOOD, but I thought it would be much higher). This seems to indicate that 80% of spam messages either go through some sort of relay or originate at a spammer's server that actually DOES retry. My unbacked assumption is that its mostly the former, and as you suggest, this should have quite a dramatic impact on relays. A feature like this shouldn't be terribly difficult to implement when TarProxy moves to a store-and-forward model. - Marty -- Marty Lamb Martian Software <mlamb at martiansoftware dot com>
