Serge Knystautas wrote:
>
> 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 ?)
This is a good example of a forking mail servlet! This mailet (or
whatever name we'll chose) let the original message pass throught to its
default path and produce reply to the message. This is NOT a signal.
> 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.
Preface: I don't have any idea on how to implement this :( ...
We should queque every external action (anything that will not be "undo"
if there is some failure) to a transactional object attached to the
message itself.
Need more time on this...
>
> Serge
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/>
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
