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 hold the 4/5xx response until after all the RCPT TO commands, and possibly until the end of the DATA phase. Otherwise, many MTAs will mis-interpret the results. This is why both sendmail & postfix have a "delay response" set of options.
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.
Too dangerous. You risk losing real e-mail, due to remote MTAs that don't properly interpret the connection being dropped.
Moreover, I can tell you for a fact that it *does* cost you a lot more resources to accept the connection and then drop it, as opposed to simply refusing the request -- think about fork()/exec() overhead, maximum number of daemon children that are allowed, virtual memory thrashing, etc....
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.
In terms of storing persistent data about a message (that is kept across sessions), I would recommend focussing on the envelope information, and keep minimal information about the body of the message (the message-id, and maybe some sort of "fingerprint").
As far as sitting in front of the MTA, you would be destroying vital envelope information -- they would no longer be able to detect the real IP address of the envelope sender, so they would be unable to apply any other anti-spam or anti-virus checking that might depend on that sort of thing. Instead, everything will look like a message generated on the local machine.
I am convinced that milter (or something akin to milter) is the only effective way to make this project work, without causing excessive collateral damage to all the other anti-spam/anti-virus checking capabilities that sites might want to implement.
That is, unless you can guarantee that you'll implement all those other functionalities as well, so that no one could ever possibly need to run any other software of any other sort.
-- Brad Knowles, <[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) ---- : 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
