- acceptConnection() could know nothing but an IP address. And I would see it returning a boolean. This would happen between accepting the connection and print the HELO/EHLO message.
- acceptRecipient() could know the remote IP address, the send email address, the SMTP session authentication info (if available), and whatever else that could be garnered from the SMTP session to date. This would likely need to return both a error code (550 etc) and a text message explaining why. What about a struct-like class with these 2 fields, and then a bunch of constant values. (OK is 200, 550 is a stanard rejection, and whatever else). The user could then return custom error message if wanted, but otherwise James would it. This would happen between RCPT TO from the client and defines the message we send back to the server.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
Noel J. Bergman wrote:
What I have in mind is a ProtocolResponse class that looks like:
class ProtocolResponse { int code; String text; }
The filter methods would return null if there is no error, or a ProtocolResponse. That is ALL that we would permit. No mailets in the protocol handler. This is strictly a means to handle protocol responses. I had originally call the class ProtocolError, but it occurs to me that a commandmap-based protocol handler could use this generally.
Two new methods would be:
- IP based service check ProtocolResponse acceptConnection(String remoteIP);
this is probably the correct way to deal with DNSRBL if you don't want to provide any service, rather than reject RCPT TO commands, immediately provide a 554.
- RCPT TO checking ProtocolResponse acceptRecipient(String recipient);
Those would complement the filtering we already support via internal mechanisms:
- maximum message size - IP based relay denied - SMTP AUTH based relay denied
Again, this is not to replace the matcher/mailet pipeline. It is strictly a means to control protocol response to protocol commands. If we like how this approach turns out, then we can consider using it more generically in later revisions to the handler, and in other protocol handlers.
Thoughts, suggestions, flames?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
