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:<[EMAIL PROTECTED]>
To:<[EMAIL PROTECTED]>
To:<[EMAIL PROTECTED]>
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
