Message Refactoring

[mikezzz]

Before delving into the Mailbox changes I would like to refactor the Mail/Message class hierachy. One of my pet annoyances is that the Mail object is very tightly coupled to the SMTP protocol and each area that uses message implements is own implementation of the Message interface. Data is constantly copied from one implementation to the other. Also every folder will contain a copy of the message object (exluding the body).

The things I would like change would be:

- Single Message implementation. Various modules that use messages could still implement the Message interface, but should delegate rather inherit the behaviour of the Message implemenation.
- Decouple message creation from the SMTP protocol. Have a MessageFactory object (possibly MBean) that can create message objects from protocol agnostic parameters. E.g. Input Stream, String, byte array.
- Normalise the Folder/Mailbox schema. Currently copies of all of the headers are placed in each foldered. We could instead store a reference to the Messages table and each 'MailboxMessage' could contain that reference and instances of the properties specific to the mailbox. E.g. flags (Read, Replied etc.).

I am interested in hearing thoughts on this structure. Especially the normalisation part as this would be the most fundamental structural change. Is there any good reasons not to do this? Handling reference counting of deletes is one possible complexity that is introduced.

Mike.

[acoliver]

* Ditch message and just use Mail. I meant to do something with Message vs Mail but no longer.

* No MBean for message creation (performance matters). I'm underwhelmed with a factory here vs just constructor messages. I don't care a whole lot either...too bikeshed for me.

* I'd actually like to see the concept of an Envelope which can store routing/delivery information. That would eliminate some of the issues.

* Messages will need multiple "parts" which means multiple store references (mime parts, etc).

* Messages will need to know how big they are (quotas). Haven't thought this 100% through yet on how quotas will be implemented efficiently.

-Andy

[acoliver]

Actually in retrospect the "factory" might be best coupled with either the store or mailbox and maybe it should be a service since there are multiple ways mails might be constructed...

[dsicore]

* I'd actually like to see the concept of an Envelope which can store routing/delivery information. That would eliminate some of the issues.

Is JBMS going to have any form of anonymity?

Any anonymous remailing support?

Just curious.

[acoliver]

Aka "spam server" -- no plans for this. Not that you couldn't create a SpamMailListener that would provide it, I actually want to reduce the anonymity of email on the net as a whole. I don't see being able to email someone without disclosing your real identity in terms of a "privacy right" or whatever. Now we probably will have some form of bulkmailing features (aka a company sends non-unsolicited spam aka "opt in" the real kind). However, it won't be "anonymous" just aliased.

[dsicore]

I don't think I've ever received a piece of spam from an anonymous remailer (i.e., a *real* remailer, not a zombie windoze box). Unless, it was deceptively repackaged minus the crypto.

I'm just talking about mixmaster or similiar style remailers that support encryption and pseudo-random routing.

See: http://en.wikipedia.org/wiki/Anonymous_remailer

Anyway.... ignore me. Move along.

[acoliver]

Oh man...if we do that Bush will ship us off to Guantánamo. If someone shows me a business case for that I'll add it into the project plan. If someone WANTS to implement it, we'll take the patches, but my efforts are all to eliminate privacy and anonymity from email. Though granted I'll take that maybe the servers in between have no business knowing provided they know it is legitimate...there in lies the problem. Ultimately I consider spam a bigger problem and favor the security of the services delivering it than the identity of the sender. Remind me never to piss you off again....I don't know who your friends are... :-) :-P