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

From: Michael Haardt <[email-masked]>
Date: Fri, 3 Mar 2006 15:14:39 +0100

On Fri, Feb 17, 2006 at 03:50:01PM -0500, [email-masked] wrote:
> 	Title		: Sieve Email Filtering -- Subaddress Extension
> 	Author(s)	: K. Murchison
> 	Filename	: draft-ietf-sieve-rfc3598bis-02.txt
> 	Pages		: 14
> 	Date		: 2006-2-17

This draft allows both prefix and suffix encoding, but still requires
both user and detail part to be substrings of the local part.

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.

Michael

---

From: Ned Freed <[email-masked]>
Date: Fri, 03 Mar 2006 09:03:05 -0800 (PST)

> used to decode it.  A filter in front of a MLM may be very useful.

I fail to see the mismatch. In a VERP scheme the user part tells you the name
of the list whie the detail part tells you the address that failed.

I suppose you could also use subdomains to encode some of this information
(VERP is an approach, not a particular encoding), but that's not how it is
normally done.

				Ned

---

From: Michael Haardt <[email-masked]>
Date: Fri, 3 Mar 2006 20:17:18 +0100

> of the list whie the detail part tells you the address that failed.

Quoting DJB:

   Here is how VERPs work: each recipient of the message sees a
   different envelope sender address. When a message to the
   [email-masked] mailing list is sent to
   [email-masked], for example, it has the following envelope sender:

      djb-sos-owner-God=[email-masked]

The "@" in the list member is replaced by "=".  A very primitive encoding,
but an encoding, whereas the subaddress draft requires substrings.

To me, a subaddress is additional information encoded in the address.
We already recognized that in general, subaddress decoding can only
be done by receiving system for its own addresses.  If that involves
splitting strings, translating characters or performing cryptographic
operations, should not be of any concern to the extension that allows
access to the decoded user and detail part.

Michael

---

From: Philip Guenther <[email-masked]>
Date: Fri, 03 Mar 2006 12:24:14 -0800

Michael Haardt <[email-masked]> writes:
...
>but an encoding, whereas the subaddress draft requires substrings.

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.

<from a previous message>
> 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
<[email-masked]> from that address?  If so, what combination of
keyword arguments would do that?  (What if _that_ address was a VERP?)

Note that you can already extract that address using variables.  Doing
so requires knowledge of what prefixes should be stripped ala
"sos-owner-" in this case.  And no, you can't strip on the last '-'
before the '=' as the wrapped address may have a '-' in its localpart.

>access to the decoded user and detail part.

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.

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.

Philip Guenther

---

From: Michael Haardt <[email-masked]>
Date: Sat, 4 Mar 2006 11:56:36 +0100

> 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.

> 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.

> subaddress portion.  Please explain how a system that 'decoded' VERPs

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>.

> 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

---

From: Philip Guenther <[email-masked]>
Date: Sat, 04 Mar 2006 22:50:44 -0800

...
>for users is, i.e. <user+detail@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.

>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
cited:
	http://cr.yp.to/proto/verp.txt
contains an example of a return-path that encodes an address, but it
does not actually provide anything like specification of an encoding.

---

From: Ned Freed <[email-masked]>
Date: Sun, 05 Mar 2006 08:25:40 -0800 (PST)

> for sieve scripts running 'in front of' MLMs only?  That's a pretty

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.

> 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

---

From: Michael Haardt <[email-masked]>
Date: Mon, 6 Mar 2006 00:06:31 +0100

> 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

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 7 Mar 2006 16:36:58 -0500

> I vote for a system-defined method of determining user and detail part.

Me too.. I think the functionality of this extension is diminished by
specifying particular syntaxes of user and detail.  After all, it seems
to me that one thing this extension is trying to do is remove knowledge
of those syntax details from the script writer; this becomes more useful
with less simplistic localpart formations.

I think it's fine if the spec focuses on a couple of different styles of
subaddressing for the purposes of explanation and exposition.  But I
don't really know why you'd want to mandate whatever we can think up at
the moment as being the only ways addresses can be extended.  The
interpretation of the localpart is best left up to any implementation,
and not just in the ways that we know of now.

I could imagine having hashed addresses:  let's say
"b0359d533e48623bae1d2dad9f2aedc4" corresponds to mem-foo .  Or perhaps
"nfmoioesoee" would be mem-foo with some noise thrown in.  Seems to me
that a subaddress extension would be much more useful to these cases
than for the simple substring/separator cases being discussed (since
difficult uses better illustrate how the extension removes the burden of
decoding them from the user, and leaves it to the implementation).

While I'm here, re this comment upthread:

> alternative) processing you're looking for.

This brings up the fact that there are already user/detail formations
out there that are not as simplistic as they might appear.  qmail
actually doesn't split on the first '-' or whatever character is in use.
It splits according to one of its control files that allows the base
"user" and detail parts to be determined.  In a default installation the
hyphen separates the two, but you can't just look for the first one.  A
base user part can be "mem-of-nh" and it's completely legitimate to have
a detail of "for-my-house" with "mem-of-nh-for-my-house" being the
complete localpart.

One might think that you could look for the final recipient address in
that string, but not with any great reliability- the base user part in
the string does not have to be the same as the one that is delivered to.

Also, the user control file can (in effect) specify different
user/detail separator strings per user or even per detail per user.
It's not common for different separators for different users in a qmail
environment, but it's possible and it's done now and then.

Having done the basic split, qmail will look for subdetail splits in the
suffix, using a hardwired separator character, usually hyphen.  (I think
I have mentioned in the past that having only one detail level doesn't
completely satisfy there as it's common to use subdetail delegation.)  A
user part of "mem" could have different separator and detail formats
including "mem-first" and "mem..second" and "mem+third" .  (Or, indeed,
"mem-sieve" and "mem..sieve" and "mem+sieve" all of which are
different.)  Just to be clear, I'm not talking about aliases: I'm
talking about a particular user being able to use any detail string
using those formats.)

mm