[dabean]

Firstly i'll point out i have been working on and off on such a script for the past 2 weeks. I still have a massive amount of work to do before its even near release quality.

There are few really big design decisions that have to be taken before anything like this is writen. For the record i've taken the approach to reuse as little as possible to make forward compatiblity as simple as possible.

Firstly do you resuse the existing vB privatemessage table or create a totally new table.

Advantages of a new table are you can index the fields that are important for email, and store message format (mime or text).

Disadvantage is you either end up with a uberhack that requires massive maintanace as vB advances, or a standalone hack that confuses end users by offering two similar systems.

Advantages of table resuse is that the end message display and listing code is far simpler. you can resuse vB almost as is.

Disadvantage is that you either need to alter the table structure or make a new additional table to store the sender email address.

Then on to the second really big problem, how do you store all the user preference settings...
As it stands it's complex to add radio button or dropdown list choices to user profile fields. So to store everything thats nessesary for email you need a second profile store.

The email system its self needs to store a lot of settings so you'd again need to create another table to hold those.

On to sending and recieving mail..
recieving via single pop3/imap4 account is simplest way to get all the messages.

But to send them rather than attempt to mange your own send queue and all fun that intails. Using the mail sending functions builtin to perl/php is way easier, (spoofing the from field where and if nessesary).

There are some tricks you can do with an address book to keep its size down but still its a huge addon feature.

The weird username problem can be coded round almost transparently to user, spaces can be _'d, @'s turned into at's, #'s changed depending on context etc.
or you can use go on userid number and totally sidestep the problem.

Finnally these are features i've got working so far:
- plain text email collection and filing userid based (xxx@you.com) partial filing of text usernames.
- unknown user forwarding or autoresponce (configurable).
- Sending via the same page as pm sending (right to left @ processing)
Still todo:
Message display and message index display.
MIME support
admin options
etc..