Re: Email Subaddressing

[Bart Schaefer <[e-mail]>]

On Aug 1, 10:15pm, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} > The one and only rule that
} > is necessary is that the primary address always identifies the same
} > entity regardless of what subaddress is attached.
} 
} What does this mean? What is an ``entity''?

It doesn't matter what an entity is.  An entity is whatever the local-part
would refer to if the subaddress were ignored.  Could be a user account,
could be an alias, could be anything.  Up to the interpreting domain.

} Why is this rule necessary?

So that new subaddresses can be created without having to create new
primary addresses.  Without that rule, all you have is flat aliasing.
It's certainly possible to implement equivalent behavior by using flat
aliasing, but then you need rules to prevent name collisions.

} More importantly, that rule is inconsistent with reality. There are
} a+b@host and a+c@host addresses that are _not_ the same entity.

Note that I avoided saying what the separator character is.  But it
really doesn't matter; if a domain that already has a+b and a+c local-
parts wants to begin using "+" as a subaddress separator, it can set up
a psuedo-user "a" whose only purpose is to redirect mail for the "a+b"
and "a+c" local-parts to the right real places.  Nobody outside that
domain should be counting on the final interpretation of "a+b" and "a+c".
The idea is that entities *inside* the domain can count on it, *if* the
domain claims to support subaddressing.

} > I've been asking for alternatives, but the only
} > suggestion so far is that we throw away combinations of agents that
} > don't already understand one another.  Not very helpful either to those
} > who'd like to change existing agents to be able to understand, nor to
} > those who want to write new agents.
} 
} On the contrary. Someone who wants to write (e.g.) a UNIX delivery agent
} that supports qmail's address hierarchy simply has to use the variables
} supplied by qmail-local: LOCAL, USER, EXT, EXT2, EXT3, etc.

That's wonderful if all I want to write is a new agent that interoperates
with qmail and other qmail agents.  What if I want to write an agent that
I can expect to interoperate with any of a large number of other MTAs and
LDAs or submission agents?  Are you going to convince Netscape and MS and
Software.com and Innosoft etc. all to adopt your scheme on all platforms
they support?

This discussion has now reached the point of arguing only for the sake of
arguing, so I'm bailing out until some other people have had a say.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com