Sorry, I didn't know of 421 and 554. Having read them, I don't know why we would support them.
Because it isn't hard, and provides additional options to the e-mail admin?
if you send these, you have to keep the connection open and continue to accept commands and return 503 until you get a QUIT.
I'd thought of that, but it is easy to catch at the top of the loop.
In my assumptions of why you would immediately not accept a connection before any communication (something based solely on IP address or excessive message rate delivery), very rarely did I care what tailored message I sent the user (not that they ever read those), and I would expect you'd want to kill the connections immediately, not wait for a QUIT. I find the fact that other mail servers do this rather than send 421 evidence that they agree with my use-cases, not that they are too lazy to provide useful error messages (although that argument could be made).
Also, I read 421 as for a server that's shutting down. It's a valid alternative to the 220 greeting, but I read this more because it's valid at all states (no matter where you are in the protocol, you need to tell the remote connection you're shutting down). We might want to think about hooking the shutdown code into the SMTP handler to adopt this notion.
What is the deal with this ProtocolResponse class name? These are two very different functions. One addresses a TCP connect request and one is a SMTP command reply.
The "ProtocolResponse" class would be used for returning a [code, text]-tuple. It fills the role that you had referred to as a "struct-like" class.
Sorry, was cranky with my note and understood your name. I meant I think you're trying to force fit some inappropriate API and as a result providing too much information and control in one situation, and not enough in the other.
We're discussing these two stages, but you're naming and arguments suggest this is something we be able to insert in ANY protocol response. I believe you would find this unworkable by examining other cases, as to generalize to this extreme would be significantly less useful.
I think the choices of where we support hooks are deliberate:
- We want to accept/reject TCP connects because we have a remote server that's pounding us, it is not in the network we like, or is otherwise a specific user we want to block or allow.
- We want to accept/reject RCPT specified email addresses because at this point we will know whether this is someone who is authenticated, and whether this is someone sending inside-inside, inside-outside, outside-inside, or outside-outside.
Adding something at MAIL FROM would only tell us "from inside or outside", not the flow. Adding something after DATA would a) not help us avoid message traffic b) lead to more complex processing that should be handled asynchronously (ie., mailets). SMTP AUTH should be extensible via a account mgmt interface, not via individual protocol response handlers. Other commands just get much less use and have less value to expose through an API.
Because it would make writing these filters more complicated, and less modular? My preference is towards smaller bits of specific functionality.
Instead of a very restricted API, why not just provide specific configuration options for the couple of expected restrictions? What is less modular about providing more information to this RCPT handler?
Finally, I have to take back the suggested returns. It's much more complicated than that...
- for accept/reject connections, you might have a specific spammer you want to always block, and you might have a static IP address DSL home user you want to always allow. You can't simply AND or OR a bunch of boolean responses together.
- for accept/reject recipient address, you have similar notions as above... specific spammers you want to always block, email addresses you might always want to allow.
Not sure what's the best way to handle these situations.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
