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
