[Top] [All Lists]

Re: Generalizing subaddress

2006-03-30 12:42:00

On Wed, 2006-03-29 at 18:35 -0800, Alexey Melnikov wrote:
Dave Cridland wrote:
On Fri Mar 24 00:25:37 2006, Ken Murchison wrote:
Perhaps what's actually needed is some kind of informational document 
describing various mechanisms that exist for subaddressing and similar 
local-part "encodings", and then using the subaddress Sieve extension 
to access those encodings.

Previous attempts to do this have failed (partially due to the help of 
DJB). I think Chris had a draft on this.

So I remain skeptical if the new effort is going to be more successful.

I first became aware of subaddressing in a bug posted to the DBMail bug
tracker by a user who wanted username+mailbox addressing to be delivered
to the right mailbox. It turned out to require a fairly invasive set of
changes to the way we were looking up valid user accounts. Getting the
mailbox spec passed along the delivery chain was less difficult.

The real issue that I see here is that the mail delivery agent has to
make a decision about whether or not an address refers to a user on the
system -- parsing the address as needed to find the local user account
-- and then the Sieve engine presents the parsed address to the script.

In the case of DBMail and libSieve, only the verbatim address is passed;
the two code bases happen to perform the same decoding. What we're
looking at, then, is a de-facto standard that both codebases adhere to.
If either side of that interface changes its decoding pattern, then it
all breaks down. If a user posts a patch to the DBMail bug tracker
providing support for some other subaddress format, then I would have to
put it on hold, saying, "This can't go in until I've rewritten the patch
for libSieve, otherwise you won't be able to use Sieve with this new
subaddress format."

Implicit in the Sieve subaddress draft is that there is a format of
either: userSEPdetail(_at_)domain or detailSEPuser(_at_)domain(_dot_) In 
database terms,
we would be violating "first normal form" if :user were further
internally formatted and required a regex to parse. It would also mean
explaining mail-system-internals to the script authors. Basically,
exactly what we're trying to prevent with this spec.

As I understand the debate to date, there are two questions holding
things up: more subaddress parts, and more complex, possibly nested,
encodings. I think I've seen the two-part-subaddress but
double-encoded-detail dismissed as being something the implementation
can handle already -- like username+=XYZ-BASE64-123=(_at_)domain(_dot_) That's 
to resolve, but probably should be treated more directly in the RFC.

Now then, there's the more and more complex patterns... my suggestion is
to accept a new fact:

1.  There is always a "user" part, which refers to an account
    in the email system.
2.  There might be a "detail" part.
3.  There might be a couple of detail parts.

We currently accept and act on facts 1 and 2. The proposals on 3 all
seem to have suggested adding more names; :detail, :mailbox, :voicemail,
whatever. The names are inherently specific to some interpretation of
the fields in the subaddress coding, thereby creating a standard, and
then putting us in need of writing that standard, which nobody wants to
do because there are so many systems already out there. How about this:

3A. :detail0 is an alias for :detail. :detail1, :detail2 ... :detailn
    refer to other parts of the subaddress; implementation defined,
    with common uses documented in an informal manner, just enough to
    give new implementors an idea of what's already out there.

Thanks for reading if you got this far! I hope that my suggested change
is well received. If not, forget that part and just remember that no
matter what the subaddressing scheme is, there has to be some agreement
between the email account lookup and the Sieve script about what parts
of the subaddress are what in the mail system, and that implies at least
a de-facto standard or contract of some kind among the codebases.


<Prev in Thread] Current Thread [Next in Thread>