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:
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).
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).
Allow configuring some sort of external binary that is run to get the same result as in (1). Has the lookup load of (1).
Store the list of possible recipient addresses alongside the sieve script, no need to look them up that way.
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.
Adjust Deliver/Sieve to accept the original recipient as a separate parameter.
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.