Problem with Fedora1 and ipop3d

Rick Stevens rstevens at vitalstream.com
Fri Apr 23 00:33:30 UTC 2004


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 at localhost.localdomain>
>>>Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
>>>Message-ID: <1082659817 at localhost.localdomain>
>>>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 at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-   The light at the end of the tunnel is really an oncoming train.  -
----------------------------------------------------------------------





More information about the fedora-list mailing list