> 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.

That approach doesn't allow the server to return a 421 or (more importantly)
a 554 reply, e.g.,

 421 - SMTP service temporarily unavailable.
 554 - SMTP service denied due to block list; see: <text>

The 554 isn't in RFC 821; it was added in RFC 2821.  In any event, that's
why I'd thought to use a ProtocolResponse object, so that the failure reason
could be reported.

> 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.

I absolutely agree with this, which is why I had proposed the
ProtocolResponse class, which would be the return value.

> 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.

Seems reasonable.

> 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.

Right.  I'm just not sure why acceptRecipient needs to know anything more
than the address.  For example, it isn't responsible for SMTP AUTH.  That is
something else.

> 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).

Agreed.  The thing that threw me in your reply was the comment about
acceptRecient needing additional context.

        --- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to