[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 ([] ident=root)
 Received: from mail.rpi.edu ([] 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
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

> > 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: