pjs/mailnews/movemail

README

just a placeholder for now.

Roland.Mainz@informatik.med.uni-giessen.de wrote:

I don't know whether this is implemented or not...

Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ?

alecf wrote:

> I don't know whether this is implemented or not...
>
> Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ?
>

Hmm... my gut is telling me that nobody from Netscape will be working on this....but I'm
quite sure that if someone does feel like adding this functionality, many unix mail people
would be very pleased...

(I'm going to start calling Unix Mail "movemail" because we've called it that in past versions
of the product)

It's actually probably simpler than your description - we've done a fairly good job at keeping
the idea of POP (as a protocol for retrieving remote mail) and Local Mail (as a way of storing
mail messages locally) as seperate entities, though there is still work to be done to seperate
the two. Both implementations reside in mozilla/mailnews/local though.

the movemail implementation could leverage the Local Mail work, performing the same function as
POP is today. Ideally, Local Mail would not be aware of any protocol specifics, so that Pop3
and movemail are both first class mail protocols.

Scott or Scott could go into more specifics.

If you're interested in helping us, the first thing to do would be to try to break local mail
apart from POP in a way that POP is just one more pluggable mail protocol that stores mail in
Local Mail....if you submit patches, I'll be more than happy to review them and check them
in...

>
> - Does Mozilla 4.x implement local Unix mail ?

Yes, but the code is VERY different than our current codebase, it's fairly simple, and wouldn't
really be worth the effort of bringing it over

Akkana Peck wrote:

> Is there something else here that's tricky?  I never understood why we
> had all that movemail stuff in 4.x when we already supported Berkeley
> mail files.

I think one of the main reasons for this is because it's kind of good e-mail karma to move your
mail OUT of /var/mail and put it in your own directory. I think this is what other unixmail
clients do....

The other issue is that metadata is kept about each mailbox file - what messages are unread, the
sorting order, the character set, etc... We do this normally by keeping a .msf file with the same
name as the directory at the same level as this directory. This means that if I try to point my
inbox at /var/mail/alecf, messenger will want to create a file /var/mail/alecf.msf

It would likely be difficult to change this, because bits of our architecture depend on in

...our architecture also depends on the folder hierarchy matching a directory structure on
disk...meaning that if I have, in messenger:

Local Mail
  +- INBOX
  +- My Folder
     +- Another Folder

The assumption is that INBOX is a sibling of My Folder on disk, and that Another Folder is a
mailbox inside the directory My Folder.sbd (since My Folder is already a file, not a
subdirectory). This means that My Folder would go into /var/mail/My Folder and Another Folder
would go in /var/mail/My Folder.sbd/AnotherFolder

it would be alot of overhead to try and abstract this so that each folder's location is
independant of it's position in messenger's hierarchy. I think this overhead is not worth the
minimal gain in capability.

                                Alec

sspitzer wrote:

Alec,

> > Is there something else here that's tricky?  I never understood why we
> > had all that movemail stuff in 4.x when we already supported Berkeley
> > mail files.
> 
> I think one of the main reasons for this is because it's kind of good e-mail karma to move your
> mail OUT of /var/mail and put it in your own directory. I think this is what other unixmail
> clients do....

I just looked at the movemail code from 4.x and alec is right.

ns/cmd/xfe/movemail.c basically did this:

lock /var/spool/mail/$USERNAME
copy /var/spool/mail/$USERNAME to .netscape.mail-recovery
call MSG_IncorporateFromFile() with .netscape.mail-recovery

I'm leaving out the gory file locking details and the builtin vs
external movemail stuff.

movemail in 5.0 is like pop, but you can't leave mail on the "server",
and the "server" is really your spool file.

> The other issue is that metadata is kept about each mailbox file - what messages are unread, the
> sorting order, the character set, etc... We do this normally by keeping a .msf file with the same
> name as the directory at the same level as this directory. This means that if I try to point my
> inbox at /var/mail/alecf, messenger will want to create a file /var/mail/alecf.msf
> 
> It would likely be difficult to change this, because bits of our architecture depend on in
> 
> ...our architecture also depends on the folder hierarchy matching a directory structure on
> disk...meaning that if I have, in messenger:
> 
> Local Mail
>   +- INBOX
>   +- My Folder
>      +- Another Folder
> 
> The assumption is that INBOX is a sibling of My Folder on disk, and that Another Folder is a
> mailbox inside the directory My Folder.sbd (since My Folder is already a file, not a
> subdirectory). This means that My Folder would go into /var/mail/My Folder and Another Folder
> would go in /var/mail/My Folder.sbd/AnotherFolder
> 
> it would be alot of overhead to try and abstract this so that each folder's location is
> independant of it's position in messenger's hierarchy. I think this overhead is not worth the
> minimal gain in capability.

we have ~/ImapMail, ~/Mail, ~/News, we could have ~/MoveMail

Its all berkeley style mail boxes, and when we process the
.netscape.mail-recovery file, it writes into ~/MoveMail/Inbox (like what
pop does to ~/Mail/Inbox)

in 5.0 you could have multiple imap, multiple pop, and local UNIX mail
all at the same time.

How about them apples?

I've sanitizing the spence's old ns/cmd/xfe/movemail.c code now.  I'll
bring it over into the 5.0 tree, and start up a
mozilla/mailnews/movemail directory.

One thing:  alecf and I (the UNIX people on 5.0 mail / news) will
probably not have time to implement movemail for 5.0

It would be so cool if someone out there wanted to take this on for 5.0.

Think about it:  

	movemail users will love you
	your peers will admire you
	free mozilla t-shirts (I'll make sure you get some)

I'm adding adding this task to http://www.mozilla.org/mailnews/jobs.html
right now.