[Dovecot] Dovecot Sieve: Vacation Recipient
Hi!
I tried to use the sieve vacation plugin, but we're facing a little problem: our user's addresses are <uid>@<domain>, and if they want to use imap and sieve, they can have a forward to <uid>@imap.<domain>. The return-path, and hence the address the vacation message is sent to, is then <uid>@<domain> and not the original sender of the message. Is there any way to circumvent this? Sending a vacation back to oneself doesn't really make sense here :)
Oh, and happy new year and thank you all for this great piece of software!
-- Lukas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 7 Jan 2010, Lukas Kolbe wrote:
I tried to use the sieve vacation plugin, but we're facing a little problem: our user's addresses are <uid>@<domain>, and if they want to use imap and sieve, they can have a forward to <uid>@imap.<domain>. The return-path, and hence the address the vacation message is sent to, is then <uid>@<domain> and not the original sender of the message. Is there any way to circumvent this? Sending a vacation back to oneself doesn't
Hmm, I understand to "forward" a mail so that a MTA accepts a message, then determines to send it to another address. In this process the original sender (aka argument of the MAIL FROM SMTP command) is preserved.
What you describe is that the message is delivered by the MTA locally, but then send to another address.
Both methods do have their pros and cons:
first one preserves the original sender, second does not
first one fails on SPF tests, second one does not
You will either need
a) to switch to the first method and use forwarding at MTA stage or
b) to determine a way to re-send the message with the original sender, which is not "From:" but maybe "Return-Path", (sort of the same as first method, but handled manually) or
c) to pass along the original sender, e.g. in a custom header, to the dovecot server and patch the Sieve implementation to use that info.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBS0Xmhb+Vh58GPL/cAQI9ZQf+OtydPwPWSHJbI+g3Bsj3jAiYcQTejTkY eKjCkcyGBqaT1mqXGWVmAZXqyvjyANfGXT5VIVwzIKNCDP1eFRPEmjcPgpI/MnIV xtApuUNDbXPubo258QEdQmb4ZBOt+x4cXMELiQ1gKttCwHXLbMEbuXqdweym92m7 12TdQvKGPPr/Y1PQoayNpvSMTyfaymFQ98slZ7xewoEQ+YNL0XTCtpuPQhkP/7sd 0+5ouENogkzN9BADBt3lElQdD4/bjeRftZe6rdLqM43qczq8mC0si5/2q/8U5H4R hE0Of5bqYYyRRnG5RbmheaKQzNp1bbgyIJcOeNG7UzxOoFwg/ZhGJA== =3ArD -----END PGP SIGNATURE-----
Am Donnerstag, den 07.01.2010, 14:49 +0100 schrieb Steffen Kaiser:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 7 Jan 2010, Lukas Kolbe wrote:
I tried to use the sieve vacation plugin, but we're facing a little problem: our user's addresses are <uid>@<domain>, and if they want to use imap and sieve, they can have a forward to <uid>@imap.<domain>. The return-path, and hence the address the vacation message is sent to, is then <uid>@<domain> and not the original sender of the message. Is there any way to circumvent this? Sending a vacation back to oneself doesn't
Hmm, I understand to "forward" a mail so that a MTA accepts a message, then determines to send it to another address. In this process the original sender (aka argument of the MAIL FROM SMTP command) is preserved.
What you describe is that the message is delivered by the MTA locally, but then send to another address.
Correct - the user has either a .forward or a procmailrc, both resulting in a resend to <uid>@imap.<domain>. It has been this way for ages, unfortunatly.
Both methods do have their pros and cons:
first one preserves the original sender, second does not
first one fails on SPF tests, second one does not
You will either need
a) to switch to the first method and use forwarding at MTA stage or
b) to determine a way to re-send the message with the original sender, which is not "From:" but maybe "Return-Path", (sort of the same as first method, but handled manually) or
c) to pass along the original sender, e.g. in a custom header, to the dovecot server and patch the Sieve implementation to use that info.
I'll look into option b then. It might not be possible with the .forward approach, but almost certainly is with procmail. We're looking into decoupling the mail service from the users home directories anyway, which would fix this issue naturally. Thanks for the clarification!
Regards,
Steffen Kaiser
-- Lukas Kolbe
participants (2)
-
Lukas Kolbe
-
Steffen Kaiser