[FEATURE] support for local unix mail (e.g. mails in /var/mail/)



MailNews Core
19 years ago
10 years ago


(Reporter: Roland Mainz, Unassigned)




Firefox Tracking Flags

(Not tracked)





19 years ago
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 !!


19 years ago
Severity: normal → enhancement

Comment 1

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

Comment 2

19 years ago
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?

Comment 3

19 years ago
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.

Comment 4

19 years ago
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.

Comment 5

19 years ago
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.

Comment 6

19 years ago
> 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.

Comment 7

19 years ago
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.

Comment 8

19 years ago
ahem, done state, not done statue.
Assignee: davidmc → sspitzer
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
> 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.
Target Milestone: M15
marking m15

the thread on n.p.m.mail-news starts here



19 years ago
QA Contact: lchiang → scurtis

Comment 12

19 years ago
(Changing qa-assigned.)


19 years ago
QA Contact: scurtis → lchiang

Comment 13

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


18 years ago
Summary: (feature) support for local unix mail (e.g. mails in /var/mail/) → [FEATURE] support for local unix mail (e.g. mails in /var/mail/)

Comment 14

18 years ago
-> helpwanted
Assignee: sspitzer → nobody
Keywords: helpwanted
adam has submitted a patch for this.

I'll go mark one of these two a duplicate.

Comment 16

18 years ago
move to M16.  Not M15 stoppers
Target Milestone: M15 → M16

Comment 17

18 years ago
> I'll go mark one of these two a duplicate.

Actually doing this now.

*** This bug has been marked as a duplicate of 11049 ***
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 18

18 years ago
Mark it verified/dup.
Product: MailNews → Core


10 years ago
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.