On Fri, 2003-03-07 at 16:28, Brad Knowles wrote: > At 12:57 PM -0500 2003/03/07, Marty Lamb wrote: > > > Enforcing the rule on new connections is easy, and requires nothing on > > the part of your local MTA. Dropping connections when you're not > > actually receiving the message body is also easy. Dropping connections > > while receiving the body of the message is *not* quite so easy. > > Uh, no. Bad idea. You don't want to drop connections. Some > MTAs are broken and would bounce a potentially legitimate message > (albeit one that might have some of the apparent hallmarks of > probable spam).
Poor choice of words. My intended meaning was that if we're not in the DATA phase, we can 4xx or 5xx after anything the remote MTA says. > You want to refuse the connection in the first place. That's the > hard thing. Actually, I think we want to drop the connection request rather than refuse it; this wastes even more time at the remote MTA with no extra effort. This kind of behavior is out in platform-specific-land, but I intend for TarProxy to write out its "offender" list (with a configurable forgiveness time) to a file. For linux (and other?) installations, it would be easy to write a bash script that executes a bunch of iptables commands based upon its contents to accomplish exactly this. > > An even more (overly?) polite mechanism replaces #3 above with a > > graceful 4xx or 5xx message to the remote server. > > > > Did I understand your question correctly? > > If the connection had already been accepted (and you had no > control), then subverting it and handing back a 4xx response code > would be the best thing to do. Just make sure that you don't 4xx the > same message for too long a period of time, otherwise it would be > inappropriately bounced. So, you might need some sort of scoring > mechanism. Yeah, the more I think about it, the sooner I think a store-and-forward architecture would be good. TarProxy could connect to the local MTA up to the DATA portion, then QUIT at the local MTA and store the data and some kind of identifying information (hash or something). It could then tempfail (4xx) the message, or upon accepting it, reconnect to the local MTA and replay the message portion of the SMTP conversation up to the DATA command. - Marty -- Marty Lamb Martian Software mlamb at martiansoftware dot com ---- : The tarproxy-list mailing list is archived at : http://www.mail-archive.com/tarproxy-list%40martiansoftware.com/ : : To unsubscribe from this list, follow the instructions at : http://www.martiansoftware.com/contact.html : : TarProxy's project page can be found at : http://www.martiansoftware.com/tarproxy
