[Dovecot] lda: vacation auto-reply for a virtual address
Hi, I am using Dovecot to manage a complex virtual mailbox setup. It's all working splendidly, thanks to the Dovecot LDA.
This morning, however, I needed to create a vacation-style autoreply for one of the virtual addresses. I made use of cmusieve, authored a little sieve script, and had it working in no time... until I discovered how limited sieve's vacation module is. Most importantly: it's hardcoded to use the Return-Path of a message, but in this very case, I need to actually use the address in the from header. So I had to give up on sieve and am now looking for another solution, but without much success.
Given that mail is delivered by the Dovecot LDA, is there any way to make deliver pass it off to e.g. procmail in such a way that $HOME is set to /srv/vmail/domain.org/localpart, so that procmail can find the .procmailrc?
Cheers,
-- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"we are trapped in the belly of this horrible machine, and the machine is bleeding to death." -- godspeed you black emperor!
spamtraps: madduck.bogus@madduck.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 8 Aug 2007, martin f krafft wrote:
until I discovered how limited sieve's vacation module is. Most importantly: it's hardcoded to use the Return-Path of a message, but in this very case, I need to actually use the address in the from
What's the reason of not using Return-Path? When it is missing, you can search the archives for a patch of mine, that uses the -f argument in this case. -> And the reply, why NOT to use From for sending replies ;-)
Given that mail is delivered by the Dovecot LDA, is there any way to make deliver pass it off to e.g. procmail in such a way that $HOME is set to /srv/vmail/domain.org/localpart, so that procmail can find the .procmailrc?
Of course, you could patch Dovecot LDA. It is rather straight forward.
Another idea is to setup your MTA to deliver each mail to two maildrops, traditionally this is called ".forward" files, because in sendmail you can create a file ".forward" in the user's homedir and put all the mail forwards there, e.g.:
\account "|vacation -a alias1 -a alias2 account"
\account is necessary to file the mail into the local maildrop (INBOX), too; otherwise it would only run vacation and trash the mail afterwards.
But, such program will normally use Return-Path as well.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRrm93C9SORjhbDpvAQICgggA3WbNxr5nrhigaJHa/Vk71YXdHNOeueC8 QCngSQ2ErSXR4ixAqMiSevDA7T1y3VKsRE2X41OAJunxxoFFliSeIGRvjBh2pCoG iv0UbWiLkLP5WspQqmRMR2mm3q9wZsy2geQiTtWvYArPMTbJoIMvRZz2TyFoqixU jMfMMHMPTBCniVjpwH93XQtzXAcQHp0cllfGSvP8wdI8Ja/wNIE8sg37g6JQ1gKF JXo13e0y0jIrBr+tVWbQjycXJ6YI9J6QTVyN/yphQ3za4igftWjXHRFD2OBdiT+q llNbNHCIemsQuvQVjJ2L7QSkW1kN/xq7xP2zb/vtGUK4iXOVkyMzpg== =oW4A -----END PGP SIGNATURE-----
also sprach Steffen Kaiser skdovecot@smail.inf.fh-bonn-rhein-sieg.de [2007.08.08.1458 +0200]:
until I discovered how limited sieve's vacation module is. Most importantly: it's hardcoded to use the Return-Path of a message, but in this very case, I need to actually use the address in the from
What's the reason of not using Return-Path?
The mailbox receives mail sent from a web interface not in our control. We know From is verified because else the user could not have used the web interface, but Return-Path is always set to the person running the web service.
When it is missing, you can search the archives for a patch of mine, that uses the -f argument in this case. -> And the reply, why NOT to use From for sending replies ;-)
I am aware of reasons not to use them. In this case it's a non-public address used only by the web interface.
Given that mail is delivered by the Dovecot LDA, is there any way to make deliver pass it off to e.g. procmail in such a way that $HOME is set to /srv/vmail/domain.org/localpart, so that procmail can find the .procmailrc?
Of course, you could patch Dovecot LDA. It is rather straight forward.
As a long-time Debian user, I'd really rather not patch anything. :)
Another idea is to setup your MTA to deliver each mail to two maildrops, traditionally this is called ".forward" files, because in sendmail you can create a file ".forward" in the user's homedir and put all the mail forwards there, e.g.:
Virtual users don't really have home directories and postfix's virtual delivery agent doesn't call them anyway.
But yes, if dovecot's LDA would honour something like .forward files, I'd be happy.
-- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"no problem is so formidable that you can't just walk away from it." -- c. schulz
spamtraps: madduck.bogus@madduck.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 8 Aug 2007, martin f krafft wrote:
As a long-time Debian user, I'd really rather not patch anything. :)
Um, I couldn't stand this policy while waiting for Sarge.
But yes, if dovecot's LDA would honour something like .forward files, I'd be happy.
Actually, the forward files functionality is mail forwarding per user, this is you setup two (independed) maildrops per recipient; it's a feature of the MTA, not of the MDA.
One maildrop is the mailbox of the local user, the other one is the auto-responder.
Maybe, you could also name it "aliasing", you alias the local recipient to the local recipient himself and the responder (double the mail, like if you would forward the mail to two different remote addresses). In sendmail the main difference between ".forward" and aliases is that aliases are executed with the permission of the MTA, but .forwards with the permissions of the user. I don't know postfix, so I cannot use the correct terms of it.
Sendmail uses different mailers (exim calls them transports, if I remember correctly) for the two different maildrops, "scripts" are invoked by the virtual "*prog*" mailer, whereas the spooling into a local mailbox is performed by the "local" mailer, which is bound to e.g. Dovecot deliver.
http://www.postfix.org/local.8.html "An alias or ~/.forward file may list any combination of external commands, destination file names, :include: directives, or mail addresses. See aliases(5) for a pre- cise description. Each line in a user's .forward file has the same syntax as the right-hand part of an alias." this paragraphe should cover what I mean (section: SYSTEM-WIDE AND USER-LEVEL ALIASING).
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRrq8Fi9SORjhbDpvAQLkCAf7BiQ1SsQdMSTw958e1z4o96tV4ljQES5p R8T004kjfmqccXuoyyzowL+oPzB9GFSHRYJkRb889FGTN1OCWiDQF1sySOVWsAn+ O/zpnuKaQ3pYLAhTuwoNviBT22sVseRNJh0LxiV8123rxrdMFGxHczzENh9+SJCN OdfVuaNBwf8eiVIuokLg1B+fbMi1TvUaYkrgMZLQJsUX+StT88AS92VVk1hlb63f OHJWpIbr+/8QMHlXrHQkhVk1TRg0hMX7T/0z1QiGK0GuZ5dT92CgnuyhZYzyQrpQ /bU08V/sM7AIcf3D0jabxXznUK01cxekOFG7602VHHHAfXLH4HBeHA== =wbX2 -----END PGP SIGNATURE-----
also sprach Steffen Kaiser skdovecot@smail.inf.fh-bonn-rhein-sieg.de [2007.08.09.0902 +0200]:
Sendmail uses different mailers (exim calls them transports, if I remember correctly) for the two different maildrops, "scripts" are invoked by the virtual "*prog*" mailer, whereas the spooling into a local mailbox is performed by the "local" mailer, which is bound to e.g. Dovecot deliver.
But postfix's local transport cannot deliver to virtual mailboxes, and the virtual transport does not provide for command execution:
virtual(8): This delivery agent only delivers mail. Other features such as mail forwarding, out-of-office notifications, etc., must be configured via virtual_alias maps or via similar lookup mechanisms.
So yes, if I find a suitable virtual delivery agent or a way to pass the maildir location from postfix to e.g. procmail, I'll have it solved. But right now it does not look like it's possible.
-- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"we should have a volleyballocracy. we elect a six-pack of presidents. each one serves until they screw up, at which point they rotate." -- dennis miller
spamtraps: madduck.bogus@madduck.net
also sprach martin f krafft madduck@madduck.net [2007.08.09.1319 +0200]:
So yes, if I find a suitable virtual delivery agent or a way to pass the maildir location from postfix to e.g. procmail, I'll have it solved. But right now it does not look like it's possible.
I can report success. This solution requires me to take the performance hit due to procmail, but it also gives me a lot of flexibility. I might replace the procmailrc with a POSIX shell script if it's less resource-hungry that way.
/etc/postfix/master.cf: vprocmail unix - n n - 5 pipe flags=DRhu user=vmail:vmail argv=/usr/bin/procmail -a ${recipient}
/etc/postfix/main.cf virtual_transport = vprocmail virtual_mailbox_maps = pgsql:$conf_dir/pgsql_virtual_mailbox_maps virtual_mailbox_base = /srv/vmail # (== ~vmail) virtual_minimum_uid = 60000 # (== vmail) virtual_uid_maps = static:60000 virtual_gid_maps = static:60000 vprocmail_destination_concurrency_limit = 5 vprocmail_destination_recipient_limit = 1
cat ~vmail/.procmailrc BIFF=no COMSAT=no
NICE='nice -20'
RECIPIENT="$1"
MAILBOX="`$NICE /usr/sbin/postmap -q $RECIPIENT pgsql:/etc/postfix/conf/pgsql_vi HOME="$HOME/$MAILBOX" ORGMAIL="$HOME/.maildir/"
# http://bugs.debian.org/387883 requires us to create the directory
# as the vmail user because otherwise it will be owned by root
# (which is how spamd does it)
MKDIR=$NICE install -d "$HOME"/.spamassassin
UMASK=0007
# and we might just as well create a .procmailrc which is writeable by the
# group so that ACLs work
RC=touch "$HOME"/.procmailrc
:0 fw |$NICE /usr/bin/spamc -x -u "$RECIPIENT"
INCLUDERC="$HOME/.procmailrc"
:0 |$NICE /usr/lib/dovecot/deliver -d "$RECIPIENT"
Cheers,
-- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
chaos reigns within. reflect, repent, reboot. order shall return.
spamtraps: madduck.bogus@madduck.net
Hi,
El Miércoles, 8 de Agosto de 2007 17:42, martin f krafft escribió:
Of course, you could patch Dovecot LDA. It is rather straight forward.
As a long-time Debian user, I'd really rather not patch anything. :)
As long as nothing depends on whatever you patch, you can do it with no problem. And I don't think that anything depends on dovecot.
Aaaaaaaaaagur.
Joseba Torre. CIDIR Bizkaia.
also sprach Joseba Torre joseba.torre@ehu.es [2007.08.09.1251 +0200]:
As long as nothing depends on whatever you patch, you can do it with no problem. And I don't think that anything depends on dovecot.
You just won't get security updates anymore.
-- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"even if you persuade me, you won't persuade me." -- aristophanes
spamtraps: madduck.bogus@madduck.net
participants (3)
-
Joseba Torre
-
martin f krafft
-
Steffen Kaiser