Aside from the discussion "how to ?" in the mozilla mail/news-newsgroup, I'll add this as a bug (for tracking when this feature is/gets implemented). If akkana@netscape.com is right, the feature is implemented yet througth "berkley mail folders", but needs to be implemented in the mail prefs dialog. No more hidden features, please !!

I'm marking the severity as enhancement since that's what this bug is tracking.

I must have missed where this started; I'll take a stab in case someone can set me straight and leave this better defined. I take it that Berkeley mail folders ("mbox" files hereafter) are found in a particular place for local Unix mail, and that it would be nice if we would notice them and present the folders along with others that are part of the mbox files that appear in the profile directory hierarchy?

Unix typically delivers the user's mail directly to a file called /usr/mail/[username], /var/mail/[username], or /usr/spool/mail/[username], depending on the version of Unix. This file is a standard Berkeley mail style file. This is just for the inbox; other folders are stored somewhere under the user's home directory according to the whims of the mail program (just like we do it). We'd need to have a way of setting the location of the inbox (or at least the so-called spool directory where it resides, under which the file is stored by username) in preferences, a way of telling biff to check that file periodically for new mail, and if we have local database files like we did in 4.x, we'll have to put them in the user's local popmail directory since the spool directory isn't guaranteed to be writable and even if it is the user shouldn't be creating other files there. That should really be all that's required to support Unix mail delivery.

Hmm, thanks, that's clearer to me now. cc David Bienvenu, and I expect no action until I talk this over with him, since currently he owns the general way files get distributed in locations. So I read this enhancement as, 1) permit the notion of "mail inbox" to be bound to a specific location (path in the Unix case), but where 2) support files like msf summaries for a "mail inbox" might live someplace entirely which might also need an explicit binding, and that 3) whether or not biff currently checks files someplace else, it also needs to check this one.

As I put on the newsgroup, I don't think this is feasable, and I think it would require architectural changes that would not be worth the gain in capability. Furthermore, I don't think this is the proper way to handle unix mail. Just because /var/mail/alecf is in Berkley Mail format does not mean we should just point the INBOX there. This is not a hidden feature either, it just won't work.

> As I put on the newsgroup, I don't think this is feasable, and I think > it would require architectural changes that would not be worth the gain > in capability. But I think it would be feasible to stay willing to see an mbox file that lives outside the profile hierarchy, although this could allow contention between two processes which have separate profiles, but both point at some mbox in a neutral third location. I assume you are saying an infeasible architectural change is involved to accord "inbox" status to such an oddly located mbox file, as opposed to the difficulty in accessing anything outside a profile's space. > Furthermore, I don't think this is the proper way to handle unix mail. I don't know the proper way myself; I'm just a wind-blown leaf here. :-) > Just because /var/mail/alecf is in Berkley Mail format does not mean we > should just point the INBOX there. This is not a hidden feature either, > it just won't work. Okay, let's drop the inbox aspect. Then we have a different question: can we just show an mbox file from some random location as a folder, even if we don't want to do anything interesting to this folder? If we could, then a user could say to themselves, "I know I am using that file as a inbox in some context, and I can at least read the content in Mozilla even if it is not treated as the inbox I think it is." Maybe that breaks folder hierarchy, since such a random mbox has no clear relation to the folders in a profile, other than a top sibling.

This bug is assigned to me, but I really have no way to go forward unless folks tell me more. I'll have to hand it off to someone else if it is currently in done statue that cannot be evolved more.

ahem, done state, not done statue.

this RFE has nothing to do with poor davidmc. he's not even a linux guy. (although I'd glady set him up with a linux box if we can get him a PC...) re-assign to me

my comments from the newsgroup thread: > > 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.

marking m15 the thread on n.p.m.mail-news starts here news://news.mozilla.org/375D61D1.B3CD128F%40informatik.med.uni-giessen.de

(Changing qa-assigned.)

<Change QA assigned from scurtis to lchiang - for now>

-> helpwanted

adam has submitted a patch for this. I'll go mark one of these two a duplicate.

move to M16. Not M15 stoppers

> I'll go mark one of these two a duplicate. Actually doing this now. *** This bug has been marked as a duplicate of 11049 ***

Mark it verified/dup.