ietf-mta-filters
[Top] [All Lists]

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

2006-03-04 04:16:02

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:

   Note that
   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(_at_)heaven(_dot_)af(_dot_)mil> 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(_at_)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.

Michael