Mark Horton wrote:
...
(1) Deliver atom(_at_)lucent(_dot_)com by looking it up in the directory,
and delivering to the physical address found in the directory.
(2) Pass directory(_dot_)query(_at_)lucent(_dot_)com (anything with syntax
containing
dot, equals, slash, colon, or underscore, followed by @lucent.com) to the
directory lookup to match one or more possible people and deliver to
their physical addresses.
...
What it does require, if you're going to use standards-based components,
then the LDAP client (MTA) and LDAP server have to agree on a few things.
Most notably, they must agree on two standard attributes: the high-level
user-visible mail address (such as "mark(_at_)lucent(_dot_)com") and the
physical
address specifying the mail server
("mark(_at_)clipper(_dot_)cb(_dot_)lucent(_dot_)com")
The job of the MTA, even in the simplest case (1 above) is to take a
high-level name, look it up in the directory, and get back the physical
address so it can route the mail there. For example, the first could be
called "mail" and the second "MailForwardingAddress". Or it could look
for attribute "id" value "mark", and still return a MailForwardingAddress.
At a bare minimum, we need to agree on these two attributes.
I agree that this would be the bare minimum to standardize
(if any of this is standardized at all). This would allow different
vendors' MTAs within an organization to do direct routing to each
other, as least for case (1). Some vendors might still want to
implement different approaches for whatever reason, but I think
there's value in trying to standardize this at some level.
The 'mail' attribute seems to be the choice for the high-level
user-visible address. As for the physical delivery address, I'd
rather not use 'mailForwardingAddress' since we're already using
that for "forwarding" (one account forwarding its mail to one or
more other accounts; typically user-controlled, like the ".forward"
file), which we consider to be different from "routing" (getting
the mail to the account in question; typically administrator-
controlled, like putting routing aliases in the sendmail aliases file).
For "routing" we have an attribute called 'mailRoutingAddress'.
Our MTA expects that this contains the physical delivery address
(although it's optional if 'mailHost' is set, since we can route
based on that).
For case (2) it may be a little harder to get consensus among
MTA vendors. Regarding doing address matching against the 'cn'
attribute, we instead provide an attribute 'mailAlternateAddress'
to explicitly set the user's additional email addresses (beyond
the one in their 'mail' attribute). This makes uniqueness checking
fairly easy, and also avoids "unexpected loss of service" cases due
to someone else getting the same 'cn'. I understand this was a
problem in some places that had something like the 'cn' matching
functionality.
By the way, the L.A. IETF meeting is coming up. If you (or anyone
else interested in this) are going, maybe we should find a way to
hook up.
-- Hans