1.\" $NetBSD: mailaddr.7,v 1.4 1997/03/08 14:10:39 mouse Exp $ 2.\" 3.\" Copyright (c) 1983, 1987, 1990, 1993 4.\" The Regents of the University of California. All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 3. All advertising materials mentioning features or use of this software 15.\" must display the following acknowledgement: 16.\" This product includes software developed by the University of 17.\" California, Berkeley and its contributors. 18.\" 4. Neither the name of the University nor the names of its contributors 19.\" may be used to endorse or promote products derived from this software 20.\" without specific prior written permission. 21.\" 22.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 23.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 24.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 25.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 26.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 27.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 28.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 29.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 30.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 31.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 32.\" SUCH DAMAGE. 33.\" 34.\" @(#)mailaddr.7 8.1 (Berkeley) 6/16/93 35.\" 36.Dd June 16, 1993 37.Dt MAILADDR 7 38.Os BSD 4.2 39.Sh NAME 40.Nm mailaddr 41.Nd mail addressing description 42.Sh DESCRIPTION 43Mail addresses are based on the Internet protocol listed at the end of this 44manual page. These addresses are in the general format 45.Pp 46.Dl user@domain 47.Pp 48where a domain is a hierarchical dot separated list of subdomains. For 49example, a valid address is: 50.Pp 51.Dl eric@CS.Berkeley.EDU 52.Pp 53Unlike some other forms of addressing, domains do not imply any routing. 54Thus, although this address is specified as an Internet address, it might 55travel by an alternative route if that were more convenient or efficient. 56For example, at Berkeley, the associated message would probably go directly 57to CS over the Ethernet rather than going via the Berkeley Internet 58gateway. 59.Ss Abbreviation. 60Under certain circumstances it may not be necessary to type the entire 61domain name. In general, anything following the first dot may be omitted 62if it is the same as the domain from which you are sending the message. 63For example, a user on ``calder.berkeley.edu'' could send to ``eric@CS'' 64without adding the ``berkeley.edu'' since it is the same on both sending 65and receiving hosts. 66.Ss Compatibility. 67.Pp 68Certain old address formats are converted to the new format to provide 69compatibility with the previous mail system. In particular, 70.Pp 71.Dl user@host 72.Pp 73and 74.Dl user@host.domain 75.Pp 76are allowed; 77.Pp 78.Dl host.domain!user 79.Pp 80is converted to 81.Pp 82.Dl user@host.domain 83.Pp 84and 85.Pp 86.Dl host!user 87.Pp 88is converted to 89.Pp 90.Dl user@host.UUCP 91.Pp 92This is normally converted back to the ``host!user'' form before being sent 93on for compatibility with older UUCP hosts. 94.Pp 95.Ss Case Distinctions. 96.Pp 97Domain names (i.e., anything after the ``@'' sign) may be given in any mixture 98of upper and lower case with the exception of UUCP hostnames. Most hosts 99accept any combination of case in user names, with the notable exception of 100MULTICS sites. 101.Ss Route-addrs. 102.Pp 103Under some circumstances it may be necessary to route a message through 104several hosts to get it to the final destination. Normally this routing 105is done automatically, but sometimes it is desirable to route the message 106manually. Addresses which show these relays are termed ``route-addrs.'' 107These use the syntax: 108.Pp 109.Dl <@hosta,@hostb:user@hostc> 110.Pp 111This specifies that the message should be sent to hosta, from there to hostb, 112and finally to hostc. This path is forced even if there is a more efficient 113path to hostc. 114.Pp 115Route-addrs occur frequently on return addresses, since these are generally 116augmented by the software at each host. It is generally possible to ignore 117all but the ``user@hostc'' part of the address to determine the actual 118sender. 119.Pp 120[Note: the route-addr syntax is officially deprecated 121in RFC 1123 and should not be used.] 122.Pp 123Many sites also support the ``percent hack'' for simplistic routing: 124.Pp 125.Dl user%hostc%hostb@hosta 126.Pp 127is routed as indicated in the previous example. 128.Ss Postmaster. 129.Pp 130Every site is required to have a user or user alias designated ``postmaster'' 131to which problems with the mail system may be addressed. 132.Ss Other Networks. 133.Pp 134Some other networks can be reached by giving the name of the network as the 135last component of the domain. 136.Em This is not a standard feature 137and may 138not be supported at all sites. For example, messages to CSNET or BITNET sites 139can often be sent to ``user@host.CSNET'' or ``user@host.BITNET'' respectively. 140.Sh SEE ALSO 141.Xr mail 1 , 142.Xr sendmail 8 ; 143.br 144Crocker, D. H., 145.Em Standard for the Format of Arpa Internet Text Messages, 146RFC822. 147.Sh HISTORY 148.Nm Mailaddr 149appeared in 4.2 BSD. 150.Sh BUGS 151The RFC822 group syntax (``group:user1,user2,user3;'') is not supported 152except in the special case of ``group:;'' because of a conflict with old 153berknet-style addresses. 154.Pp 155Route-Address syntax is grotty. 156.Pp 157UUCP- and Internet-style addresses do not coexist politely. 158