Rick Stevens 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. ---------------------------------------------------------------------- - Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx - - VitalStream, Inc. http://www.vitalstream.com - - - - He who laughs last thinks slowest. - ----------------------------------------------------------------------
Now I am really puzzled!
Everyone on this thread seems upset by a behavior that I know has existed in mail on Linux for at least the last 7 years.
Is it because you just found out about it? or is there really a problem with this behavior? Email clients do not even see that dummy message. Only when looking at the box contents with a text browser such as cat/less/etc or an editor such as vi/vim/emacs/etc do you even see it.
As I said earlier, it seems to be put there by the daemon serving the mail, and I have seen it ranging from pine to mutt to other clients such as fetchmail and mozilla. I believe it is being put there by the host, and not sendmail or the client. I think this is more of a scare than a problem as it is a housekeeping thing. Alexander has recently shown that.
