From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Galeon/1.3.20 Description of problem: After spending quite a while trying to make my mail on my workstation easily visible from my laptop, I suggest considering switching the default mail box for new accounts to be a maildir in, say, ~/Mail. I've used /var/spool/mail/<username> for years, and I've now become pretty much convinced that having procmail deliver mail to ~/Mail is a better idea. (At least for roughly personal workstations.) The advantages (as I see them) are that: - All mail-user-agents see the same mail. Mutt, evolution, etc. would store data in the same place. (Evolution's current upstream default behavior, storing precious email in a _dot_ directory, is appalling.) - The default dovecot settings (via the MAIL environment variable, I guess) can point to the same maildir, so that users with both a laptop and a desktop can very simply have the MUA on the laptop execute something like "ssh userid /usr/libexec/dovecot/imap" and have easy, secure access to their mail. - Email backups become subsumed in backing up ~. (Currently users must remember to also back up /var/spool/mail. I have seen _many_ users forget this.) - Also, and related to the previous point, a common partition scheme for Fedora is / /home /usr/local (maybe), and swap With this scheme a Fedora reinstall w/o backing up /var/spool/mail is catastrophic. But, many new users either don't know where their mail is actually stored, or just forget to back up that directory when backing up the rest of their system, and lose there mail. I couldn't figure out a good place to put this RFE, so I put it under Dovecot rather than procmail or one of the MUAs. Please tell me if there is a better home for the bug. I'm not sure if I'm missing a critical reason to keep mail in /var... it's been the norm for a long time, but I've found that (with my personal computers anyway) keeping mail in an easily accessible location is a real boon. Thanks for thinking about this! John Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Additional info:
Thank you for your thoughtful and well reasoned input. I agree 100% with you. However, as you correctly point out this is not a dovecot specific issue. In fact its really a multiple package configuration issue. In particular the LDA has to be configured to deliver (and properly lock) the same location that an IMAP server such as dovecot can read and manipulate. The change to the dovecot default configuration is simple, thats not the issue. The problem is we ship many packages (several MTA's, several POP/IMAP servers, Squirrelmail, procmail, fetchmail, etc.) and we don't know which ones will be combined in the field to comprise an integrated mail solution. Each requires multiple configuration "edits" to bring themselves in alignment with each other. Making a config change to dovecot does not address nor solve this problem. I have long been an advocate of Red Hat producing an email configuration tool that will let the user pick a configuration and mananage each packages configuration (because it has intelligence about the configuration interrelationships). This is the right solution and there is some buy-in this needs to be done. While I agree with you I'm afraid I'm going to close this a won't fix because at the moment I can only update dovecot's configuration file and that is not enough to adequlately address the multiple configuration issues. Hopefully in the not too distant future we'll have an integrated mail configuration utility that handles all the pieces of the puzzle in unison.
Yeah, I understand how much is involved with doing this the "right" way. I couldn't figure out where to put the RFE, though, so I put it here. :) Is there a better place to put this comment/request? I can't figure out how to put a report into bugzilla that is relevant to a wide set of packages. I'm glad other people are thinking about the same issues. It took me some time to get things working for myself, and I thought it would be a shame if I didn't document the resulting ideas somewhere. :) John
There is a formal procedure for requesting features/enhancements, its called "Feature Tracker". However, to get an item into Feature Tracker you must be a paying customer with access to a TAM (Technical Account Mananger). Since you filed this against Fedora and not the Enterprise product I'm making the assumption you don't have to TAM with whom to file this request with :-( But don't dispair, there is an awareness of the need to do what you're asking and internal advocates for it. I don't think it will be forgotten, it might take longer than hoped, but it won't be lost. I do really appreciate your thoughtful input and even if bugzilla is not the right forum for such requests the presence of such bug reports helps lend credibility to the arugument we need to do this.