Re: [Dovecot] sieve vacation response
bart wrote:
Jure Pečar 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.
Also :addresses ["*"] would be ok, without the need to explicitly list all
addresses.
You can circumvent explicitly listing all addresses by doing something
like this:
require ["variables", "envelope", "vacation"];
if envelope :matches "to" "*" {
set "envto" "${1}";
vacation
:addresses ["${envto}"]
"vacation message here...";
}
Iew, scary things one can do with the variables extension. :) Wouldn't
surprise me when the specification authors did not consider this in
their efforts to write the vacation RFC.
Beware that this solution will cause vacation responses to be sent when
the mailbox is part of a multi-drop alias (an ad-hoc mailinglist). This
is usually not what you want. When a large group is collectively on
vacation, an unfortunate sender could receive many useless and redundant
vacation responses from the implicit recipients. Basically, this means
that potentially a response is sent for all implicitly delivered messages.
These considerations are also true for the "*" implementation suggested
above.
Regards,
Stephan.
Re: [Dovecot] sieve vacation response
Jure Pečar 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.
>>
>
> Also :addresses ["*"] would be ok, without the need to explicitly list all
> addresses.
>
>
You can circumvent explicitly listing all addresses by doing something
like this:
require ["variables", "envelope", "vacation"];
if envelope :matches "to" "*" {
set "envto" "${1}";
vacation
:addresses ["${envto}"]
"vacation message here...";
}
regards, bart
Re: [Dovecot] sieve vacation response
-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 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- localp...@* 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 localp...@example.com explicitly, but localp...@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-
Re: [Dovecot] sieve vacation response
On Fri, 2009-08-07 at 15:01 +0200, Jure Pečar wrote: > And when sent and delivered to some...@example.com, we get this in the log: .. > Our final recipients are in the form of usern...@fqdn.hostname.com; it looks > like this is being matched in sieve as address. But we want to match against > original recipient address, not address after alias expansion. Is it really necessary for you to change the address like that? I think that's going to mess up other tests too. I think deliver should eventually be called with: deliver -a some...@example.com -d usern...@fqdn.hostname.com Then vacation and everything works correctly. Can you configure your MTA to do that? deliver/dovecot-auth could also internally do the some...@example.com -> usern...@fqdn.hostname.com translation in userdb lookup. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] sieve vacation response
Timo Sirainen schreef: On Fri, 2009-08-07 at 19:21 +0200, Stephan Bosch wrote: dovecot: deliver(username): sieve: msgid=<...>: discarding vacation response for message implicitly delivered to Our final recipients are in the form of usern...@fqdn.hostname.com; it looks like this is being matched in sieve as address. But we want to match against original recipient address, not address after alias expansion. Any ideas? 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? That is the problem. It usually isn't available anywhere, except perhaps in the Received: headers. Parsing those should yield all intermittent destination addresses. When one of those is also listed in one of the relevant headers of the message itself (To, Cc, Bcc, Resent-To, Resent-Cc, or Resent-Bcc), the vacation action would succeed. I am not sure how valid and safe this is. Regards, -- Stephan Bosch step...@rename-it.nl
Re: [Dovecot] sieve vacation response
On Fri, 07 Aug 2009 19:21:53 +0200 Stephan Bosch 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. Also :addresses ["*"] would be ok, without the need to explicitly list all addresses. -- Jure Pečar http://jure.pecar.org http://f5j.eu
Re: [Dovecot] sieve vacation response
On Fri, 07 Aug 2009 14:27:29 -0400 Timo Sirainen wrote: > > > 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? Looks like that one is already in expanded form, usern...@hostname. -- Jure Pečar http://jure.pecar.org http://f5j.eu
Re: [Dovecot] sieve vacation response
On Fri, 2009-08-07 at 20:26 +0200, Jure Pečar wrote: > On Fri, 07 Aug 2009 13:57:57 -0400 > Timo Sirainen 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? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] sieve vacation response
On Fri, 07 Aug 2009 13:57:57 -0400 Timo Sirainen 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. -- Jure Pečar http://jure.pecar.org http://f5j.eu
Re: [Dovecot] sieve vacation response
On Fri, 2009-08-07 at 19:21 +0200, Stephan Bosch wrote: > > dovecot: deliver(username): sieve: msgid=<...>: discarding vacation > > response for message implicitly delivered to > > > > Our final recipients are in the form of usern...@fqdn.hostname.com; it > > looks like this is being matched in sieve as address. But we want to match > > against original recipient address, not address after alias expansion. > > > > Any ideas? > 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? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] sieve vacation response
Jure Pečar schreef:
Hello,
we're implementing a dovecot 1.2.1 with sieve 0.1.7 and managesieve 0.11.7.
We're having problems with creating sieve scripts so that vacation works.
Our script looks like this:
require ["fileinto", "vacation"];
if address :matches ["To", "Cc"] "*some...@example.com*" {
if not header :matches "X-Spam-Status" "Yes*" {
vacation
:days 1
:subject "test"
"autoresponder test.";
keep;
}
}
And when sent and delivered to some...@example.com, we get this in the log:
dovecot: deliver(username): sieve: msgid=<...>: discarding vacation response for
message implicitly delivered to
Our final recipients are in the form of usern...@fqdn.hostname.com; it looks
like this is being matched in sieve as address. But we want to match against
original recipient address, not address after alias expansion.
Any ideas?
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.
Regards,
--
Stephan Bosch
step...@rename-it.nl
