My wishlist for future MailetAPIs

[Stefano Bagnara <ap...@bago.org>]

I would like to 

1) separate concerns: mailmessage <=> mailenvelope <=> mailstamp
- mailmessage is the MimeMessage or a string representation this is what we
send in the DATA of an SMTP connection and what we receive in reply to a
RETR in POP3.
- mailevelope could be the current Mail object: contains more informations
about the delivery of the message. I would like to add here most of the
standard envelope attributes (EnvId, sender, recipients, additional per
recipient dsn requests) and a flexible way to add more informations.
Probably a good ground could be the headers defined by the DSN rfc.
- mailstamps are similar to the current mail attributes: mailets and
mailet-container components can exchange messages via this object. It is
persisted with the message but it is container/mailet-specific. We probably
could use "X-" keys and use the extensibility of the previous envelope.

2) recipients attribute: The mailenvelope recipient cannot be a simple email
address. For full ESMTP-DSN support we need to rememeber the
Original-Recipient, the Notify choice and possibly more from future
extensions. Again we need "recipient attributes".

3) recipients collection should be incapsulated: we can't expose the
collection but better expose an iterator and methods to add/remove
recipients.

4) delivery tracking: we need to support more than Bounces. "Success",
"Delay" and expanded are valid notifications. When we dispose a message we
should be forced to declare wether the message has been succesfully,
delayed, relayed, delivered, expanded or what else.

5) we probably need to expose methods to expand the message to multiple
address or to split the message for each recipient/recipient group so that
the container would be responsible to clone/copy/split messages.

And now the most important: mail -destinations-.
I think we should consider SpoolRepositories, MailRepositories,
UserRepositories, Redirects to other servers as possible destinations for
the current message. We currenly handle the "state" that is the current
position in the processing but it is not enough: why don't we use email
address to move messages between processors, from local spooler to outgoing
spooler, from spooler to remote server, from spooler to user inbox, from
spooler to specific folder of an user inbox? We could use the "old"
source-route syntax to move messages around. 
I can elaborate on this if we think it's an option.

Stefano

Re: My wishlist for future MailetAPIs

[Danny Angus <da...@gmail.com>]

On 25/08/05, Stefano Bagnara <ap...@bago.org> wrote:

> BTW we've a lot to do before this, so I prefer
> to do now something else, and to discuss destinations when we have finished
> implementing the other more defined tasks.

Good call.

d.

Re: My wishlist for future MailetAPIs

[Stefano Bagnara <ap...@bago.org>]

> Please take this slowly, and separate each proposal out so 
> that we can examine each one as you do them. 
> Propose->discuss->comit->review.
> That way I would hope to be able to give you some useful feedback.
>
> But 1st of all, +1 to modelling message->envelope properly

I will do that by adding MessageRepositories soon and merge Mail/Spool
Repositories into a single entity.
MessageRepositories are for Messages, Mail/Spool repositories are for
Envelopes (containing messages).
Eventually Mail/Spool repositories could make use of MessageRepositories for
the message storage purpose.

> on point 2 please explain this in more detail, 1st what is 
> required and why, 2nd what is your proposal, (I assume have one!).

2) recipients attribute:
Recipient to be an object having one main attribute (the mail address) but
adding to it the "attributes" in a similar way we use attributes for the
Mail object. This way I could add an "OriginalRecipient" attribute with
"rfc822;original@domain1.com" value and a "DSN-NotifyRequest" attribute with
the value "SUCCESS,DELAY" when a client issue the "RCPT TO:
<re...@domain.com> ORCPT=rfc822;original@domain1.com
NOTIFY=SUCCESS,DELAY". This is the only clean way to achieve ESMTP-DSN
support and other ESMTP extensions.

