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 email@example.com /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
/usr/local (maybe), and
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!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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. :)
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.