Looking at mail_filter_mailbox_allocated() of
src/plugins/mail-filter/mail-filter-plugin.c:
if ((class_flags & MAIL_STORAGE_CLASS_FLAG_OPEN_STREAMS) == 0 &&
(class_flags & MAIL_STORAGE_CLASS_FLAG_BINARY_DATA) != 0 &&
muser->out_socket_path != NULL)
v->save_begin = mail_filter_mail_save_begin;
it seems that a backend with MAIL_STORAGE_CLASS_FLAG_OPEN_STREAMS unset and
MAIL_STORAGE_CLASS_FLAG_BINARY_DATA set is expected by the plugin.
Technically, this would thus exclude the mbox backend, since its flag
configuration seems to be exactly the opposite:
struct mail_storage mbox_storage = {
.name = MBOX_STORAGE_NAME,
.class_flags = MAIL_STORAGE_CLASS_FLAG_MAILBOX_IS_FILE |
MAIL_STORAGE_CLASS_FLAG_OPEN_STREAMS |
MAIL_STORAGE_CLASS_FLAG_HAVE_MAIL_GUIDS,
[...]
Is this a correct interpretation?
If yes, what is the rationale?
I couldn't find any info related to such a limitation in the docs; the README
file of http://dovecot.org/patches/2.2/mail-filter.tar.gz even says: "Mail
filter plugin can read an email from any storage supported by Dovecot and
modify the mail in some way"...
All of this stems from my attempts to have working mail filters when I was
trying to better understand the behaviors Stanislas was describing in a recent
thread...
Hence another question; in sdbox-storage.c, the definition of the "alias" for
sdbox comes with:
struct mail_storage dbox_storage = {
.name = "dbox", /* alias */
.class_flags = MAIL_STORAGE_CLASS_FLAG_FILE_PER_MSG,
[...]
The initialization of member class_flags seems to be incomplete, when compared
to the one for the name "sdbox". A typo?
On the other hand, Stanislas showed a configuration with
mail_location = dbox:/mailboxes/%Ld/%Ln
and seemed to have a working mail filter.
If above interpretation is correct, this would mean that the "alias" definition
isn't used, but that the one for "sdbox" is used instead.
Out of curiosity, how/where is that substitution achieved?
Regards,
Axel
