search for: istream_open

...n 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... static int scrambler_istream_opened(struct mail *_mail, struct istream **stream) { struct mail_private *mail = (struct mail_private *)_mail; union mail_module_context *mmail = SCRAMBLER_MAIL_CONTEXT(mail); struct istream *input, *inputs[2]; input = *stream; *stream = scrambler_istream_create(input);...

...e parsed for user2 5. ???/mail_allocated/ then /mail_save_begin/ for user2 (at this stage, the email is encrypted with users2 params) 6. Dovecot tells to LMTP that mail for user2 is delivered 7. then, ??? we are still in user2 context ???, an other /mail_allocated/ is run, followed by a /istream_opened/ 8. mail user context is swithed to user3 --> /mail_user_created/ --> plugin's args parsed --> ??? /mail_allocated/ 9. and??? Dovecot tells to LMTP that mail for user3 is delivered So, it appears that Dovecot is re-using user2's email to pass it to user3 by opening an istr...

...scrambler_istream that does the encryption and that I hook in the mail storage process. The scrambler_ostream is stacked on top of the output stream of the mail_save_context (mail_save_context->data.output) and the scrambler_istream is attached to the input stream when the virtual function istream_opened in the mail_private struct is called. Basically, the encrypt/decrypt works, but during the process the data size changes slightly. And when I'm doing a FETCH BINARY[] via imap, it results in the error... Cached message size smaller than expected (204 < 208) Error: Corrupted index cache...

...dovecot-2.2.35.tar.gz.sig ??? - charset_alias: compile fails with Solaris Studio, reported by ??? ? John Woods. ??? - Fix local name handling in v2.2.34 SNI code, bug found by cPanel. ??? - imapc: Don't try to add mails to index if they already exist there. ??? - imapc: If email is modified in istream_opened hook, mail size isn't ??? ? updated. ??? - lib-dcrypt: When reading encrypted data, more data would not be ??? ? read if buffer was not consumed causing panic or hang. ??? - notify: When notify plugin is used and transaction commit fails in ??? ? dsync, crash occurs. ??? - sdbox: When deliver...

...dovecot-2.2.35.tar.gz.sig ??? - charset_alias: compile fails with Solaris Studio, reported by ??? ? John Woods. ??? - Fix local name handling in v2.2.34 SNI code, bug found by cPanel. ??? - imapc: Don't try to add mails to index if they already exist there. ??? - imapc: If email is modified in istream_opened hook, mail size isn't ??? ? updated. ??? - lib-dcrypt: When reading encrypted data, more data would not be ??? ? read if buffer was not consumed causing panic or hang. ??? - notify: When notify plugin is used and transaction commit fails in ??? ? dsync, crash occurs. ??? - sdbox: When deliver...

I've noticed that maildir IMAP COPY commands can generate invalid dovecot.index entries when all seven of the following are true: - The zlib plugin is enabled; - The zlib_save/zlib_save_level options are NOT enabled; - The source message being copied is compressed; - The mail_log plugin is logging "copy" events; - The mail_log_fields setting includes at least one message header; -

...ng a mail that we're just in the middle of saving, and we didn't do the compression ourself. in such situation we're probably checking if the user-given input looks compressed */ if (_mail->saving && zuser->save_handler == NULL) return zmail->super.istream_opened(_mail, stream); When these lines are removed, the problem no longer happens. I'm guessing that an IMAP COPY with the seven circumstances I mentioned matches "we are reading a mail that we're just in the middle of saving, and we didn't do the compression ourself". But the m...

...gt; 5. ???/mail_allocated/ then /mail_save_begin/ for user2 (at this stage, > the email is encrypted with users2 params) > 6. Dovecot tells to LMTP that mail for user2 is delivered > 7. then, ??? we are still in user2 context ???, an other > /mail_allocated/ is run, followed by a /istream_opened/ > 8. mail user context is swithed to user3 --> /mail_user_created/ --> > plugin's args parsed --> ??? /mail_allocated/ > 9. and??? Dovecot tells to LMTP that mail for user3 is delivered > > So, it appears that Dovecot is re-using user2's email to pass it to &gt...