When using the zlib plugin with maildir and copying with hardlinks, if a compressed message is copied, the 'Z' suffix on the file isn't copied, so the new message isn't uncompressed when it's fetched. I wasn't smart enough to figure out a clean way to carry a file suffix through a copy, so I changed how the zlib-plugin detects if a message is compressed. This patch peeks at the first two bytes of the message looking for the zlib header. -- Richard Platel Tucows -------------- next part -------------- A non-text attachment was scrubbed... Name: zlib-plugin.c.patch Type: application/octet-stream Size: 1531 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20080403/f0c57b8d/attachment-0002.obj>
Hi> I wasn't smart enough to figure out a clean way to carry a file suffix > through a copy, so I changed how the zlib-plugin detects if a message > is compressed. This patch peeks at the first two bytes of the message > looking for the zlib header.This is actually an even more robust solution anyway. Good fix Ed
There was a bug in this patch, causing a seg fault with 0 or 1 byte messages (which shouldn't really happen, but, hey). Patched patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: zlib-plugin.c.patch Type: application/octet-stream Size: 1562 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20080430/dd28d696/attachment-0002.obj> -------------- next part -------------- On Apr 3, 2008, at 3:04 PM, Richard Platel wrote:> When using the zlib plugin with maildir and copying with hardlinks, > if a compressed message is copied, the 'Z' suffix on the file isn't > copied, so the new message isn't uncompressed when it's fetched. > > I wasn't smart enough to figure out a clean way to carry a file > suffix through a copy, so I changed how the zlib-plugin detects if > a message is compressed. This patch peeks at the first two bytes > of the message looking for the zlib header. > > -- > Richard Platel > Tucows<zlib-plugin.c.patch>
On Thu, 2008-04-03 at 15:04 -0400, Richard Platel wrote:> When using the zlib plugin with maildir and copying with hardlinks, > if a compressed message is copied, the 'Z' suffix on the file isn't > copied, so the new message isn't uncompressed when it's fetched. > > I wasn't smart enough to figure out a clean way to carry a file > suffix through a copy, so I changed how the zlib-plugin detects if a > message is compressed. This patch peeks at the first two bytes of > the message looking for the zlib header.I originally also thought about this kind of a detection, but then started wondering if it would cause problems if the check returned zlib-positive but the data actually isn't valid zlib data. But I guess this isn't a real problem, especially since MTAs usually add some headers at the beginning of the mails so this can't be triggered on purpose by sending special mails. Although it's still possible to do it with APPEND command, but hopefully zlib has no more security holes in it. Well, except you could probably DoS yourself (and maybe other users via shared mailboxes) by generating zlib input which expands into a huge mail. Hmm. I think I'd prefer to keep using Z flag, but it would need some maildir code changes so that zlib plugin can add the flag.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20080504/ba7a7a58/attachment-0002.bin>