On Sat, Mar 04, 2006 at 10:50:44PM -0800, Philip Guenther wrote:
I guess my concern is that generalizing the wording will make it less
precise and more difficult to understand. Currently there are some
fairly precise statements setting when :detail is or contains the empty
key; if this all becomes just a system-defined abstract query, how can
those requirements still be stated?
They can't, and I don't see why they should. If subaddressing would be
specified by any standard, things would be different, but it is not.
Trying to standardize subadressing by creating a sieve extension that
is able to process a (large, but still a) subset of what is possible
does not look right to me. If you want to define how subadressing
should work, for cleaning up the world-wide mess, then it should be
done outside the context of Sieve (perhaps as common best practice),
not by trying to set facts.
As it is, all kinds of subadressing are in use, and given the broad range
of possibilities, this extension almost certainly can not be used for all
of them. To begin with, it would only allow a single separator character
and suffix details. I showed some people use character sequences as
separator and some use the detail as prefix. Now the extension covers
those cases, but that does not mean it covers everything. That's why
I vote for a system-defined method of determining user and detail part.
To satisfy all needs, Exim sets the user and the detail part by generic
string expressions. I will not cripple that to specify a separator
and a matching direction, but using that flexibility to express more
is obviously a violation of the extension that requires user and detail
part to be substrings - not something I am glad about.
Please don't focus on VERP. I just quoted it because it was the first
application of subadressing not using substrings that came to my mind.
I am sure there is more, but I do not have a reference for crypted detail
parts or something like that.
Michael