Federico Barbieri wrote:
> This looks to me like "flexibility syndrom"...
> forcing only references instead of instances is a way to keep confs
> ordered and avoid to have configs in two different palces which may mess
> things up.
>
> What is the purpose of doing things in two ways is one is enought? Just
> confusion.
I have to agree with Federico on this one... -1 to offering two ways of
configuring the mail servlets. A single section to initialize and map
all servlets to simple names is IMO the best way to go.
On the subject of configuration, I think we're letting conf options get
out of hand (myself included). I really don't think we need nested
functionality... I think servlets should handle determining whether it
has handled the message delivery... I still don't think you should be
able to return a different message and should add a feature to the Mail
message to either 1) add methods to send a new message from the servlet,
or 2) provide a method to grab the "servlet context" (the mail server)
from which you could then send the message. I prefer the latter because
a) it models the http servlet engine where you can have "application
scope" variables, b) it seems untenable that servlets have to know the
mail server's XML conf file format to get something like the
postmaster's address, and c) adds some useability to the API that
currently relies on a lot of static field names.
On routing for mail servlets, like I said I don't think we need nesting
logic... I think we ought to explore how a MailDispatcher (like an http
RequestDispatcher) could work... and I think we should move closer to
Stefano's hardcoded checks on message-servlet mapping. However, instead
of only supporting only name="" (functions off of recipient), we should
develop a set of standard message attributes you need to check (not
want). I propose the following possible conf managed mapping checks:
1. recipient
2. recipient is local (the mail server will know whether the recipient
falls within a domain that this server claims to handle, configured in
one place)
3. sender
4. sender is local
5. ip address (of remote connection)
6. host name (of remote connection)
7. subject
8. message size
9. multipart
10. spam (more on this later)
11. all (send everything... save it for the last mapping)
Then assuming elsewhere in the conf file we've specified instances of
mail servlets and mapped them to simple names, the servlet mapping part
would look something like:
<servlet-mapping>
<servlet-name>mylistserv</servletname>
<recipient>james*@list.working-dogs.com</recipient>
</servlet-mapping>
<servlet-mapping>
<servlet-name>StoreInMailbox</servlet-name>
<recipientislocal />
</servlet-mapping>
<servlet-mapping>
<servlet-name>RemoteDelivery</servlet-name>
<all />
</servlet-mapping>
The DTD would define a servlet-mapping tag of having exactly 1
(required) servlet-name tag, and exactly 1 (required) "condition" tag,
which is one of <recipient>, <recipientislocal />, <sender>,
<senderislocal />, <ipaddress>, <hostname>, <subject>, <size>,
<multipart>, <spam />, and <all />.
The more I thought about it, anything beyond very simple condition
concepts is beyond the scope of administration and would more properly
be put into the mail servlet itself. This combined with a
MailDispatcher concept would give plenty of flexibility while keeping
the admin simple and free of programming. Here's how I think the
MailDispatcher would work (very primitive right now)...
on MailServlet, you add....
public MailDispatcher getDispatcher(String servletName);
MailDispatcher would look something like...
public interface MailDispatcher {
public void forward(Mail mail);
public boolean include(Mail mail);
}
Ok, I haven't completely figured out why/how we would implement the
differences between forward and include. I also don't know what exactly
you'd pass to get a Dispatcher... is this the servlet's class name, is
it the instance name set in the conf file? I guess a getServlet would
work just as well, but at least according to the wisdom of the http
servlet spec people (which I think is justified), they removed
getServlet, because this gives direct access to other servlet
instances. You should be able to interact with other servlets for the
purpose of routing issues... not for the sake of passing other
parameters or other things that getServlet allows.
As for spamming, I think this is such an important issue, the mail
server should bundle prebuilt spam detectors that get called before any
servlet runs. This is probably an optional feature, but defaults to
true. As more people submit spam detectors, we keep adding them and
perhaps make the configuration the thoroughness to which it determines
whether it's spam... simplest checks are just for known bad addresses
and some simple ip address checking to prevent relaying. More thorough
checking would go to MAPS or another 3rd party service that blacklists
spammers, or perhaps doing other authentication against the to/from
headers. Thoughts?
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
