Op 7/27/2016 om 12:46 PM schreef Harald Leithner:
Hi,
it seams I have a problem with the vacation script.
The problem is that the vacation answers to a address that is not listed in the sieve script. I checked the postfix master.conf which delivers to lda correct parameter.
In the logfile you can see that that office@example.com received a message that get delivered to user@example.com (with the sievescipt) and to office@example.com (another user without script).
The sieve script has the :addresses parameter only set to user@example.com
Is something wrong with my setup?
We use roundcube + sievemanage to create sieve scripts.
[...]
postfix master.conf dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -a ${original_recipient} -d ${user}@${nexthop} -e
First of all, the ":addresses" argument is not an exclusive list of which addresses the vacation action will respond for. It is a list of alternative addresses, for when the message headers have no address that is recognized as the envelope recipient. So, even when ":addresses" does not list a particular recipient address, the vacation action will still respond for it if the message is addressed at that recipient explicitly in the headers. Read https://tools.ietf.org/html/rfc5230#section-4.5 for more info.
Due to the way you invoke dovecot-lda, Sieve only gets to see the original recipient address, which is "office@example.com". I am assuming, that is what is in either the "To" or "Cc" headers of the message, which means that vacation will respond.
This problem is probably fixed by using a -r ${recipient} parameter for dovecot-lda, in addition to the existing -a argument. This way, vacation will use the final recipient address instead. LDA parameters are documented here: http://wiki2.dovecot.org/LDA#Parameters .
There is additional info in the description of the sieve_vacation_use_original_recipient setting (http://wiki2.dovecot.org/Pigeonhole/Sieve/Extensions/Vacation#Configuration). Leave this at the default "no" though, as "yes" would negate the fix described above.
Regards,
Stephan.