LDAP-based Routing of SMTP Messages: Approach at Stanford University
draft-ietf-asid-email-routing-su-00
| Document | Type |
Expired Internet-Draft
(asid WG)
Expired & archived
|
|
|---|---|---|---|
| Authors | Jeff Hodges , Booker C. Bense | ||
| Last updated | 1997-03-27 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The 'Internet X.500 Schema' defines an RFC-822 email address attribute of a person's entry, rfc822Mailbox (aka 'Mail'), but it does not address the issues involved in routing RFC-822-based email within an administrative domain served by an X.500/LDAP-based directory service. Significantly, it doesn't delineate between a person's publicaly 'advertised' or 'promoted' email address and the actual 'internal to the administrative domain' address for the person. This memo illustrates an object class and an attendant attribute we use at Stanford University to solve this issue. This scheme provides us with flexible, simple to implement, distributed routing of RFC-822-based email to people represented by entries within our directory service. The LDAP-enabled version of sendmail we use is freely available. Additionally, we anticipate that the Internet community will devise conventions and perhaps support a process for facilitating multi-vendor directory utilization. We present an anticipated tenet and goals.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)