[Dovecot] Plugin

[Alex Baule]

Hi Timo....

Making my tests with the body and head separately (splited in 2 files and
concatenated with the i_stream_create_concat), getting some errors that I do
not understand.
I did not create the plugin, the changes is in maildir-mail.c. Is the same
that I write in the beginning of the email.
The error happens when there is attachment in the message, with a attachment
with 12K of size, i got the errors...
I got these messages from /var/log/mail


Jan 27 09:52:21 brc dovecot: IMAP(alex at exemplo.com.br): Panic: file
istream.c: line 96 (i_stream_read): assertion failed: (stream->eof)
Jan 27 09:52:21 brc dovecot: IMAP(alex at exemplo.com.br): Raw backtrace: imap
[0x80eb910] -> imap [0x80eb96a] -> imap [0x80eb21a] ->
imap(i_stream_read+0x14b) [0x80f0b0b] -> imap(i_stream_read_data+0x1d)
[0x80f0b8d] -> imap [0x80e3c5f] -> imap [0x80e4dfe] ->
imap(message_parser_parse_next_block+0x2a) [0x80e3daa] ->
imap(message_parser_parse_body+0x2c) [0x80e3f0c] -> imap [0x809e68e] -> imap
[0x809e7cf] -> imap(index_mail_get_special+0x3f9) [0x809ecf9] -> imap
[0x8088b07] -> imap [0x80666a5] -> imap(imap_fetch_more+0x104) [0x8067304]
-> imap(cmd_fetch+0x282) [0x805f012] -> imap(cmd_uid+0x7f) [0x806377f] ->
imap [0x80643dc] -> imap [0x806448b] -> imap(client_handle_input+0x3f)
[0x80645df] -> imap(client_input+0x5f) [0x806514f] ->
imap(io_loop_handler_run+0x110) [0x80f4620] -> imap(io_loop_run+0x28)
[0x80f36e8] -> imap(main+0x738) [0x806d628] ->
/lib/libc.so.6(__libc_start_main+0xd8) [0xb75d47c8] -> imap [0x805d071]
Jan 27 09:52:21 brc dovecot: dovecot: child 24407 (imap) killed with signal
6 (core dumps disabled)


Why this happens ? The size of message dont change, it is only splited.


2010/1/20 Timo Sirainen <tss at iki.fi>

> On 20.1.2010, at 20.45, Alex Baule wrote:
>
> > Timo Sirainen send to me this modification, in
> > src/lib-storage/index/maildir/maildir-mail.c
> >
> > struct istream *full_input[3];
> > full_input[0] = i_stream_create_fd(fd, 0, TRUE);
> > full_input[1] = i_stream_create_fd(fd1, 0, TRUE);
> > full_input[2] = NULL;
> > input = i_stream_create_concat(full_
> > input);
> >
> > This is necessary because my Header and Body is splited.
> > This modification works fine.
> >
> > My question is:
> >
> > There is a way to do this with a plugin ?
> > I dont know how to implement this in a plugin, because i dont know what
> is
> > the hook to change the maildir_open_mail functions. (this is the function
> > with the modification above) .
>
> It's similar to how zlib plugin does its work. You need to copy&paste
> enough code from it, so that you'll get to
>
> static int zlib_maildir_get_stream(struct mail *_mail,
>
> The important part of the code below it that replaces the maildir's istream
> is:
>
>                imail->data.destroying_stream = TRUE;
>                i_stream_unref(&imail->data.stream);
>                i_assert(!imail->data.destroying_stream);
>
>                if (fd == -1)
>                        return -1;
>                imail->data.stream = handler->create_istream(fd);
>
> So instead of handler->create_istream(fd), you'll use your own. Or actually
> IIRC you didn't even want to destroy the original stream, so instead of any
> of the above, you'd probably do something like:
>
> old_stream = imail->data.stream;
> imail->data.stream = create_your_stream(old_stream);
> i_stream_unref(&old_stream);
>
> > Another question is: There is a seek function, in dovecot, and in zlib
> > plugin, it is rewrite by another function, that use the "gzseek" to do
> the
> > seek. My splited body will be encrypted, and the crypto no have seek,
> > because the message will be encrypted. (if i open the message, decrypt
> and
> > seek to some position, maybe work).
> >
> > The seek function is really necessary to IMAP and maildir ?
>
> Well, gzseek() doesn't work any easier. It can't directly jump to wanted
> position. When seeking forwards, it'll just read and uncompress data until
> it reaches the wanted offset. When seeking backwards, it'll go back to
> beginning and start reading and uncompressing from there. That's why there's
> the "marked" code in istream-zlib that tries to
> avoid the backwards seeks. You could maybe use something like that too, but
> you could also put the whole thing through i_stream_create_seekable() and
> Dovecot just keeps the whole message in memory (by setting
> max_buffer_size=(size_t)-1).