Noel J. Bergman wrote:
Sorry, to clarify what started me on that last tangent...One of the things I've considered is that if a matcher discovers spam from a currently active connection, then we could kill that connection (with a proper 5xx code) ASAP. I'm tired of spammers tying up my connections. I am also willing to limit parallel connections from a single IP address, although I see that "attack" less frequently.
I used to similarly ponder how it might be nice to add matcher/mailets within the SMTP session, but I think this is hard to configure, and I think we could hit 90% of the use cases with half a dozen fast-fail configuration options. Basically improve support and say if you really need some custom logic on accepting/rejecting messages, well the mailet API does that just fine within the regular spool processing.
Besides, the mailet API doesn't fit the SMTP command handling perfectly, so in the end I think it comes off as something of a hack trying to reuse the API in this way. You end up creating a pseudo-mail object that has no mime message but the sender and maybe the recipient list. I've found it rather awkward. And SMTP provides a way for an accepted message to be returned that is nearly as effective as not accepting it in the first place during the SMTP session.
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
