issues with conversion from UW Imap

[John A. Tamplin]

Quoting Henrique de Moraes Holschuh <hmh at debian.org>:


> Is there a reason for not using a shared-memory interface for Cyrus to
> allow
> all imapds serving a mailbox to share flag state?  Maybe a long-living
> daemon akin to idled that stores the seen state, or using IPC and real
> shared memory maps.
> 
> It would impact performance, I'm sure, but it could be probably made a
> runtime
> or compile-time option...

That would certainly solve the problem, but it is a rather large modification. 
Since CMU representatives previously said they had no interest in changing the
caching behavior of seen-state, I was hoping for something less grand that would
solve the needs of those (apparently few) who need it. Since the hardware I am
running this on used to handle the load with UW Imap and unix format mailboxes,
the additional disk I/O for updating seen state after every fetch should be
acceptable for my environment.

When you start to talk about a separate daemon that manages disk access and
caching of a database, that sounds a lot like using a real database to store the
data.  If there is a lot of data, the overhead of another process (and perhaps a
query language) can be made up for by a shared cache and combining random I/O
into sequential I/O, but building your own database is a lot of work.

> >      course it hasn't happened again since then.  Has anyone else seen
> >      this behavior?
> 
> I did.  OE bug, AFAIK...

Was there any patch for it or any way around it besides deleting the account and
recreating it?  Any idea why it shows up with Cyrus but not UW Imap?

> Well, this is the second or third time I heard about this NULL issue. These
> messages are indeed broken, and Cyrus is right in not accepting them. OTOH,
> this does not mean we can't add an option for Cyrus to FIX them by trashing
> the NULL chars, and adding a X-Message-bad header or something like that...
> still, I am not sure how difficult is to add that code to Cyrus, it would
> have to get the APPEND and LMTP message inclusion paths...

Well, I think it goes back to the "be liberal in what you accept and
conservative in what you send" rule.  The users who have been happily receiving
these messages aren't going to appreciate a response of "Well, they don't follow
the standard, get Yahoo (etc) to fix their problem -- until then live without
those messages", so for me I need to accept them.  I have a solution that works
for now (stripping them in my delivery program), but it seems like this out to
be a standard option.

-- 
John A. Tamplin
Unix System Administrator