\begindata{text,538873300} \textdsversion{12} \template{help} \define{global } \chapter{The + symbol in Andrew mail addresses } \section{What is the +?} \leftindent{The + is a symbol that is recognized by the Andrew Message Delivery System (AMDS) and allows for a number of different types of local addresses. This file describes the kinds of local mail addresses that are understood by the AMDS. A "local mail address" is the mail addresses that may appear to the left of the ``@'' sign in addresses of the form localaddress@domain.name both for mail that originates on site and for mail that arrives from other computers. (For those familiar with RFC822, it describes how Andrew interprets what appears as a grammatical "local-part".) The domain name used as an example through this document is "andrew.cmu.edu". }\section{Types of mail addresses}\leftindent{ The AMS delivery system recognizes three broad classes of local mail addresses: personal names, userid forms, and special address types. These types are distinguished by their use of a special tag character, the plus sign ("+"). \bold{personal names.} Addresses without any plus signs are considered to be personal names. An example is "Jello.Biafra@andrew.cmu.edu" \bold{userid forms.} Addresses that do not start with a plus sign but have a plus sign embedded in them are considered to be userid forms. For backward compatibility with earlier versions of this scheme, addresses that do not start with a plus sign but have a hash mark ("#") embedded in them are also considered to be userid forms. An example is "jbRo+@andrew.cmu.edu". \bold{special addresses.} Addresses that start with an initial plus sign are considered to be special addresses. An example is "+dist+/afs/andrew/usr/jello/dlist.project@andrew.cmu.edu". }\section{Personal names}\leftindent{ Given a personal name form of mail address--an address without any plus signs or hash marks--the Andrew message delivery system determines how it is to be delivered by matching the given personal name against the collection of user (and Mailbox) names known to the system as published in the White Pages ( \italic{\helptopic{WP}} ) database. The White Pages matching algorithm is rule-driven and tries successively more general matches between the name and the published names, allowing for abbreviations, nicknames and misspellings. The unusual feature of this algorithm, though, is that it does not first check to see if the probe name matches one of the user IDs (login names) on the system. That is, even there is a user ID "jello" on Andrew, mail to the address "jello@andrew.cmu.edu" (a personal name form of mail address) is not guaranteed to reach that account, because there may be other matches for the name "jello" that have equal or greater priority to the match that is made to the set of user IDs. For example, if the Jello brothers Joe and Bob are granted accounts, then the address "jello@andrew.cmu.edu" would match each of them as strongly as it matches the user ID "jello". }\section{User ids}\leftindent{ Given a userid form of mail address -- an address without a leading plus sign but with an embedded plus sign or hash mark -- the Andrew message delivery determines how it is to be delivered by isolating the string to the left of the leftmost plus sign or hash mark and looking that string up in the set of user IDs (login names) known to the system. If that string matches a user ID, the mail is delivered to that account. The remainder of the local address is not used in determining the account to which the mail is delivered; instead, the recipient's mail reading program may choose to use the extra information, if any, in processing new mail. For example, you might ask that the address jbRo+recipes@andrew.cmu.edu be added to a mailing list that discusses dessert recipes, and a \italic{\helptopic{flames}} program (acting as a mail reader) might automatically classify mail that arrives for that address into a particular folder. Even if that full address does not appear in the header of the received piece of mail, the delivery system will include it in the "for" clause of a Received: line prepended to the mail on delivery, so that the mail reader can find it there.} \section{Special Addresses} \leftindent{Special addresses--an address that begins with a plus sign, and contains at least one more plus sign--are used to invoke mail delivery services other than delivery to an Andrew account. The string between the leading plus sign and the next plus sign is called the \bold{delivery kind}, and the string after that next plus sign is called the \bold{delivery parameter}. The delivery kind string must be one of a set of predefined code strings, and the interpretation of the delivery parameter then depends on which code string was matched. The following delivery kinds and their parameters are currently defined. \italic{\bold{dist } } The delivery parameter for the "dist" delivery kind is the name of a distribution list file; such a file is an ordinary text file that contains mail addresses and other information. Mail addressed to a distribution list (even by users off-site) is delivered to the addresses contained in the distribution list file. Distribution lists are described in detail in the \italic{\helptopic{dlists} } help file. For example, the address +dist+/afs/andrew/usr/jbRo/dists/test1.dl@andrew.cmu.edu is a distribution list used for testing. \bold{\italic{dir-insert } }The delivery parameter for the "dir-insert" kind is the name of an Andrew directory. Mail addressed to a dir-insert special address type is delivered by writing it as a new file to be inserted in the named directory, for which the System:AnyUser (anonymous) permissions are presumed to be adequate. For example, the address +dir-insert+/afs/andrew/usr/jbRo/Mailbox@andrew.cmu.edu puts a piece of mail in jbRo's ~/Mailbox directory, the same way that ordinarily-addressed mail is delivered, but the +dir-insert+ form does not look up the user by their account, so it does not check other attributes, such as mail forwarding. \bold{\italic{fs-members}} The delivery parameter for the "fs-members" delivery kind is the name of an \helptopic{AFS} group; such a group is created and maintained with the prs command and contains userids of accounts. Mail addressed to a file system group (even by users off-site) is delivered to the users names in the group. Groups are described in detail in the \italic{\helptopic{pts} } help file. For example, the address "+fs-members+pierette:mailmavens"@andrew.cmu.edu is a group whose members maintains the mail system. Please remember to quote the entire address (as above) if the groupname contains a colon (":") in it (most do). }\section{Special Address Architecture }\leftindent{ This architecture for special addresses is loosely based on a corresponding feature of RFC733, the special-atom types ":include:" and ":postal:". Unlike their RFC733 counterparts, which required implementation of their special treatment wherever they were used, these forms are expressed completely within the local-address parameter to mail delivery, and as such need be treated specially only in the specific delivery system to which they are addressed. This special address architecture is extensible, in the sense that new types may be added, locally, at any time. For example, mail to +filter+/aaa/bbb/ccc@andrew.cmu.edu might some day be piped to the standard input of the executable program /aaa/bbb/ccc, itself operating in some previously-specified, and probably unprivileged, environment. Mail to +file-append+/xxx/yyy/zzz@andrew.cmu.edu might some day be appended to the named file. Mail to +campus-mail+Joe_Student|UCC_506@andrew.cmu.edu might some day be printed and placed in the campus paper mail system addressed to Joe Student, UCC 506. This special address architecture is an improvement on the older styles of special addresses, which were usually unadorned file names, or file names with a special character at their beginnings or ends. For example, some mail systems interpret a local address that is simply a file name as a use of the named file as a distribution list; some systems interpret a name with an asterisk prepended as the name of a file to which the mail should be appended; some systems interpret a name with a vertical bar prepended as the name of a program to which the mail is to be piped; some systems interpret a name with an up-arrow appended as the name of a distribution list. In our system, every special address carries with it an initial type-tag; file names by themselves are not recognized as anything, so the user does not have to wonder whether a file name used as a mail destination will use the named file as a distribution list, or as a program through which to filter mail, or as a file to which to append the mail.}\leftindent{ }\section{Cannonical addresses }\leftindent{ Because the AMDS personal name matcher does not consider user ID matches to override all other matches (a positive feature given what remote or naive users expect it to do), it cannot keep one of the usual traditions of computer mail, which is that a user's canonical mail address is simply userid@machinename. That is, the system embodies the notion it is more important that users be able to establish initial contact with an Andrew mail recipient by addressing a piece of mail to the recipient's full name or surname, expecting that the mail will either be delivered to the desired person or rejected with an explanation, than it is to maintain the userid@machinename tradition. If the personal name matcher were to look for user ID matches first, then one of Joe Borax's friends on another system might try to send him mail with the address "borax@andrew.cmu.edu", but if there were a user id "borax" on the system (that was not Joe) it would be delivered to the userid "borax" rather than to Joe Borax, and neither Joe nor his friend would ever receive a warning from the delivery system. Given that, the Andrew Message delivery system allows two forms of canonical address: the personal name form, and the userid form: fullname@andrew.cmu.edu ("Joe.Borax@andrew.cmu.edu") userid+@andrew.cmu.edu ("jbRo+@andrew.cmu.edu") That is, either of these forms could be put in the From: header of mail composed by a user with the full expectation that replies directed to the contents of the From: header would be delivered to the initial message's author without error. The system uses the userid form of canonical address ("From: userid+@andrew.cmu.edu") in mail that it composes, rather than the fullname form, for several reasons. First, user IDs are guaranteed to be unique within our (large) system, and we do not expect that userids will be re-used as users leave the system and new users receive new accounts; these properties are not true of full personal names in our system. Second, suppose that a second Joe Borax applies for an account; what should the system use for his full name? If he has a middle name, that name or its initial might be used, making "Joe T. Borax". But does the first Joe Borax become "Joe R. Borax" to the system? If so, mail to the once-canonical address "Joe.Borax@andrew.cmu.edu" is now ambiguous. If not, then the system's name space expresses a preference for the first Joe Borax: if a user tries to contact the second Joe Borax by sending mail to "Joe.Borax@andrew.cmu.edu", the mail is delivered, without complaint, to the wrong person. } \section{Related tools} Select (highlight) one of the italicized names and choose "Show Help on Selected Word" from the pop-up menu to see the help document for: \leftindent{\italic{\helptopic{CUI} \helptopic{flames} \helptopic{mail} \helptopic{Messages} \helptopic{dlists} \helptopic{SendMessage} \helptopic{white-pages}} } \begindata{bp,537558784} \enddata{bp,537558784} \view{bpv,537558784,1513,0,0} Copyright 1992 Carnegie Mellon University and IBM. All rights reserved. \smaller{\smaller{$Disclaimer: Permission to use, copy, modify, and distribute this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice, this permission notice, and the following disclaimer appear in supporting documentation, and that the names of IBM, Carnegie Mellon University, and other copyright holders, not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. IBM, CARNEGIE MELLON UNIVERSITY, AND THE OTHER COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL IBM, CARNEGIE MELLON UNIVERSITY, OR ANY OTHER COPYRIGHT HOLDER BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. $ }}\enddata{text,538873300}