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.
Sorry, I didn't know of 421 and 554. Having read them, I don't know why we would support them. Sendmail and other mail servers I'm familiar with just immediately disconnect with no output. Both commands are just listed as "may" be used. Once more, if you send these, you have to keep the connection open and continue to accept commands and return 503 until you get a QUIT. This seems counter to the point of this feature.
I absolutely agree with this, which is why I had proposed the ProtocolResponse class, which would be the return value.
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.
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.
Err, why not?
-- 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]
