I agree with some of your comments, I disagree with some others. In general, I would rather not artificially restrict the approach to implement a usage policy. And we have other services, e.g., NNTP, where this could be useful.
It is incorrect to say we have other services. There is only 1: NNTP. POP3 and IMAP (which we do not have) do not relate to mailets. Fetchmail we can only fetch whole messages so is not affected by SMTPACL.
SMTPACL is attempting to expand the use of mailets, which are already heavily tied to SMTP processing, to a faster-fail environment. More on NNTP below...
I would permit something like:
<filter event="<event>"> </filter>
This implies there are more protocols and events than we actually have. If there are others, let's list them and figure out a pattern.
so that one might be allowed to say:
<filter event="<CONNECT>"> ... DNS RBL checks ... </filter>
This doesn't really relate to the mailet API, instead to our server-container. A basic interface addresses this:
public interface ConnectionCredential {
public boolean accept(InetAddress);
}This should be part of Avalon and if/when we add this, we can pass it back to them. Are we sure this is legal for a mail server to reject this way, except temporarily such as responding to a DOS attack?
<filter event="MAIL FROM">
... sender checks, e.g., sender in fake domain or SPF ...
</filter>
This is a possible place to check grant you.
<filter event="RCPT TO">
... recipient checks, e.g., quota, relaying, etc., ...
</filter>
This is the area that we have been discussing which the SMTPACL and my changes address.
Leaving the choice of what and when to the mail admin, or possibly some future RFC.
Yes, this is about giving the mail admin choices of fast-fail. But you're suggesting a solution to give RFC authors choices. Also I had asked the mailing list a few months ago whether we wanted to evolve James towards a richer mail server (gear it towards mail admins) or collection of mail protocol implementations (gear towards Java server developers). The response was overwhelmingly towards the former, and I think your ideas speak to possible issues of the latter.
And, just as a talking point, I think that we may want a Mailet that explicitly provides a return code and message so that we can better collect statistics.
I believe that was addressed. If you mean to separate the two pieces of data, then you've hardcoded responses to how SMTP handles responses.
In terms of NNTP, I don't know enough about how we're using mailets. But, in NNTP you can either retrieve the message headers or the full message. So in terms of supporting a fast-fail notion, you could allow matchers & mailets declare they can operate on a partial MimeMessage (though I'm not sure how you would represent).
But rather than hash any of this out now, I think we should do it post-release.
I look forward to the hashing and nashing.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
