Your message dated Mon, 26 Sep 2011 12:53:17 +0200 (CEST)
with message-id <[email protected]>
and subject line Re: Bug#642982: procmail: Mail logged as stored in a maildir
folder, but never appeared
has caused the Debian Bug report #642982,
regarding procmail: Mail logged as stored in a maildir folder, but never
appeared
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
642982: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642982
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: procmail
Version: 3.22-19
Severity: critical
Justification: causes serious data loss
I use procmail to filter my mail and for some mail, the procmail log
says:
>From [email protected] Mon Sep 26 10:20:54 2011
Subject: Re: ...
Folder: Mail/Maildir/new/1317025254.11570_2.xvii 2429
However the mail never appeared in my mailbox (I was waiting for it).
When I looked at the file system, there was no such file.
The mail was stored due to the default rule. I have:
DEFAULT=Mail/Maildir/
The file system is ext3 (encrypted).
Of course, I can't exclude a file system bug or a bug in Mutt (which
I was using at the same time). Does procmail avoid any race condition
with MUA's by doing the right thing when dealing with maildir?
Note: I've received my mail on this machine since September 1, 2011.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages procmail depends on:
ii libc6 2.13-21
Versions of packages procmail recommends:
ii postfix [mail-transport-agent] 2.8.4-1
procmail suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On Mon, 26 Sep 2011, Vincent Lefevre wrote:
> Package: procmail
> Version: 3.22-19
> Severity: critical
> Justification: causes serious data loss
>
> I use procmail to filter my mail and for some mail, the procmail log
> says:
>
> >From [email protected] Mon Sep 26 10:20:54 2011
> Subject: Re: ...
> Folder: Mail/Maildir/new/1317025254.11570_2.xvii
> 2429
>
> However the mail never appeared in my mailbox (I was waiting for it).
> When I looked at the file system, there was no such file.
Of course there was no such file. If you were using mutt at the same
time, then mutt probably moved the file somewhere to Mail/Maildir/cur/*,
as that's how Maildir works.
Just because it's no longer where procmail put the email in the first
place does not mean that procmail deleted it or didn't deliver it.
> Of course, I can't exclude a file system bug or a bug in Mutt (which
> I was using at the same time). Does procmail avoid any race condition
> with MUA's by doing the right thing when dealing with maildir?
Yes, and by design. That's the very reason Maildir exist. procmail
puts new emails in "new". MUAs simply move the files to "cur".
I've just checked using a .procmailrc like this:
LOGFILE=procmail.log
DEFAULT=Mail/Maildir/
then I do this:
cd Mail
mutt -f Maildir
Then I send an email and as soon as I press down-arrow in mutt, it
appears in the folder.
If you lost email, I'm very sorry, but filing a critical bug against
procmail (or any other package) without a way to reproduce the bug
is pretty useless.
Please tell me if you have a way to reproduce it, and I will reopen.
Thanks.
--- End Message ---
