Minutes, Reported by Ned Freed:

The purpose of this effort is to standardize a mechanism for routing local
mail using LDAP.  Currently there is no standard schema for this purpose.

Hans Lachman presented an overview of how Netscape does this
(draft-lachman-ldap-mail-routing-03.txt).  Additional attributes are added to
a user's LDAP entry.  mailRecipient is the object class, the single-valued
mail attribute gives the user's address and the single-valued mailHost
attribute gives the host the mail is to be routed to.  The multi-valued
mailAlternateAddress can be used to specify additional addresses the user
uses to receive mail.  mailRoutingAddress optionally gives a new address the
mailrouting process changes the envelope recipient address to.  This last
attribute was added to deal with situations where some agents demand some
peculiar sort of envelope recipient address.

Daryl Huff presented an overview of how Sun does this.  inetMailRouting is
the name of their object class.  mail is the user's email address attribute
and mailHost is the host name of the user's mail server.  Both of these are
required.  An optional attribute, rfc822MailAlias gives alternate addresses
the user uses to receive mail (same as mailAlternateAddress in Netscape's
scheme).  There is no equivalent of mailRoutingAddress in the Sun scheme.
This is all used in conjunction with the inetOrgPerson object class for users
and groupOfUniqueNames for aliases and distribution lists, neither of which
are being considered in this BOF.

Jeff Hodges presented the approach used at Stanford.  Given
"local-part@domain", the lookup is done on "local-part".  A very complex
naming scheme is used.  The attribute looked up is seasSunetId.  On a match,
the attribute mailDrop gives the new address to route the mail to.  Uses the
mail attribute to advertise the email address.

Chris Newman asserted that the goal here should be to come up with a single,
standardized mail routing mechanism.  A hum-poll of the room indicated strong
support for this.

Jeff Hodges asserted that mail routing should be independent of the mail
attribute.

Bob Morgan noted that their design at Stanford is being changed to accommodate
multiple ids.

A suggestion was made that whatever system that is adopted be capable of
handling multiple advertised addresses and that these addresses not be limited
to RFC822.  Ned Freed disagreed strongly with the latter part of this.

Further discussion ensued, at which point Chris Newman claimed that this
sufficed to identify a rat-hole and that how to advertise a user's address be
placed out of scope.  Daryl Huff agreed that the scope should be limited in
this way.

John Beck conducted a straw poll: Should the scope initially be kept narrow
and focused on local routing only, with possible expansion to other topics
later, or should it be wide to begin with?  There was a clear consensus that
the former is the right approach.

Another poll: Should this go to a design team or should we go for a WG now?
There was no consensus on this point.  It was then suggested that the design
team be tried first, and if that fails...

A final poll: Is anyone interested in working on a general inbox schema?  If
there are lots of people interested they didn't appear to be in the room...