Re: merged messages mystery (new, improved! with null-padded email sample)
On Thu, Apr 05, 2001 at 01:10:22PM +0200, Louis-David Mitterrand wrote:
>
> On Thu, Apr 05, 2001 at 12:22:35PM +0200, Wichert Akkerman wrote:
> > Previously Louis-David Mitterrand wrote:
> > > Some users of our network (a Debian unstable mail server with postfix,
> > > procmail, uw-imap, uw-ipop3d and Oulook Express clients) report
> > > instances of merged e-mail messages: two separate messages become one
> > > with merged headers and loss of one of the messages' body.
> >
> > I'm quite certain it is a bug in how procmail deals with mboxes.
> > I used to suffer from this on a regular basis until I switched all
> > my mail over to maildirs.
>
> It's a possibility but I am leaning in another direction right now:
>
> I suspect a problem with /var/spool/mail 's permissions. In
> /usr/share/doc/uw-imapd-ssl/bugs.txt.gz one can read:
>
> . /tmp, /usr/tmp or /var/tmp (if present), and the mail spool directory
> must be protected 1777 (world write with sticky bit); otherwise
> mailbox locking and updates won't work.
>
> But on Debian systems /var/spool/mail 's mode is drwxrwsr-x if you
> decline to have world-writable directories when installing (for
> instance) postfix.
>
> So this might warrant a major warning message either in postfix or
> uw-imap or both when installing.
>
> ---
>
> Flame me if you want, I probably deserve it. After spending ^@^@^@^@^@^@^@^@^Received: from mail.rpi.edu ([128.113.100.7] ident=root)
Received: from mail.rpi.edu ([128.113.100.7] ident=root)
by incandescent with esmtp (Exim 3.16 #1 (Debian))
id 13ksRk-0004Hu-00
for <dilinger@incandescent.mp3revolution.net>; Sun, 15 Oct 2000 14:23:44 -0400
This was delivered directly to dilinger@incandescent.mp3revolution.net's
/var/spool/mail/dilinger, where they were merged upon either procmail
delivering them, or exim delivering them via it's appendfile transport (I'm
not sure whether or not I was using procmail at that point; I was using
exim's filtering language previously. I do remember it being a problem; exim
does not call procmail when using appendfile, so this problem happens whether
it's exim or procmail delivering).
I took a quick peek at both procmail's and exim's sources; both are using
fcntl() to lock the mailbox file. I'm not sure what your imapd uses, but
I'd imagine it required a lockfile if it needed write permission.
[dilinger@incandescent src]$ su -c "./exim_lock -fcntl /var/spool/mail/test" test
Password:
exim_lock: fcntl() lock successfully applied
exim_lock: locking /var/spool/mail/test succeeded: running /bin/bash ...
test@incandescent:/home/dilinger/exim-3.22/src$ ./exim_lock -fcntl /var/spool/mail/test
exim_lock: fcntl() failed: Resource temporarily unavailable
exim_lock: file closed
... waiting
exim_lock: fcntl() failed: Resource temporarily unavailable
exim_lock: file closed
... waiting
exim_lock: fcntl() failed: Resource temporarily unavailable
exim_lock: file closed
... waiting
test@incandescent:/home/dilinger/exim-3.22/src$ ls -la /var/spool/mail/
total 6
drwsrwsr-x 3 root mail 96 Apr 5 08:19 .
As you can see, exim and procmail (assuming they're using fcntl) should
not have any problems w/ /var/spool/mail's permissions. Exim, in
particular, would surely complain if it were unable to lock the mailbox
file.
> > The nul-characters are weird though, I never had those, and suggest
> > a kernel problem.
>
> I have included one of these (finally found it!) as an attachement.
> Really strange.
>
> --
> If I want your opinion I'll give you one.
--
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, rriggs@tesser.com
Reply to: