[Top] [All Lists]

Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt

2006-03-05 00:13:47

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.

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?

Philip Guenther

** As a footnote, VERP is _not_ an encoding but just the abstract idea
of using, well, Variable Envelope Return Paths.  The page that was
contains an example of a return-path that encodes an address, but it
does not actually provide anything like specification of an encoding.