issues with conversion from UW Imap

[John A. Tamplin]

I finally settled on hacking up perdition to do what I wanted (treating 
a destination mail server starting with ! as a message to give when 
failing login) and writing my own delivery program (looks up the same 
database, returning tempory failure if it start with !, otherwise 
connecting to the LMTP server on the destination), and that part is 
working fine.

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):

if(fetchargs.fetchitems & FETCH_SETSEEN) {
	index_check(imapd_mailbox,1,1);
}
    

    and this at the end of cmd_partial (replacing imapd.c:3068):

index_check(imapd_mailbox,0,(fetchedsomething && (fetchargs.fetchitems & FETCH_SETSEEN)));
    

    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.

    * 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?

Thanks for any help or insight you can provide.

-- 
John A. Tamplin
Unix Systems Administrator

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.andrew.cmu.edu/mailman/private/info-cyrus/attachments/20021221/b64fcb6a/attachment.html