Serge,
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.
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 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.
Thoughts?
ProtocolResponse could have final int values for protocol responses,
although those probably ought to be in ProtocolResponse subclasses because
they aren't identical across the various protocols.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 27, 2003 16:39
To: James Developers List
Subject: Re: Protocol Handler-based rejection
I would think these are two different interfaces:
- 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
