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?
--- Noel
-----Original Message-----
From: Hontvari Jozsef [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 27, 2003 3:22
To: James Developers List
Subject: Re: [PATCH] AOL blocking James
The filter is a good solution. I prefer the second configuration style,
because it is similar to most others in James.
I would add one thing, the error message may optionally include the rcpt to
address. Most web servers does this. It is better in the log files and maybe
the user get more information also, which is otherwise unavailable for him.
For example this can be implemented using the java.text.MessageFormat class
and its {0} plcaeholder in the error message text.
Because the filter mechanism will likely change in the future, it would be
useful to prepare for such a change. From this viewpoint the first
configuration is better, we can define an rcpt_to2 filter later if
necessary. So I would replace the command element in the second alternative
with a type element, its value can be "rcpt_to" now.
Something different: the specific example which uses the "aol" string as
criteria is very dangerous, it shouldn't be included in the doc and config
file. I am afraid if aol detects such a customized behaviour they will block
the server once and forever.
----- Original Message -----
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
Sent: Monday, May 26, 2003 11:20 AM
Subject: RE: [PATCH] AOL blocking James
> > > Other than the inappropriately named configuration setting,
> > > does anyone want this, or something like it, included in
> > > the CVS?
>
> > Is this the direction we want to go ??
> > From what I remember, the idea was to accept all and then
> > process (reject, redirect,etc.)
>
> James is certainly not an Open Relay, regardless of AOL foolishness.
>
> I'm not particularly fond of the proposed change. However, a generic
> fails fail solution could involve an acceptRCPT_TO type method. The
> handler would be blind to it, and there could be some minimal plug-in
> support for the server. A hypothetical configuration might look like:
>
> <filters>
> <rcpt_to class="regexfilter" match="[EMAIL PROTECTED]"
> error="code" text="..."/>
> <filter command="RCPT TO">
> <class>regexfilter</class>
> <match>"[EMAIL PROTECTED]"</match>
> <error>code</error>
> <text>notice</text>
> </filter>
> </filters>
>
> which does nothing other than illustrate two different ways of expressing
> something. Although I, personally, could use either (or several other
> variants), I'm not entirely happy with the ease of expression. The only
> good ideas, so far, are to hide all details from the handler, and have a
> limited albeit flexible means of filtering on specific items.
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
