Hi! Some more info: Apparently, the basic bug really appears to be in IMP. The reason I didn't see anything wrong happening with an older version of Cyrus (2.4.12) was that I didn't look closely enough. See, the broken message actually /does/ get saved into the Sent folder (even though Cyrus gives an error about NUL bytes), but /it doesn't end up in cyrus.index/, so replication ignores it completely, doesn't even try to replicate it, and so doesn't get stuck in the size mismatch error. (And you can't see it in the message index with your client.) However, when I reconstruct the Sent folder, the message appears in the index and replication gets stuck, just as with Cyrus 2.4.17. However, when I tried this with a 2.4.17 frontend and either of the backends (2.4.12 and 2.4.17), the message didn't even get saved in the Sent folder. So maybe the problem is with the 2.4.16 frontend? (The configs in the 2.4.16 frontend and 2.4.17 frontend are identical.) I'll have to look further into this. --Janne On Fri, Mar 15, 2013 at 04:15:04PM +0200, Janne Peltonen wrote: > Hi! > > I've run into a weird problem. Apparently, sometimes the web-based IMAP client > IMP fucks up the MIME headers of a part of a multipart message (will file an > IMP bug on that soon), so that if the content type of an attachment is > text/plain and encoding is utf-16 (little endian), the header ends up being > partially encoded as utf-16 (little endian). But the header of the MIME part > shouldn't contain NUL characters, so Cyrus says "Message contains NUL > characters" and rejects the message when IMP tries to save it to the Sent > folder. > > Except not always. Since last week, when I upgraded one of my murder backend > servers from 2.4.12 to 2.4.17, sometimes the NUL bytes creep through. Like so: > > --clip-- > --=_pRVOz2N9C9oTNFcAA1MfBg1 > Content-Type: text/plain; charset=u^@t^@f^@-^@1^@6^@l^@e^@; > name=m^@a^@a^@l^@a^@m^@p^@o^@1^@b^@.^@t^@x^@t > Content-Disposition: attachment; filename=m^@a^@a^@l^@a^@m^@p^@o^@1^@b^@.^@t^@x^@t^@; > size=146736 > Content-Transfer-Encoding: q^@u^@o^@t^@e^@d^@-^@p^@r^@i^@n^@t^@a^@b^@l^@e > --clip-- > > (The ^@:s stand for NUL characters. Weird thing is, the > Content-Transfer-Encoding seems to be missing one NUL.) > > Would anyone have any idea what's going on: in what kind of circumstances would > Cyrus accept NUL characters in a MIME part header? > > All the frontends are at version 2.4.16, if that's any help. > > I've been trying to reproduce the problem, but haven't been able to find the > exact conditions :( The irritating thing is, when this happens (NUL bytes in > mime part headers or otherwise corrupted MIME parts), Cyrus ends up counting > the size of the message wrong and replication gets stuck... (sync_support that > makes the sanity checks that the message on disk is the same as the message > referred to in cyrus.index counts the message size using stat(), but apparently > the size that ends up in cyrus.index is counted somehow differently). > > > --Janne > -- > Janne Peltonen <janne.peltonen@xxxxxxxxxxx> PGP Key ID: 0x9CFAC88B > Please consider membership of the Hospitality Club (http://www.hospitalityclub.org) > ---- > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Janne Peltonen <janne.peltonen@xxxxxxxxxxx> PGP Key ID: 0x9CFAC88B Please consider membership of the Hospitality Club (http://www.hospitalityclub.org) ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
