Re: [Dovecot] Order of istream and ostream chains

2014-02-12 Thread Philipp Brüll

On 11/02/14 21:32, Timo Sirainen wrote:

On 12.2.2014, at 2.27, Philipp Brüll  wrote:


I'm creating a scrambler plugin, that adds an istream and an ostream to the 
stream-chain for the mail input/output. It works well until the zlib plugin is 
added to the configuration. The scrambler should run before the zlib and 
encrypt the mail before it's compressed. Since, the plugin is named 
lib18_scrambler_... (and the other lib20_zlib), that works well when a mail 
is received.

When a mail is read via IMAP, the plugins should handle the mail in the reverse 
order. So first, the zlib should decompress it and afterwards the scrambler 
should decrypt it.

But it seems, that they work the other way around. The scrambler istream gets 
compressed data as input. It's hooked in the chain of istream as the 
following...


In your previous mail you mentioned you're using v2.1.17. Have you tried with 
v2.2.10? I think this is already fixed (at least I've successfully used zlib + 
mail encryption plugin).



I just tried version 2.2.11, but the problem seems still to exists.

As soon as the zlib is activated, the scrambler receives 0x1f, 0x8b, 
0x08, ... which is exactly the gz header. The mail doesn't seem to get 
decompressed before it's passed to the scrambler. I assume that the 
order of istreams is messed up.


I've checked already the istreams of the mail_filter and zlib plugins, 
but can't find any differences to my implementation. Do you know any 
other example code, where I can see how ostreams/istreams are chained in 
the correct order?


Best regards,
Philipp



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [Dovecot] Order of istream and ostream chains

2014-02-11 Thread Philipp Brüll

On 11/02/14 21:32, Timo Sirainen wrote:

On 12.2.2014, at 2.27, Philipp Brüll  wrote:


I'm creating a scrambler plugin, that adds an istream and an ostream to the 
stream-chain for the mail input/output. It works well until the zlib plugin is 
added to the configuration. The scrambler should run before the zlib and 
encrypt the mail before it's compressed. Since, the plugin is named 
lib18_scrambler_... (and the other lib20_zlib), that works well when a mail 
is received.

When a mail is read via IMAP, the plugins should handle the mail in the reverse 
order. So first, the zlib should decompress it and afterwards the scrambler 
should decrypt it.

But it seems, that they work the other way around. The scrambler istream gets 
compressed data as input. It's hooked in the chain of istream as the 
following...


In your previous mail you mentioned you're using v2.1.17. Have you tried with 
v2.2.10? I think this is already fixed (at least I've successfully used zlib + 
mail encryption plugin).



Thanks for the fast reply. Yes, I'm using v2.1.17. If this is a bug in 
2.1, is there a workaround existing?


I'm already pushing the admin to upgrade to 2.2, but I don't know is 
this is happening soon ;-)


Kind regards,
Philipp



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [Dovecot] Order of istream and ostream chains

2014-02-11 Thread Timo Sirainen
On 12.2.2014, at 2.27, Philipp Brüll  wrote:

> I'm creating a scrambler plugin, that adds an istream and an ostream to the 
> stream-chain for the mail input/output. It works well until the zlib plugin 
> is added to the configuration. The scrambler should run before the zlib and 
> encrypt the mail before it's compressed. Since, the plugin is named 
> lib18_scrambler_... (and the other lib20_zlib), that works well when a 
> mail is received.
> 
> When a mail is read via IMAP, the plugins should handle the mail in the 
> reverse order. So first, the zlib should decompress it and afterwards the 
> scrambler should decrypt it.
> 
> But it seems, that they work the other way around. The scrambler istream gets 
> compressed data as input. It's hooked in the chain of istream as the 
> following...

In your previous mail you mentioned you're using v2.1.17. Have you tried with 
v2.2.10? I think this is already fixed (at least I've successfully used zlib + 
mail encryption plugin).