Closed Bug 269372 Opened 20 years ago Closed 3 years ago

allow movemail accounts for multiple usernames and sort out the file paths

Categories

(MailNews Core :: Movemail, defect)

All
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: wolfiR, Assigned: aceman)

References

Details

Attachments

(1 file)

within the account manager there are active edit fields for server name and user name. The fields should be left out or at least inactive. I observed this with thunderbird but it seems to be a generic mailnews thing.
Product: Browser → Seamonkey
I have two "Movemail" accounts in /var/spool/mail. One is associated with my current account (the file has the same name than my username). The other belongs to another account, but I can read it (with cat) because of permissions. I tried to set up these movemail accounts within thunderbird, but I can't read any messages within the account not belonging to me. I get no errors, but no message neither. So, I still haven't found the meaning of these two fields : server name and user name because it seems they do not work correctly but disabling them as you suggest, won't allow people like me to to have two movemail accounts.
Assignee: sspitzer → mail
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.2pre) Gecko/2008071201 SeaMonkey/2.0a1pre movemail is currently disabled in SeaMonkey, but shouldn't be.
Assignee: mail → pkwarren
Component: MailNews: Account Manager → MailNews: Movemail
Depends on: movemail
Product: Mozilla Application Suite → Core
QA Contact: movemail
Movemail isn't disabled, the .rdf just seems to be not packaged, but I can confirm the bug here.
Product: Core → MailNews Core
The basic problem this bug is about is the LocateSpoolFile function in nsMovemailService.cpp: <http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsMovemailService.cpp#270> It does not care what stuff has been entered into the server/username fields, it always uses $MAIL/$USER/$USERNAME. We should either disable the am fields or use them.
Severity: minor → normal
Not very crowdy here :) Posted this in https://bugzilla.mozilla.org/show_bug.cgi?id=596575 , too. Maybe one of the bugs should be marked as duplicate. I had a few minutes and took a look into the source and wrote a really "quick and dirty" patch, nothing to release yet. But it should give an idea how this could be solved. After patching one can create multiple Movemail accounts. Movemail no longer uses the environment variables %USERNAME%, %USER% or %MAIL% to determine username or spool folder. When you enter your email address e.g. youremail@localhost in the account wizard I the username "administrator" is always written to the prefs.js user_pref("mail.server.server3.userName", "youremail"); Now this is used in combination with the mentioned examples for spooler folders const char * gDefaultSpoolPaths[] = { "/var/spool/mail/", "/usr/spool/mail/", "/var/mail/", "/usr/mail/" }; to determine the spool file. They are checked in combination with the username one after another, loop breaks on success. Setting the parameter aRequiresUsername to PR_TRUE makes is possible to add multiple Movemail accounts, as there is some sort of check made (see aw-server.js, function serverPageValidate(), parameter !gProtocolInfo.requiresUsername). This disables the "Next" button in the wizard. Well, have a look, give it a try and tell me what you think.
Mnyromyr, do you want to take a look at the patch?
Well I don't know, but Thanks :-)
Yes, I will. :)
Comment on attachment 483273 [details] [diff] [review] Add multiple Movemail accounts If you want this to go somewhere you'll need to set review flags.
Attachment #483273 - Flags: review?(neil)
Attachment #483273 - Flags: review?(neil) → review?(neil)
Ok, thanks. I just thought it might be to early to ask for review, because the patch is still rough. But few mins ago I read on the developer pages that it is ok to ask for review in early stages of a patch. Well, I think additionally to this patch we should fit the account wizard. In the past the server-setting localhost from movemail.rdf is used and can not be changed via GUI. This is fine so far, I think. But we should move away from that the username is taken from the users emailaddress without even mentioning that in the GUI. We could introduce one field that takes "spool file name without path", since multiple accounts are possible in the future. And we could think of moving away from const char * gDefaultSpoolPaths[] = { "/var/spool/mail/", "/usr/spool/mail/", "/var/mail/", "/usr/mail/" }; and let the user set the path via the GUI. Ideas welcome :)
But please no path input in the Wizard, this would go against the easy-to-use policy, most ordinary users don't know about such paths. Keep the above defaults in server settings and make it editable?
(In reply to comment #12) > Well, I think additionally to this patch we should > fit the account wizard. > > In the past the server-setting localhost from movemail.rdf is used > and can not be changed via GUI. This is fine so far, I think. In the long run, I want to move away from the hack that causes movemail.rdf to work (which is already possible, in theory at least). > and let the user set the path via the GUI. That is probably the best, and also has the added benefit of allowing us to write automated tests for movemail. (In reply to comment #13) > But please no path input in the Wizard, this would go against the easy-to-use > policy, most ordinary users don't know about such paths. I would say find the default path via that setup and let the user change it in the Wizard if they wish to. But I'm not a ui-r expert.
Assignee: pkwarren → homerun4711
Well, I suppose a user that tries to set up a Unix Movemail account can be considered above-usual-knowledge :) Question is, do we want to move away from the system environment variables. (for example, %MAIL is not available in ubuntu...) We could first read the mailbox-name via a textbox, then read the default paths and test using .isFile .Then we could provide a new window "Thunderbird found a mailbox with that name in /var/mail..., is the box you want to use?" Then radio buttons Yes: Use it, No: provide a field where one can input the complete path including the name of the spool file. Then again .isFile check. I have a question here: that movemail.rdf file is read from AccountWizzard.xul here, right??? <vbox datasources="rdf:ispdefaults" </vbox> How is it done, that this is only available in the Linux version of TB? Is the movemail.rdf file only included then? If we want to move away from the rdf-files, how is it assured, that Movemail is only available in the account wizard of Linux versions? Is there a parameter somewhere?
(In reply to comment #15) > Question is, do we want to move away from the system environment > variables. (for example, %MAIL is not available in ubuntu...) It could be good for finding the default mailbox. > We could first read the mailbox-name via a textbox, then > read the default paths and test using .isFile .Then we could > provide a new window "Thunderbird found a mailbox with that name in > /var/mail..., > is the box you want to use?" > Then radio buttons > Yes: Use it, > No: provide a field where one can input the complete path including > the name of the spool file. > Then again .isFile check. The perhaps easiest way of doing this is using new account type extension hooks in the account wizard, which isn't terribly documented, but it's what we have. The basic idea is documented here: <https://wiki.mozilla.org/MailNews:Creating_New_Account_Types#Step_2:_Account_Wizard_Overlays>. Essentially, it boils down to writing a new wizard page for movemail, so the page setup is "identitypage,movemailpage,accnamepage". > How is it done, that this is only available > in the Linux version of TB? > Is the movemail.rdf file only included then? movemail.rdf is only packaged (and the backend files themselves are only built) on Linux machines. > If we want to move away from the rdf-files, > how is it assured, that Movemail is only > available in the account wizard of Linux versions? > Is there a parameter somewhere? If you package the account wizard stuff as an overlay, you can conditionally export the overlay in the jar.mn files.
Assignee: homerun4711 → nobody
> > How is it done, that this is only available > > in the Linux version of TB? > > Is the movemail.rdf file only included then? > > movemail.rdf is only packaged (and the backend files themselves are only built) > on Linux machines. That's not quite true. Movemail is still part of SeaMonkey's Mac builds. OTOH, you could claim that OS X is just another Unix variant... ;-)
Comment on attachment 483273 [details] [diff] [review] Add multiple Movemail accounts Joshua, can you do a first run on reviewing this please.
Attachment #483273 - Flags: review?(neil) → review?(Pidgeot18)
Comment on attachment 483273 [details] [diff] [review] Add multiple Movemail accounts Review of attachment 483273 [details] [diff] [review]: ----------------------------------------------------------------- Apologies for the delay in reviewing this, but time has been a bit of precious commodity for me recently. First off, the code has several style violations (commented code, I think it makes a function into dead code, improper indentation). I haven't explored the difference in UX between the version with and without this patch, but from my recollections, it doesn't make it particularly clear what the initial value of the username is keyed off of, instead pulling it off of the email address. I may want my identity for reading root's email address to be my username@domain, but it does not appear to be possible to do this.
Attachment #483273 - Flags: review?(Pidgeot18) → review-
This looks interesting.
Assignee: nobody → acelists
Summary: server settings for movemail account → allow movemail accounts for multiple usernames and sort out the file paths
So my proposal would be: - Hide the host name field in the account manager. It is set to "localhost" and I am not sure we want it be changed to other value. It would probably be ignored. - In LocateSpoolFile, obey the value of username set, only fall back to the env variable if none set (but the username will be mandatory - it is got at account creation). - When the username is changed, run LocateSpoolFile again to find the file. - Expose the "spoolDir" value in the account manager as a read-only field for now so that the user can at least see where Tb tries to fetch the msgs from. (We could make it editable in the next iteration.) Would this pass?
Flags: needinfo?(Pidgeot18)
Hardware: x86 → All
Sounds okay. I would like to point out that any code that guesses paths from the environment variables should be run at account (re)config time, and you'll want to run this by somebody for ui-r when you actually make the patch.
Flags: needinfo?(Pidgeot18)
I am not sure this is a good idea. First, I have never seen in almost 25 years of Linux-based system use an email client providing movemail protocol without letting the user choose his spool files. This is a most basic feature. Second, a single spool file is not sufficient for many Linux users. Third, many Linux users choose other spool files than the classical /var/mail/username and similar spool files. See the man of procmail and of procmailrc to have a small idea of what we do with Linux. Fourth, putting spoolDir anywhere else than in the account manager is likely to lead to a far-from-easy-to-use scheme. For example, aceman's suggestion is complex. If I correctly follow his scheme, to choose another spool file, one must create a movemail account with his mandatory user name, then set an environment variable to choose his personal spool file(s), then go into TB account manager to erase his user name to trigger LocateSpoolFile to select the spool file(s) from the user's environment. This is not logical and not complying with an easy-to-use policy, specially for a piece of software where a good manual is still lacking. I have recently updated TB from version 17 to 24 and it cost me more than 20 hours to corner a bug just because I could not find out which spool file TB was processing. Check the bug report I filled a couple of days ago: https://bugzilla.mozilla.org/show_bug.cgi?id=931695 and check that discussion: http://forums.mozillazine.org/viewtopic.php?f=39&t=2762333&p=13146065#p13146065 to have an idea of the time lost just because spoolDir was unavailable. I think I would have cornered the bug in just an hour if that variable had been available. This was terribly frustrating. I have not seen a single argument in this thread explaining clearly why accessing spoolDir is such an anti-easy-to-use policy. My opinion, that might not be a good one, is that the spoolDir should be editable in the account manager. The field should accept a string or run LocateSpoolFile when the field is empty. At account creation, LocateSpoolFile could be executed after the user has entered his user name, then a spoolDir value could be suggested thanks to the LocateSpoolFile result, and the user could edit the default setting if he knows what he does. I do not think that it is a hard process for a Linux user. Today TB has become so limited that I am forced to choose another email client. This is very disappointing because TB shows so many qualities.
It just happened to me that I clicked an "send email" link from Firefox/Ubuntu, unknowing how it would be send. (with thunderbird as I now know). I couple of hours later a got shocked as I tried to read my Inbox (located locally at /var/spool/mail/user) with my usual email client (alpine) and found that all the mail had disappeared. Luckyly I remembered what I've done before that day and had the idea that it might have been the another mail client. But anyhow I took me quiet some time to figure out that my mails have disappeared into ~.thunderbird/6v0r4ew6.default/Mail/localhost/Inbox. A less expert or more unwary user might have lost his mails FOREVER. I don't know if Ubuntu or Thunderbird is to blame, but this is certainly a very serious bug.

Support for Movemail has been removed as of version 87 per Bug 1625741

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: