I am running Cyrus 2.1.11 on Solaris 9, using skiplist for mailboxes and seen, db3_nosync for TLS and duplicates, and flat for subscriptions.
I have about a third of the users converted, and there have been a number of issues with the conversion:
- A number of Outlook Express users have seen the same Seen-state lossage that was mentioned here earlier. Specifically, OE 6.0 seems to open multiple connections for a given folder and the second connection sees the message that was picked up by the first connection as unseen again. I have not had any reports of it on other clients, including Mozilla 1.x, Netscape 4.7x, Horde/IMP, or Eudora. I can't think of why OE would open this extra connection and then ignore it, but regardless this is an issue that is a problem since the majority of our users use OE and this problem did not appear on UW Imap. It looks like the seen flags are kept in memory and only written to disk when index_check is called with checkseen true -- how much of a performance hit would be taken to just add code like this at the end of cmd_fetch (after imapd.c:2960):
and this at the end of cmd_partial (replacing imapd.c:3068):if(fetchargs.fetchitems & FETCH_SETSEEN) { index_check(imapd_mailbox,1,1); }
It seems like that would solve the problem at the cost of performance, or am I missing something else here? If this will solve the problem, perhaps we could make a configuration directive and make it conditional on that directive so other people seeing this problem can choose to trade performance for correctness with OE.index_check(imapd_mailbox,0,(fetchedsomething && (fetchargs.fetchitems & FETCH_SETSEEN)));
- One OE 6.0 user reported seeing really strange behavior where occasionally messages would show as deleted in OE (never having been read), and when she tried to view the message it gave an error saying the message no longer existed. Other mail clients accessing the same mailbox while this was happening saw the messages with no difficulties, and deleting the account and recreating it in OE made them visible again. I have created a protocol log directory to try and catch what was going on, but of course it hasn't happened again since then. Has anyone else seen this behavior?
- lmtpd seems overly restrictive about envelope from addresses. Specifically, it rejects addresses of the form "xxxx"@reply.yahoo.com, since in parseaddr (lmtpengine.c:502) it strips away quoted strings at the beginning. This doesn't seem to be correct, since according to RFC2821 (the LMTP RFC says that anything not overridden is the same as ESMTP) a quoted string is a valid local-part of the return-path. Is there anything that would break by allowing quotes in the return-path? It looks like quotes could get there already by \", so I am assuming the rest of the code can handle it fine. Currently, I have my delivery program strip the quotes and backslash-quote any special characters inside the quoted string, but I am not positive that address would be treated the same by the destination host.
- I set my delivery program to treat any failure as a temporary failure so that I wouldn't lose any mail if I had a bug in it. I noticed tons of messages buildng up that were being rejected because they had null characters in them. Some of these were spam, but many were also messages from places like Yahoo groups mailings. For now, I fixed it by just stripping null characters in my delivery program, but eventually I want to be able to use the standard deliver. Do other people just let these messages bounce, or do you not see similar messages? Would it be acceptable to add an option to deliver to also strip nulls in deliver.c/push and lmtpengine.c/pushmsg?
-- John A. Tamplin Unix Systems Administrator
