I'm using qmail as MTA with mailboxes in home directories as `Mailbox'. I've removed the whole /var/spool/mail directory. In my .procmailrc I haven't got any line containing /var/spool/... or so. But I got this message in my syslog after every mail : Oct 4 12:56:26 oxygene qmail: 939034587.003341 delivery 2944: success: procmail:_Couldn't_create_"/var/spool/mail/lgb"/did_0+0+1/ This is not problem since procmail seems to work but it's very annoying. What can be the problem ? Thanx : Gabor Lenart
I think the problem is that you removed /var/spool/mail...
This is from procmail(1)
FILES
/var/spool/mail/$LOGNAME
system mailbox; both the system
mailbox and the immediate directory
it is in will be created everytime
procmail starts and either one is
not present
Do you still consider this as a bug?
In article <cistron.Pine.LNX.3.96.991005172418.5749A-100000@cantor.unex.es>, Santiago Vila <sanvila@unex.es> wrote: Well, I didn't submit the bugreport but I consider it a bug. Especially since /var/spool/mail/$LOGNAME is a maildir-style mailbox around here. I talked this over with the current upstream maintainer and even sent him a bunch of patches that generalised several parts of procmail, and in the process fixed this as well, but for reasons beyond me he didn't think it was a bug and no patches got applied. So even if you do think it's a bug, good luck getting it fixed .. Mike.
IMHO, the issue here is whether or not we should support Maildir-style mailbox folders in /var/spool/mail/ or not, and whether or not we should support the removal of /var/spool/mail. If this may be done in procmail without "breaking" current policy, I would be willing to do it. Thanks.
Hello. I received this from the Debian Bug System. [ Please keep the Cc: lines when replying ]. Maybe there should be a way to disable ordinary /var/spool/mail checking in cases like this one. Thanks. Package: procmail Version: 3.13.1-2 Severity: normal I'm using qmail as MTA with mailboxes in home directories as `Mailbox'. I've removed the whole /var/spool/mail directory. In my .procmailrc I haven't got any line containing /var/spool/... or so. But I got this message in my syslog after every mail : Oct 4 12:56:26 oxygene qmail: 939034587.003341 delivery 2944: success: procmail:_Couldn't_create_"/var/spool/mail/lgb"/did_0+0+1/ This is not problem since procmail seems to work but it's very annoying. What can be the problem ? Thanx : Gabor Lenart
Santiago Vila <sanvila@unex.es> writes: They should rebuild procmail with MAILSPOOLHOME set to "/Mailbox" in src/authenticate.c. That way procmail can verify and possibly correct the permissions on the mail file for the user, and then if and only if they are okay will ORGMAIL and DEFAULT be set to point to the file. Note that if the the default mailbox should be anything but a normal mbox-style file then this won't work right. (This will be fixed in 3.14, along with maildir support.) il:_Couldn't_create_"/var/spool/mail/lgb"/did_0+0+1/ Philip Guenther
I am having a similar problem. I am sporatically receiving mail in /var/spool/mail/*, but my .procmailrc has a catch all rule to put mail in $HOME/mail/general. It also seems like mail is sometimes put in the wrong folder. I noticed this happening after I upgraded on Monday. .procmailrc: MAILDIR=$HOME/mail ...rules... # Catch all :0 general
Did your /home run out of disk space?
I too had mail delivered to /var/spool/mail when /home was full. I
think this is very wrong, as the mail might as well be lost. It took
several months until for no real reason I poked around in
/var/spool/mail, and found some 100 messages.
I since wrote a shell script that I run from cron that looks like this:
nveber@pyre[3146:~/bin]$ cat procmailcheck
#!/bin/sh
if [ -s /var/spool/mail/nveber ] ; then
echo "Procmail fucked up again!"
ls -al /var/spool/mail/nveber
fi
This way I eventually get an email (unless its misdelivered) about the other
lost emails..
This is a slightly different bug than the original. In this case the
DEFAULT variable is not being honored. It should fail if it cant
deliver the message where its supposed to, and let the MTA queue it,
instead of saving it in random locations..
Thanks,
Norbert
fwiw, my /etc/procmailrc has: ORGMAIL=$HOME/Mailbox DEFAULT=$HOME/Mailbox and i consider it a bug that procmail insists on querying and creating /var/mail/$USER even though i've told it otherwise. i've studied the source code and it's pretty clear that /etc/procmailrc parsing occurs later than this unnecessary futzing with /var/mail/$USER. sure i can recompile from source, but that's kind of an unfortunate thing to do.
Hi,
Was this bug fixed ? It looks not (debian etch/lenny).
It's problem, because we use Maildir (postfix+procmail delivery and users
are in ldap) and if for example user doesn't have Maildir directory (he
delete it), or ldap get slow response for $HOME variable etc. mail is stored
in /var/spool/mail/$LOGNAME and is never moved in Maildir.
Thnx for information.
Peter Ivancik
Am 2008-09-18 15:52:42, schrieb Peter Ivancik: This is NOT a Bug! If you have setup procmail correctly, it will use Maildirs. However, /var/mail/$LOGNAME is created as BACKUP IF delivery to $MAILDIR fails. ...and why not create a simple check for it?----8<----------------------------------------------------- MAILDIR=${HOME}/Maildir DEFAULT=${MAILDIR}/ DUMMY_EXEC=`if [ ! -d ${MAILDIR}/tmp ] || [ ! -d ${MAILDIR}/new ] || [ ! -d ${MAILDIR}/cur ] ; then mkdir -p ${MAILDIR}/{tmp,new,cur} ; fi` ... ----8<----------------------------------------------------- Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant
Dear Customer, We can not deliver your parcel arrived at January 26. Please check delivery label attached! Thank you for making business with us, Virgil Floyd, USPS Support Clerk.
Su Microsoft 365 necesita una actualización de servicio hoy para mantener un buen servicio de correo electrónico. Para activar esta actualización, haga clic en VER/014327<https://www.surveyrock.com/ts/DB9QNM> para continuar. Servicio de mesa