Glad to see there's so much activity on the mail "servlet" API. It's a
little dated, but I wrote up my notes at
http://www.lokitech.com/~sergek/james/proposal.html when I originally
submitted the code. As people are considering what model best supports
mail servlets, I think the most helpful information is in section 2.
mail servlets where I list 17 possible uses of mail servlets. These
examples are useful in trying to fit new designs to what they're trying
to accomplish. For convenience, here they are:
Sample
1.AliasesServlet -> Maps addresses, called mail aliases in Netscape's
mail server (and others).
2.LogServlet -> Records the message and recipient list to a specified
directory. Could be extended to only log in certain circumstances.
3.CheapoListserv -> A partially implemented listserv. No
administrative features, but sends an incoming message to a list of
accounts, prepends the subject with a customizable [topic], adds a
reply-to header, and some other simple features.
4.ReturnToSenderServlet -> Default servlet to run on failed delivery
attempts. Builds an error message, attaches the original message, and
sends this to the sender.
Suggested
1.VirusScanServlet -> looks for virus code and removes it
2.HTMLtoTextServlet -> looks for HTML encoded mail and strip the HTML
out
3.SpamRejectorServlet -> process the mail fields and reject the mail
on some logic
4.MailListServlet -> see example on java.apache.org
5.ImOnVacationServlet -> doesn't touch the message but replies with a
user message (.onvacation ?)
6.ForwardServlet -> forwards the message according to the list found
in user configurations (.forward ?)
7.CryptoServlet -> see example (note: the idea would be the entire
original message is encrypted in wrapped in something only the receiving
mail server could understand... thus everything (identity of receiver...
everything) is encrypted.... you could only tell it was going to this
one server).
8.SafeCopyServlet -> stores the message in a database and doesn't
touch it.
9.TimeStampServlet -> stores the hashcode of the message and appends
an indication of legal value (as www.timestamp.com does)
10.FileOnDemandServlet -> returns a mail with attached the requested
file or chuncks of it.
11.NTPStampServlet -> this overwrites the timestamping of the message
done by the client to the "correct" time based off of a local NTP server
(or the mailserver's local time) This way you don't get people's email
showing up in strange places when you sort by time sent because of a
localized machine problem.
12.LogServlet -> record some data in the message to a text file or
database (size of message, recipients (building a contact list), a way
to record mailing list traffic)
13.AnonymityServlet -> converts your email address into an anonymous
numeric address. Allows sysadmins to find out who you are, but hides
your identity from most users.
Really I think you have both responders (the email is a request and the
servlet generates a response to it), and modifiers (the email is just
inspected and possibly modified is some slight way). What about the
idea of coming up with 2 interfaces and have James support both?
And as for mail servlets, I really don't care what we name it and can
somewhat agree that servlet isn't the perfect name. Here are some other
possibilities:
- Mailet
- Mail filter
- Mail processor
- Mail handler
If we take the 2 interface approach, I would still like to have 1 name
we can generally refer to these components as... even if their actions
are different.
One more comment: I like Federico's suggestion (I think it was his) that
you process the entire message before resaving. That's pretty clever as
there's no *real* need to save emails partially processed and will
greatly speed mail processing. One note though is that if you start
forking new messages and/or handle error conditions, you'll need to save
state/messages.
Serge
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
