> From: John R Levine [mailto:[EMAIL PROTECTED]] > > if you accept mail for a domain at all, > you have to accept it mixed in with all the other domains for > which you accept mail.
I agree completely; what I'm trying to find out is if any MTA's take an extra step and group by the IP address rather than simply the MX host name. As far as the store-and-forward aspect, I understand your point, but the purpose of this filter to to analyze the SMTP protocol, in real time, and make decisions about whether or not the client is a spammer. In effect, it is a proxy; for each session it is connected to both the client & the server. It looks at lots of things; the HELO, MAIL & RCPT commands, as well as other sources of data - our SQL database, DNS blacklists, spamtraps & what-have-you. At some point, hopefully before the DATA command is issued, the points are tallied up and as soon as a threshold it passed, all SMTP commands are rejected. This can happen at any stage of the session. It needs to connect to the "real" SMTP server because the filter also monitors the response to the commands and draws information from them. The whole point is that sometimes the commands and responses pass through untouched, and sometimes the filter acts on the behalf of the SMTP server. It _could_ do store & forward, but I'm not going there; that defeats the purpose of this as a filter and not an MTA. > If I were intent on implementing this bad idea, I'd assign a > bunch of virtual IPs to the machine doing the filtering Thanks for that advice; I was hoping to not need several /24's just to implement this. I guess I need to experiment with a few test subscriptions. A question - why do you think this is a bad idea? I'm assuming I didn't make a clear-enough description in the first place. -- Rick
