Michael Haardt <michael(_at_)freenet-ag(_dot_)de> writes:
On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
...
I didn't think VERPs were an all-or-nothing choice. A user may send
some messages with VERP-style address and others with random tags in the
subaddress portion. Please explain how a system that 'decoded' VERPs
would support that.
Users usually do not send VERPs, but MLMs do. The system that runs
the MLM would be configured to know which bounces belong to the MLM,
and set up subaddressing to decode VERP. Mail that belongs to users
would be delivered with subaddressing set up as the local convention
for users is, i.e. <user+detail(_at_)domain>.
So, the use-case you have in mind for the requested flexibility would be
for sieve scripts running 'in front of' MLMs only? That's a pretty
specialized application.
I agree. I will also point out, again, that the VERP concept is distinct from
the specific encoding that's described, and may be MLM or even list specific.
It may make sense, for example, to incorporate some sort of keying mechanism to
prevent forged unsubscribes.
VERPs are a optional encoding inside the subaddress encoding, ergo
decoding of them should be separately performed or requested so that
access to both levels can be provided.
If you want ultimate configurability, indeed variables and string
expressions are needed. But all I ask for is making the subaddress
specification less restrictive on issues outsides its scope and change
it into an abstraction that simply queries an abstract user and detail
part, not caring about how they are formed.
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?
I'm afraid I have to agree. Breaking the local-part apart into pieces
is one thing, decoding any encoding in there is quite another.
If you want a different example, consider how you'd embed a non-ASCII folder
name in a subaddress. The situation surrounding IMAP's use of modified UTF-7 is
already enough of a mess without allowing for decoding to occur as
part of sieve subaddress handling.
Ned