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

On Mon, Mar 06, 2006 at 12:06:31AM +0100, Michael Haardt wrote:
> 
> 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.

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:

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.

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