What I want is to have tools to implement full DSN support in a mail
server implementing the mailet apis.
A scenario:
In the MAIL FROM an ID can be specified for the message, for tracking
purpose: we can put this in the Mail object, but we have to make sure we
know what happens to that mail and we have to decide wether to keep the
ID for a cloned mail or not (so the container need control over this
process).
In the RCPT TO a NOTIFY and an ORCPT can be specified: for each
recipient you can specify what was the original destination address and
what kind of notification you want. We can put this in the Mail object,
again, but we have to make sure that when the mail is splitted/forwarded
we correctly update this data.
The only solution to this issue I found is to define container methods
(context methods) to "declare" what kind of processing is done to the
routing.
As an example after a LocalDelivery mailet the container should be able
to notify the sender if he requested a NOTIFY=success. with a
ToRepository it depends: we should ask mailet writer to define the
result of the processing of that mailet.
I think being able to let implementations to support DSN is a *must* for
the next Mailet APIs: I'm open to any suggestion/proposal on how to make
this possible.
Stefano
Andrew C. Oliver wrote:
2) I think we have to add something better for the routing than Mail
service(Mail mail). We need a way to split a message into multiple
parts and let the container know this happened, we need a way to
bounce a message and let the container this happened, to forward to a
different address and let the container know this, to expand it to
multiple recipient and again let it know to dad.
Yes...bounce messages. I have a whole barrel of them from things that
scan the net and falsify the reply-to. Yes I know it is in the spec,
but generally turning it off should be an option.
I'm under convinced that the mail needs to be broken into multiple parts
and the container informed (this is should be about queues).
MailetChains process Queues (you guys call these Spools)
MailetChains post to Queues
Any mailet can terminate the chain (by returning null)
However I agree that more is needed for status. An idea that has been
discussed before on james-dev (some years back) and amongst our group
(some time back) was the concept of an envelope. In addition to moving
the attributes off of the Mail object (which can instead purely
represent the mail), we could add something like terminate(reason) that
the container can check to see if it should bounce the mail (by policy).
Postfix among others actually have a separate bounce queue. But I think
that I prefer the notification "this failed, here's why" and leave it up
to the container implementation (again my config will be "eat it" or
possibly "eat it unless it has a nice spam rating").
-Andy