This will need changes in repositories (currently our jdbc mail/spool
repositories expects Recipients to be just an email address.

> on point 5 we need to split it when the content changes or if 
> the route forks, and expand it when the message is unchanged 
> and the route is unchanged but more recipients are added.

Exactly: we need to be sure every operation is done via Context so that we
can safely track what happens.

> As for destinations, I'm not convinced that modelling 
> destinations would help, it is likely to add confusion and 
> result in more than one way to achieve a specified result.
> I'm +1 for encapsulating and exposing a coherent model of 
> storage, for Mailets to use, but -1 to having destinations 
> explicitly set in Mail's. The destination should be the 
> result of applying a routing algorythm to the Mail, and can 
> vary depending upon the purpose of the Mailet performing the 
> evaluation.
> Destinations do not map 1:1 onto messages, even if only 1 
> recipient is specified, for instance mailinglists, moderation 
> and archiving might want to silently fork or redirect messages.
> In summary destination is not a state a message can have.

We will talk again about destinations in future: I'm plannin changes in
repositories and repository selection, virtual repository maps and other
possible new features that could help us understanding the easiest way to
implement my idea of "destinations".
One of the possibilities is to use sourcerouting informations to let mailets
to add hints on destinations. BTW we've a lot to do before this, so I prefer
to do now something else, and to discuss destinations when we have finished
implementing the other more defined tasks.

Stefano

Re: My wishlist for future MailetAPIs

[Danny Angus <da...@gmail.com>]

On 19/08/05, Stefano Bagnara <ap...@bago.org> wrote:
> I would like to
<the cool stuff he'd like to do has been mercilessly snipped/>

Stefano,

I've got a lot of thoughts on this, and some code/UML which has
informed my thinking.
What I don't have is too much time, so I'm asking... 

Please take this slowly, and separate each proposal out so that we can
examine each one as you do them. Propose->discuss->comit->review.
That way I would hope to be able to give you some useful feedback.

But 1st of all, +1 to modelling message->envelope properly

on point 2 please explain this in more detail, 1st what is required
and why, 2nd what is your proposal, (I assume have one!).

on point 5 we need to split it when the content changes or if the
route forks, and expand it when the message is unchanged and the route
is unchanged but more recipients are added.

As for destinations, I'm not convinced that modelling destinations
would help, it is likely to add confusion and result in more than one
way to achieve a specified result.
I'm +1 for encapsulating and exposing a coherent model of storage, for
Mailets to use, but -1 to having destinations explicitly set in
Mail's. The destination should be the result of applying a routing
algorythm to the Mail, and can vary depending upon the purpose of the
Mailet performing the evaluation.
Destinations do not map 1:1 onto messages, even if only 1 recipient is
specified, for instance mailinglists, moderation and archiving might
want to silently fork or redirect messages.
In summary destination is not a state a message can have.

d.

Re: My wishlist for future MailetAPIs

[ac...@jboss.org]

Stefano Bagnara wrote:
> I would like to 
> 
> 1) separate concerns: mailmessage <=> mailenvelope <=> mailstamp
> - mailmessage is the MimeMessage or a string representation this is what we
> send in the DATA of an SMTP connection and what we receive in reply to a
> RETR in POP3.

Describe?  We do not read the entire message in at once (except when 
sending out because of stupid JavaMail issues).

> - mailevelope could be the current Mail object: contains more informations
> about the delivery of the message. I would like to add here most of the
> standard envelope attributes (EnvId, sender, recipients, additional per
> recipient dsn requests) and a flexible way to add more informations.
> Probably a good ground could be the headers defined by the DSN rfc.

yes.

> - mailstamps are similar to the current mail attributes: mailets and
> mailet-container components can exchange messages via this object. It is
> persisted with the message but it is container/mailet-specific. We probably
> could use "X-" keys and use the extensibility of the previous envelope.
> 

not sure why it is container specific.

> 2) recipients attribute: The mailenvelope recipient cannot be a simple email
> address. For full ESMTP-DSN support we need to rememeber the
> Original-Recipient, the Notify choice and possibly more from future
> extensions. Again we need "recipient attributes".
> 

okay, can it be attached to envelope?

> 3) recipients collection should be incapsulated: we can't expose the
> collection but better expose an iterator and methods to add/remove
> recipients.
> 

I think I agree.

> 4) delivery tracking: we need to support more than Bounces. "Success",
> "Delay" and expanded are valid notifications. When we dispose a message we
> should be forced to declare wether the message has been succesfully,
> delayed, relayed, delivered, expanded or what else.
> 

And on a per user basis.  Not always possible with outgoing SMTP but if 
I say

To:<ac...@jboss.org>
To:<ac...@apache.org>
To:<ac...@nowherelasdfasdfadsgeghr.org>

I should be able to attach envelope information noting which receipients 
this mail has already been processed for (if I have one instance) and 
which it failed for.

> 5) we probably need to expose methods to expand the message to multiple
> address or to split the message for each recipient/recipient group so that
> the container would be responsible to clone/copy/split messages.
> 

And that probably should be envelope based or whatever because the 
actual To/Cc headers need to be kept intact

> And now the most important: mail -destinations-.
> I think we should consider SpoolRepositories, MailRepositories,
> UserRepositories, Redirects to other servers as possible destinations for
> the current message. We currenly handle the "state" that is the current
> position in the processing but it is not enough: why don't we use email
> address to move messages between processors, from local spooler to outgoing
> spooler, from spooler to remote server, from spooler to user inbox, from
> spooler to specific folder of an user inbox? We could use the "old"
> source-route syntax to move messages around. 
> I can elaborate on this if we think it's an option.
> 

+1 UserRepository

Unsure on SR and MR.  I dislike the SR as described in the Javadoc on 
the website (will d/l the new stuff in a few days, replying in between 
preparing next JBMS release).  I think there should be multiple chains 
of mailets that should not be completely aware of their context. 
meaning I might have a mailet that processes the mails in the incoming 
queue that routes mails to MailRepository.user[].folder[] if it finds 
the user in UserRepository and another that puts it on an outgoing queue 
if it finds that the domain is a "relay domain" (a domain for which we 
allow anonymous relaying to).

-Andy

> Stefano
> 
>