[Dovecot] simple steps with sieve
skdovecot at smail.inf.fh-brs.de
Wed Oct 28 12:43:50 EET 2009
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 20 Oct 2009, Stephan Bosch wrote:
> Finding a good solution is difficult
Yes! and there is no general solution for every setup, I guess.
> 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).
But _why_ is BCC spurious? There are spurious BCC, but not in general.
If I BCC a message to somebody, I want to know an out-of-office state.
Just like for any CC or TO recipient.
> 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).
When I consider some automagic to get all aliases per account, I wonder
how do I stop Sieve from using this automagic? So I surround the vacation
with an if conditional, e.g. to respond only to 5 out of my 386 possible
Dunno how a dict can be working internally, but can Dovecot dicts perform
> 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
because of the "not sure" this variant won't work.
> 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).
This loads off the problem to the admin. Not too bad, IMHO. And would
include variant 2)
> 4) Store the list of possible recipient addresses alongside
> the sieve script, no need to look them up that way.
Problem with (quote from variant 1) ): "if many or wildcard aliases exist"
> 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.
Same problem as 2). sendmail does not pass along envelop recipients, if
more than one recipient is specified, for example.
Also, what is the "original recipient address", the envelope address? If
so, you call BCC's non-spurious now. It also won't help with: "if many or
wildcard aliases exist"
> 6) Adjust Deliver/Sieve to accept the original recipient as a separate
Looks like the same as 5), or am I mistaken.
> 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
Hmm, so an combination of:
a) standard-conform: verify "to"/"cc" recipients against the current
user's _implicit_ alias lists, e.g. dict, external binary, or plain file;
here you can even do regex matching
b) non-standard-conform: add a ":accept-all-addresses" modifier to
vacation and let the user select on To/Cc adresses via if condition.
BTW: Splitting hair: IMHO sec 4.5/4.6 of RFC 5230 does not specify the
notation of an "address". So "@example.net" could be as valid as
"localpart@" or anything else.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the dovecot