-----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:
- 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?
- 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.
- 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)
- 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"
- 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"
- Adjust Deliver/Sieve to accept the original recipient as a separate parameter.
Looks like the same as 5), or am I mistaken.
- 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-----