Hi!

On Wed, 2009-07-22 at 16:49 +0200, Simon Matter wrote:
[...]
> > I'm in the process of upgrading cyrus-imapd-2.2.13 (from
> > Debian-3.1/Sarge) to cyrus-imapd-2.3.7 (from RHEL-5/CentOS-5) on a
> > system with approx. 25k mailboxes.
> >
> > We are using quite simple sieve scripts for vacation and 2.3.7
> > duplicates (into the local inbox) all emails which trigger an outgoing
> > vacation mail.
> 
> I'm not sure I completely understand your situation and what your problem is.
I can give more details:

If I have the following sieve script, everything works fine and each
(non-Spam-)mail appears once in the INBOX (since we have the "keep"
there)
----  snip  ----
require [ "fileinto", "vacation" ];
if header :contains [ "X-Spam-Flag" ] [ "YES" ] {
fileinto "INBOX/Spam"; 
} else {
keep;
}
----  snip  ----
If I add a "vacation" statement (with a known working local email
address) as in
----  snip  ----
require [ "fileinto", "vacation" ];
vacation :days 7 :addresses [ "user@example.com" ] "Bin im Urlaub ..."; 
if header :contains [ "X-Spam-Flag" ] [ "YES" ] {
fileinto "INBOX/Spam"; 
} else {
keep;
}
----  snip  ----
each (non-spam-)mail, which triggers a vacation response, is stored 2
times in the INBOX (and not just once - from the "keep").

I have now more details. The vacation response is sent via sendmail but
the sendmail process terminates with an exit code 65 which is -
according to the sources - "data format error". The vacation response
mails always arrived BTW.
I don't know yet if it's related to that problem or not.

> However, you should note that the RHEL-5 system might have delayed expunge
> enabled which at least means that a mail delivered to an inbox and then
> deleted from there will still be visible on the filesystem. Do you really
> see the mail via IMAP or only on the filesystem?

I see them via IMAP (and I didn't actually check the filesystem as I saw
no reason).


> > Glancing over the source diff'ing the old and new imap/lmtp_sieve.c file
> > (and diff'ing to 2.3.14) doesn't reveal anything remotely strange (to my
> > eyes - I'm not experienced with cyrus-imapd's source code. So I may well
> > looked into the wrong file.).
> >
> > Googling and searching in the bug/issue trackers from above also doesn't
> > give any useful hint - and I didn't even found someone else having that
> > problem.
> >
> > FWIW, we have "duplicatesuppression: false" in /etc/imapd.conf - as it
> > saved a lot of I/O load on the old systems (avoiding storing and
> > checking the for duplicates in the DB).
> >
> > Does anyone have any idea what could be wrong or what could/should be
> > debugged/analyzed/....?

TIAaA,
 	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services