Forwarding to many destinations emails about mailu

[kaiyou]

After some thinking, I believe external scripts are the only decent way to go. The behaviour could be accomplished with a very simple script, provided that sendmail is available locally and that the original mail is provided on stdin.

The behaviour of such a script would be:

1. duplicate stdin
2. fork and exec sendmail with the proper flags
3. loop with the next address

[kaiyou]

• For user forwards, multiple addresses are not yet supported indeed. Forwards are implemented using Sieve redirect command, I am not sure that it supports multiple destinations, I will check and maybe implement it using logic if required.
• For aliases, #19 is already open regarding the issue. I updated the title to better describe the problem, which I believe correlates with the use of select2 for the alias form instead of multitag.

[kaiyou]

From the Sieve RFC :

Syntax:   redirect <address: string>

   The "redirect" action is used to send the message to another user at
   a supplied address, as a mail forwarding feature does.  The
   "redirect" action makes no changes to the message body or existing
   headers, but it may add new headers.  The "redirect" modifies the
   envelope recipient.

   The redirect command performs an MTA-style "forward"--that is, what
   you get from a .forward file using sendmail under UNIX.  The address
   on the SMTP envelope is replaced with the one on the redirect command
   and the message is sent back out.  (This is not an MUA-style forward,
   which creates a new message with a different sender and message ID,
   wrapping the old message in a new one.)

   A simple script can be used for redirecting all mail:

   Example:  redirect "[email protected]";

redirect does not seem to support multiple destination addresses. I will try tonight on a test server and implement using a Sieve loop if possible. Otherwise we will not be able to support multiple destination for user forwards.

[jkarlosb]

Sorry, I don't have many knowledge about Sieve language, can you explain me why is better using Sieve vs virtual_alias_maps with a hash table map file how I describe above?

I tested the latter and I checked that it can be used to email forwarding (with local copy) and aliases to multiple destinations.

Maybe, as I tell you in #19, is not possible using sql db easily with admin web interface for multiple destinations, but it is easiest with plain text + postmap.

Ok, I wait for your opinion.

[kaiyou]

The idea when designing this was that forwarding an email is a user choice while aliases are MTA operations. As such, a user choice belongs in the MDA, therefore Dovecot and Pigeonhole.

Maybe the design choice is too constraining, and maybe having an SQL-based map in Postfix would simplify things. Still, some important differences:

• aliases is done prior to antispam or antivirus checks, forwarding is done afterwards and I believe it should remain so (a user who sets a forward address does not expect any more spam than he or she gets in the initial inbox) ;
• currently forwarding by Sieve is done prior to executing user scripts because I first wanted something simple before, in the future it should be performed after user scripts, therefore user scripts could alter the message or drop it before it is forwarded, this behaviour cannot be accomplished if forwarding with Postfix.

[kaiyou]

I just pushed to branch feat-forward-multiple to work on this issue. For now it only stores multiple destinations in the same format as aliases, forwarding is thus broken because Dovecot does not interpret the comma separated string properly.

[kaiyou]

Sieve does not support loops and I do not believe that extdata is able to provide a list of any kind. I am not sure how to address this issue.

[jkarlosb]

OK, I understand it and I believe too it should remain so.

Loops in Sieve seem dangerous, it is the cause because this feature is unavailable. With loops and vnd.dovecot.filter plugin we could implement it, but it don´t seem possible.

I think that we can use vnd.dovecot.execute or vnd.dovecot.pipe plugins in dovecot/sieve/before.sieve for to make our own external program which forwarding the emails calling Postfix directly ...

For another hand, Horde team fixed this issue:

• https://bugs.horde.org/ticket/11457
• https://github.com/horde/horde/blob/7ba9e0a92a1ddc8d95d4447e6256cafcadc50ff1/ingo/lib/Script/Sieve.php
• https://github.com/horde/horde/blob/7ba9e0a92a1ddc8d95d4447e6256cafcadc50ff1/ingo/lib/Script/Sieve/Action/Redirect.php

They regenerate the sieve config with they own framework. We could modify dovecot/sieve/before.sieve from admin interface from forward page every time that user forward config is changed.

Neither of the two ideas I really like, but do you think about it?

[jkarlosb]

Of course, another workaround could be forwarding to an alias, that alias redirects to multiple destinations. We simply have explain the multiple forward configuration in the readme file. This way the desired behaviour would respected, right? In this case, this workaround could fix the problem for now.

[kaiyou]

(I renamed the issue to remove the part about aliases)

Thank you for the ideas. Documenting a proper configuration using aliases seems like a simple enough workaround solution if we do not find anything better soon.

Regarding your proposals, one of the core design concepts in Freeposte.io was to put as much as possible in the database. I would love to find a way to store DKIM keys in the database, so writing custom sieve scripts to disk does not thrill me. I would like to keep it as a last resort option.

Instead, I see three solutions that do not require to write dynamic files to disk:

• the first you suggest, using external scripts, I never used them, I would have to have a proper look and see how we could do a proper redirect from there;
• shipping a homemade dovecot pigeonhole extension that provides redirect operation to multiple addresses;
• setting an upper limit and implementing a homemade loop as a (very) ugly sive script.

[kaiyou]

Also, extprogram is not currently packaged in Alpine, we would have to provide a package. After dicussing the matter with ncopa, the plan is to write a single Dovecot APKBUILD with multiple subpackages for plugins. I will start working on this.