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

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..