Tim Alberts wrote:
On Thursday 22 April 2004 16:57, you wrote:
Tim Alberts wrote:
I've learned that if I set the /var/spool/mail folder permission to 777,
I no longer get the following error.
Mailbox Vulnerable - Directory /var/spool/mail must have 1777 protection
It seems odd that something requires worldwriteable access to the
/var/spool/mail folder.
However, the main problem persists that if I use kmail to retrieve email
from the pop3 server, the /var/spool/mail/user email file gets written
with the
message:
From MAILER-DAEMON Thu Apr 22 11:50:17 2004
Date: 22 Apr 2004 11:50:17 -0700
From: Mail System Internal Data <MAILER-DAEMON@xxxxxxxxxxxxxxxxxxxxx>
Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
Message-ID: <1082659817@xxxxxxxxxxxxxxxxxxxxx>
X-IMAP: 1082659816 0000000002
Status: RO
This text is part of the internal format of your mail folder, and is not
a real message. It is created automatically by the mail system software.
If deleted, important folder data will be lost, and it will be re-created
with the data reset to initial values.
A few people have hinted that imapd writes this to a mail file to keep
track of which emails have been read. How can this be happening if I
have the imapd disabled?
As I said in an earlier posting, ipop3d is based on Crispin's c-client
code. So is imapd, so even though you have imapd disabled, the ipop3d
may be inserting that message because it's done in the c-client bit.
I just looked at the source code for imapd and ipop3d (for the
terminally curious, specifically the imap-2000e version) and they both
use the c-client "unix" driver for mailboxes. That driver inserts the
message, so now even the POP daemon inserts the IMAP housekeeping
message. Lovely.
It looks like you are correct. However, I've been running a RedHat7.3 server
for a couple years now with imap version 2001a-10 and never had the user mail
files get imap access messages written to them. The newer fedora1 runs imap
version 2002d-3 and it seems to behave this way. I guess this is not the
source of my problem after all.
What I am currently facing is I keep getting error messages telling me to set
/var/spool/mail folder to 777 access rather than the default 775. When I set
it to 777, I no longer get the message telling me to change it however I feel
I would be a fool to leave a world accessible mail spool open.
I am left with 2 questions:
1. Why is imapd/ipop3d telling me to set access to 777 on /var/spool/mail?
To quote the BUILD file from imap-2000e:
----------------------------------------------------------------------
STEP 4: notes on privileges
Neither user "root", not any other UID 0 account, can log in via
IMAP or POP. "That's not a bug, it's a feature!"
This software is designed to run without privileges. The mail
spool directory must be protected 1777; that is, with world write and
the sticky bit. Of course, mail *files* should be protected 600!
An alternative to having the mail spool directory protected 1777,
at the cost of some performance, is to use the external "mlock" program,
available as part of the imap-utils package. With mlock installed as
/etc/mlock and setgid mail, the spool directory can be protected 775
with group mail. Please disregard this paragraph if you don't understand
it COMPLETELY, and know EXACTLY what to do without question.
----------------------------------------------------------------------
Since the program is intended to run completely unprivileged, the spool
directory must be set world-writable. If you want to lock it down, you
must run the mlock program and set ipop3d and imapd as setgid mail.
2. Why is email randomly dissappearing?
I am now looking at the second problem as possibly being a problem resulting
from either my procmail recipe or I have installed ClamAV and am using
TrashScan via procmail to scan for viruses.
That's the most likely candidate. You could add:
VERBOSE=yes
LOGFILE=/var/log/procmail.log
to the top of your procmailrc and "tail -f /var/log/procmail.log" to
watch it do its thing. Maybe that'll give you a hint.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx -
- VitalStream, Inc. http://www.vitalstream.com -
- -
- The light at the end of the tunnel is really an oncoming train. -
----------------------------------------------------------------------
