Re: [Dovecot] Empty messages in 1.0RC2
Renaud Allard wrote:
Message: 1 Date: Tue, 18 Jul 2006 10:03:28 +0200 From: Renaud Allard Subject: [Dovecot] Empty messages in 1.0RC2 To: dovecot@dovecot.org Message-ID: 44BC95D0.8020800@llorien.org Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am running 1.0RC2 (upgrade from a beta, so I haven't tested RC1 unfortunately). I sometimes get empty messages in my inbox folder. Mails are stored using Maildir. Here is an output of a ls -la ~/Maildir/cur
-rw------- 1 n users 0 Jul 18 09:31 _CFC+Y5IvEB.gandalf.llorien.org:2, -rw------- 1 n users 0 Jul 18 09:28 _bEG+A2IvEB.gandalf.llorien.org:2, -rw------- 1 n users 0 Jul 18 09:54 _ezF+eOJvEB.gandalf.llorien.org:2, -rw------- 1 n users 2246 Jul 18 08:10 msg.f23:2,RSa
There is one real message (the last one). All messages seems to have strange file names names, even the real one. Messages delivered by the MTA generally have a name like 1152736772.H956194P17632.mail.llorien.org:2,RS
There is nothing in the SMTP server logs that could suggest these empty mails are delivered with SMTP and only dovecot version has changed. So I guess this is dovecot related. My IMAP client is thunderbird on Linux, but I have also seen the problem with sylpheed on OpenBSD.
Any help or hint appreciated.
These filenames mey be related to procmail temporary files created during delivery:
Try an strace (or equivalent) like this:
$ strace procmail &1|grep O_EXCL open("/var/mu/apap/Maildir/_YgG.ZvMvEB.hyperion", O_WRONLY|O_CREAT|O_EXCL, 0444) = 6 ...
Are you using procmail? If yes, something may be breaking it.
Apostolis Papagiannakis
These filenames mey be related to procmail temporary files created during delivery:
Try an strace (or equivalent) like this:
$ strace procmail &1|grep O_EXCL open("/var/mu/apap/Maildir/_YgG.ZvMvEB.hyperion", O_WRONLY|O_CREAT|O_EXCL, 0444) = 6 ...
Are you using procmail? If yes, something may be breaking it.
Indeed, I am using procmail to sort mailing list posts into dedicated folders. No other user has reported me this kind of bug and I am the only one using a .procmailrc file. So this should indeed be the cause. I will investigate on this.
Thanks
These filenames mey be related to procmail temporary files created during delivery:
Try an strace (or equivalent) like this:
$ strace procmail &1|grep O_EXCL open("/var/mu/apap/Maildir/_YgG.ZvMvEB.hyperion", O_WRONLY|O_CREAT|O_EXCL, 0444) = 6 ...
Are you using procmail? If yes, something may be breaking it.
It seems the culprit may be procmail which breaks. But only when I am logged on my imap account. When I am logged on imap, a verbose procmail gives: $ procmail &1 procmail: Couldn't create "/var/mail/n" procmail: [5957] Tue Jul 18 16:04:16 2006 procmail: Assigning "LOCKFILE=/home/n/procmail.lock" procmail: Locking "/home/n/procmail.lock" procmail: No match on "^Return-path:.*exim-users-bounces.*" procmail: No match on "^Return-path:.*dovecot-bounces.*" procmail: Couldn't create or rename temp file "/home/n/Maildir/new/msg.eW3"
When not logged into my imap account, it all works well: $ procmail &1 procmail: Couldn't create "/var/mail/n" procmail: [3092] Tue Jul 18 16:06:03 2006 procmail: Assigning "LOCKFILE=/home/n/procmail.lock" procmail: Locking "/home/n/procmail.lock" procmail: No match on "^Return-path:.*exim-users-bounces.*" procmail: No match on "^Return-path:.*dovecot-bounces.*" procmail: Assigning "LASTFOLDER=/home/n/Maildir/new/msg.R33" procmail: Opening "/home/n/Maildir/new/msg.R33" procmail: Acquiring kernel-lock procmail: Notified comsat: "n@0:/home/n/Maildir/new/msg.R33" Folder: /home/n/Maildir/new/msg.R33 1 procmail: Unlocking "/home/n/procmail.lock"
Note that I used a static lock to test. But it seems that dovecot is doing something with the file /home/n/Maildir/new/msg.R33 very likely moving, deleting or renaming it as I cannot find it back afterwards.
On Tue, 2006-07-18 at 16:14 +0200, Renaud Allard wrote:
Note that I used a static lock to test. But it seems that dovecot is doing something with the file /home/n/Maildir/new/msg.R33 very likely moving, deleting or renaming it as I cannot find it back afterwards.
See procmail problems in http://wiki.dovecot.org/MailboxFormat/Maildir
Thanks, it works now, but it's a quite strange rule in my procmailrc
MAILDIR=$HOME/Maildir DEFAULT=$MAILDIR .... :0
- .* ./
If I don't put the 3 last lines, the message is delivered to ~/Maildir instead of ~/Maildir/new, so dovecot was obviously unable to find it.
Anyway, this solves my problem.
Timo Sirainen wrote:
On Tue, 2006-07-18 at 16:14 +0200, Renaud Allard wrote:
Note that I used a static lock to test. But it seems that dovecot is doing something with the file /home/n/Maildir/new/msg.R33 very likely moving, deleting or renaming it as I cannot find it back afterwards.
See procmail problems in http://wiki.dovecot.org/MailboxFormat/Maildir
Thanks, it works now, but it's a quite strange rule in my procmailrc
MAILDIR=$HOME/Maildir DEFAULT=$MAILDIR .... :0
- .* ./
If I don't put the 3 last lines, the message is delivered to ~/Maildir instead of ~/Maildir/new, so dovecot was obviously unable to find it.
Try adding a trailing slash to the DEFAULT variable and removing the rule. Without the trailing slash, procmail does not know the directory is a maildir.
DEFAULT=$MAILDIR/
-Scott
Thanks, that's the hint I missed. Much better without the useless 3 lines junk. :)
Scott Alter wrote:
Thanks, it works now, but it's a quite strange rule in my procmailrc
MAILDIR=$HOME/Maildir DEFAULT=$MAILDIR .... :0
- .* ./
If I don't put the 3 last lines, the message is delivered to ~/Maildir instead of ~/Maildir/new, so dovecot was obviously unable to find it.
Try adding a trailing slash to the DEFAULT variable and removing the rule. Without the trailing slash, procmail does not know the directory is a maildir.
DEFAULT=$MAILDIR/
-Scott
Renaud Allard wrote:
Thanks, it works now, but it's a quite strange rule in my procmailrc
MAILDIR=$HOME/Maildir DEFAULT=$MAILDIR .... :0
- .* ./
If I don't put the 3 last lines, the message is delivered to ~/Maildir instead of ~/Maildir/new, so dovecot was obviously unable to find it.
The reason is that the heuristic is to always refer to a Maildir with a trailing slash, as opposed to an mbox which has no trailing slash. Omit the first line and change that secondline to:
DEFAULT=$HOME/Maildir/
and delete the last three lines (the default delivery) and you should be good to go.
HTH
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
* On 18/07/06 21:45 +0200, Renaud Allard wrote:
| Thanks, it works now, but it's a quite strange rule in my procmailrc
|
| MAILDIR=$HOME/Maildir
| DEFAULT=$MAILDIR
| ....
| :0
| * .*
| ./
In my .procmailrc, I have the last rule:
:0:
$DEFAULT
But $DEFAULT is not defined anywhere in the file as a variable.
I believe it's a magic value for procmail.
-Wash
http://www.netmeister.org/news/learn2quote.html
DISCLAIMER: See http://www.wananchi.com/bms/terms.php
--
+======================================================================+
|\ _,,,---,,_ | Odhiambo Washington
Probably defined in /etc/procmailrc
--
Jeff Graves, MCSA
Image Source, Inc.
508.966.5200 x31
www.image-src.com
-----Original Message-----
From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On
Behalf Of Odhiambo WASHINGTON
Sent: Tuesday, July 18, 2006 3:57 PM
To: dovecot@dovecot.org
Subject: Re: [Dovecot] Empty messages in 1.0RC2
* On 18/07/06 21:45 +0200, Renaud Allard wrote:
| Thanks, it works now, but it's a quite strange rule in my procmailrc
|
| MAILDIR=$HOME/Maildir
| DEFAULT=$MAILDIR
| ....
| :0
| * .*
| ./
In my .procmailrc, I have the last rule:
:0:
$DEFAULT
But $DEFAULT is not defined anywhere in the file as a variable. I believe
it's a magic value for procmail.
-Wash
http://www.netmeister.org/news/learn2quote.html
DISCLAIMER: See http://www.wananchi.com/bms/terms.php
--
+======================================================================+
|\ _,,,---,,_ | Odhiambo Washington
participants (7)
-
Apostolos Papayanakis
-
Jeff Graves
-
John Peacock
-
Odhiambo WASHINGTON
-
Renaud Allard
-
Scott Alter
-
Timo Sirainen