I don't believe this is the case... We set it to "no" on our site because we see a lot of lock contention on the duplicate delivery database. The problem is that setting it to "no" doesn't help if you have SIEVE enabled in your server. From what I could tell in the source code, SIEVE makes very active use of the duplicate delivery database, for vacationing, forwarding, redirections, etc.
The end result is that we patched our server (both in 2.2.1 and in 2.2.8) to honor the "no" for even Sieve operations. This works, but the downside is that this will break vacation stuff, as it is needed to prevent the auto-response message going back to the same user every single time a message is received from that user. Fortunately, nobody is using vacation via SIEVE in our environment yet, so it works for now...
The long term solution is to determine what in SIEVE actually truly needs to deal with the duplicate delivery suppression and code based on that.
From what I can tell, the forwarding, rediction, etc deals with the DB only
for the purposes of determine duplicate messages. So, if it is set to "no", then it shouldn't check. With regard to vacation messages, SIEVE is doing something different here and just uses the DB as a convenient way of storing the last time it sent a particular user an auto-response message. I think that can be ignored and still use the DB, even when the setting is "no". Is there anything else in SIEVE that should ignore the option?
Anyways, that is my 2 cents.
Incidentally, if you disable sieve when compiling the server, the option works exactly as expected. Sieve is enabled by default.
Scott
--On Friday, November 19, 2004 11:14 AM +0100 Fredrik Jönsson <[EMAIL PROTECTED]> wrote:
Hi,
From the man-page imapd.conf(5)
duplicatesuppression: yes If enabled, lmtpd will suppress delivery of a message to a mailbox if a message with the same message-id (or resent-message-id) is recorded as having already been delivered to the mailbox. Records the mailbox and message-id/resent-message-id of all successful deliveries.
Setting it to no (and restarting the server I think) will allow duplicate delivery. It has worked for us previously, though we quickly turned it back on again.
Regards,
/Fredrik Jönsson
On Fri, 2004-11-19 at 08:08, Antoine Jacoutot wrote:On Thursday 18 November 2004 22:52, torgan wrote: > cyrus.conf > # this is only necessary if using duplicate delivery suppression, > # Sieve or NNTP > # delprune cmd="cyr_expire -E 3" at=0400 > > hope that would help
Well, thanks but not really. I already saw that but I don't see how it would allow me to receive 2 instances of the same message. It is strange, I never had this problem with any other imap server.
Antoine --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
--- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
-- +-----------------------------------------------------------------------+ Scott W. Adkins http://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +-----------------------------------------------------------------------+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
pgpdIqAzYVhb7.pgp
Description: PGP signature
