Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forwarding to many destinations emails #34

Closed
jkarlosb opened this issue Aug 9, 2016 · 11 comments
Closed

Forwarding to many destinations emails #34

jkarlosb opened this issue Aug 9, 2016 · 11 comments
Milestone

Comments

@jkarlosb
Copy link
Contributor

jkarlosb commented Aug 9, 2016

Hi, I would like to forward to many destinations, but I don't see that option in the administration interface, when I fill the box with various email addresses (separated by spaces or commas), not working for me.

For another hand, I think that there are a bug in edit alias page, because when I try to add many email addresses and I save the configuration with Create button, when I check the aliases again, only one appear.

This can be solved (workaround) with the new config override feature (#29, #31), changing virtual_alias_maps parameter of main.cf with a table map file:

/freeposte/overrides/postfix.cf

virtual_alias_maps = hash:/etc/postfix/virtual_alias.map

/freeposte/overrides/virtual_alias.map

info@mydomain.com info@mydomain.com, forward1@gmail.com, forward2@gmail.com, forward3@gmail.com
@kaiyou
Copy link
Member

kaiyou commented Aug 9, 2016

  • 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, Aliases with more than one destination do not work #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
Copy link
Member

kaiyou commented Aug 9, 2016

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 "bart@example.edu";

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
Copy link
Contributor Author

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
Copy link
Member

kaiyou commented Aug 11, 2016

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
Copy link
Member

kaiyou commented Aug 11, 2016

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
Copy link
Member

kaiyou commented Aug 11, 2016

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
Copy link
Contributor Author

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:

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
Copy link
Contributor Author

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 kaiyou changed the title Forwarding or aliases to many destinations emails Forwarding to many destinations emails Aug 12, 2016
@kaiyou
Copy link
Member

kaiyou commented Aug 12, 2016

(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
Copy link
Member

kaiyou commented Aug 13, 2016

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
Copy link
Member

kaiyou commented Aug 13, 2016

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.

@kaiyou kaiyou added this to the 1.4 milestone Oct 31, 2016
@kaiyou kaiyou closed this as completed in 692bcda Dec 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants