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