Why would they be different? acceptConnection() could be backed by a DNSRBL, for example, and would want to return the TXT record explaining the reason for the block. At least that was my consideration.
Here's where I said I expected these listeners would go as we don't seem to be on similar pages.
a) acceptConnection() happens between accepting the socket and sending EHLO/HELO. This has to be a boolean because you either disconnect immediately or accept the connection and send EHLO/HELO.
b) acceptRecipient() happens between receiving a RCPT TO command and sending the response. This has to be a int code and String message because that's what SMTP's protocol requires back. We might return a boolean, but it seems important to return the specific error code. We might return just an int error code, but it seems helpful to optionally let a developer give a more tailored error message.
Your comments related to acceptRecipient are interesting. It sounds as if
you interpreted it as being a single call that would handle all cases
related to RCPT TO.
I don't understand what you think I'm saying. :) To me this is an API where you can list classes that implement each of these handlers for each of these accept situations. As these events happen, these classes have the appropriate method called.
For acceptRecipients, the results would be constants (for most cases), and as long as the result was positive, it would flow through to the next. The first non-positive response would get spit out to the connection and the RCPT TO command failed.
> I had figured that we already had code to check for
everything except for evaluating the recipient string, so I was just supplementing what we already had, rather than replace doRCPT(). I don't believe that a single method for checking all conditions would be as flexible.
Hmmm, from my perspective, this API would replace nothing we already do as we have historically had no fast-fail capabilities (aside from what's just been added).
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
