[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt
On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
> My interpretation is that for that example address, the sieved handling
> mail for silverton.berkeley.edu would follow the qmail practice and
> split the localpart on the first '-', such that :user would specify
> 'djb' and :detail would specify 'sos-owner-God=heaven.af.mil'. If you
> disagree or desire otherwise, please describe the additional (or
> alternative) processing you're looking for.
You misunderstand me. The subaddress extension does not split addresses
on its own, but asks the underlying system to perform that operation,
and simply uses the results. It does not specify if prefix or suffix
strings are to be used, but relies on the underlying system to know
the local convention:
the mechanisms used to define and/or query the separator character
sequence and sub-part ordering used by the mail system are outside
the scope of this document.
And things are good that way.
Unfortunately, it says: The only algorithm the underlying system may
perform is to use a separator for splitting the address in parts.
I ask to be less restrictive and allow the underlying system to split
the addresses in whatever way someone may want to configure it.
> > Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> > and if you relaxed the encoding specification, Sieve could be
> > used to decode it. A filter in front of a MLM may be very useful.
> You're looking for a means in sieved to extract the address
> <God@xxxxxxxxxxxxx> from that address? If so, what combination of
> keyword arguments would do that? (What if _that_ address was a VERP?)
Yes. Using :detail should be allowed to do that. Let's not discuss
VERP, because as I said, it is a primitive encoding, but a great real
world example that shows substrings do not suffice.
> 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@domain>.
> 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.