[Dovecot] simple steps with sieve

[Steffen Kaiser]

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

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 
addresses.

Dunno how a dict can be working internally, but can Dovecot dicts perform 
wildcard checks?

> 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).

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 
> parameter.

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 
> standard.

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

and

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.

Regards,

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

iQEVAwUBSuggbHWSIuGy1ktrAQJ4cggAhAXOHHv1fiDxON7hbnr2j6PDMo9t0odK
dxTtGLOI6UXMsFEOv6Tx/3cnMfxJF7viaC7NCH5YYmKkCjDRm0DkMBqNnIkpMFfF
XyzZCUa9FYTEYLjDtFPQtJrkVeh3YUueTxhw0ZvkWSh5he/Y5R0vA5i1PLJyP2uk
F4hF1+894bzXWwaLR1chv3BEQQkzKY5W82L5TY2R8bSIej+SQFDouJflbHi/oM9F
Hrjg2ezbRVqSj4nnmNwReHQnajAUW/QnE0VRl/cncW7svxmMMJhiXe22kZw+/VWy
nthaci7sUW17toy8VY5cPIU66oEqo8ILGUG+IbVveKMau/NdRMic0A==
=knhz
-----END PGP SIGNATURE-----