[Dovecot] simple steps with sieve

Stephan Bosch stephan at rename-it.nl
Tue Oct 20 18:34:01 EEST 2009


Peter Borg wrote:
> I find it really hard to believe that Gavin and I are the only ones to hit
> this issue. That said I've probably been hacking at this particular system
> too long and am missing something very obvious....!
> 
You're definitely not the only one. Finding a good solution is difficult 
however. The intention of this check within the vacation action is to 
prevent spurious vacation responses to for example Bcc:'ed deliveries 
(and perhaps multi-drop aliases).

Thus far I have seen the following suggestions to solve this problem:

1) Do some sort of a dict lookup that yields all valid aliases for the 
user's account or alternatively a lookup that checks whether an address 
is a valid alias for an account (if many or wildcard aliases exist). A 
problem with this solution is that potentially many recipients exist and 
that each would need to be looked up (up to some limit preferably).

2) Ask the MTA somehow for the same result as in (1) to make sure alias 
resolution is identical (execute the real alias processing). I am not 
sure which MTA's even support something like that. Also has the lookup 
load of (1).

3) Allow configuring some sort of external binary that is run to get the 
same result as in (1). Has the lookup load of (1).

4) Store the list of possible recipient addresses alongside
the sieve script, no need to look them up that way.

5) Let the MTA provide deliver with the original recipient address as 
the -a parameter. This will cause multi-drop aliases to be reported as 
sender in messages produced by Deliver or Sieve.

6) Adjust Deliver/Sieve to accept the original recipient as a separate 
parameter.

7) Allow wildcards in the :addresses parameter of the vacation action. 
This is non-standard and then would only work for Dovecot. It gives the 
user full control, which is not always desirable (but hard to prevent 
anyway). It does not solve the problem properly for everyone. I'd rather 
not deviate from the standard.

Any other ideas? I don't really like any of the solutions above, perhaps 
  nr 6.

Regards,

Stephan.




More information about the dovecot mailing list