[Dovecot] sieve vacation response

[Steffen Kaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 7 Aug 2009, Timo Sirainen wrote:

> On Fri, 2009-08-07 at 20:26 +0200, Jure Pečar wrote:
>> On Fri, 07 Aug 2009 13:57:57 -0400
>> Timo Sirainen <tss at iki.fi> wrote:
>>
>>>> Currently, you need to add all allowed aliases to the :addresses
>>>> argument of the vacation command. My TODO list contains a new feature
>>>> that lets you extract additional valid aliases directly from a
>>>> dictionary (e.g. an SQL database). It is not at the top of my TODO list
>>>> yet, but since you are not the only one needing this, I'll give it some
>>>> more priority.
>>>
>>> I don't think the above really needs a dict? Rather maybe there's a way
>>> to have the script check the original unexpanded address. Is it stored
>>> in some specific header, or how would Dovecot/Sieve know about it?
>>
>> I agree - for example, we have X-Original-To. I'll suggest our team to
>> match against that header.
>
> What about Delivered-To?

Not all MTAs add this header, e.g. stock sendmail. In case of a stock 
sendmail installation there is _no_ evidence of the RCPT TOs at all, if 
there is not exactly one recipient.

I would re-raise my suggestion to have:

localPart -or- localPart@*

matches any domain or - if I just read it, I prefer this - an 
admin-defined list of domains.

This would at least won't require a dict and will fail, if one hosts 
at least two distinct domains and a mail is sent to

localPart at example.com   explicitly, but
localPart at example.net   implicitly (same local part, domain clash).

Moreover, locally I have users, who do selectivly pick particular 
(recipient) domains, which to respond to, whereas others want that "it 
just works". To trigger to fetch aliases from the dict should be 
controllable by each user, e.g. an empty :addresses list or a "*" in the 
list pulls the default from there or something like that.

Regards,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBSn/f0nWSIuGy1ktrAQJYxwf/eMrxbmKcxbAUphVjzMh7Nit6GuTEi2+W
3zdX3cOIxl8IZrSZWD+cxlS27AYrbwKBy2g5nL6v6fuwO+a24mfmgYbzzsPJxpvl
zexldhqiEzlqtikuEUcMv0FBMqI9DJIIWTueENsN9PH0/GtfVk0gY0erbi2MW7I7
mwD9xbMvN2wnkG4Fe2bBcLBaneP0E2QJBZ3sniDfAIkrjdjrnmJbkWLRIOX3zleV
WuXd343vmQ8JRYPriSpLqdBhmBCLJA/lyMGLJI3VrzFDxR/pGhCROoaRNydxEzmH
p+tLTdiDHuFc3bmqI/iedTOicSUjM+PuHxIXMI8RhgDaioGaEKapiw==
=8Ftl
-----END PGP SIGNATURE-----