+.\" Copyright (c) 1983, 1987, 1990 The Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\" must display the following acknowledgement:
+.\" This product includes software developed by the University of
+.\" California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\" may be used to endorse or promote products derived from this software
+.\" without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" @(#)mailaddr.7 6.6 (Berkeley) 6/24/90
+.\"
+.Dd June 24, 1990
+.Dt MAILADDR 7
+.Os BSD 4.2
+.Sh NAME
+.Nm mailaddr
+.Nd mail addressing description
+.Sh DESCRIPTION
+Mail addresses are based on the ARPANET protocol listed at the end of this
+manual page. These addresses are in the general format
+.Pp
+.Dl user@domain
+.Pp
+where a domain is a hierarchical dot separated list of subdomains. For
+example, the address
+.Pp
+.Dl eric@monet.berkeley.edu
+.Pp
+is normally interpreted from right to left: the message should go to the
+ARPA name tables (which do not correspond exactly to the physical ARPANET),
+then to the Berkeley gateway, after which it should go to the local host
+monet. When the message reaches monet it is delivered to the user ``eric''.
+.Pp
+Unlike some other forms of addressing, this does not imply any routing.
+Thus, although this address is specified as an ARPA address, it might
+travel by an alternate route if that were more convenient or efficient.
+For example, at Berkeley, the associated message would probably go directly
+to monet over the Ethernet rather than going via the Berkeley ARPANET
+gateway.
+.Ss Abbreviation.
+Under certain circumstances it may not be necessary to type the entire
+domain name. In general, anything following the first dot may be omitted
+if it is the same as the domain from which you are sending the message.
+For example, a user on ``calder.berkeley.edu'' could send to ``eric@monet''
+without adding the ``berkeley.edu'' since it is the same on both sending
+and receiving hosts.
+.Pp
+Certain other abbreviations may be permitted as special cases. For
+example, at Berkeley, ARPANET hosts may be referenced without adding
+the ``berkeley.edu'' as long as their names do not conflict with a local
+host name.
+.Ss Compatibility.
+.Pp
+Certain old address formats are converted to the new format to provide
+compatibility with the previous mail system. In particular,
+.Pp
+.Dl user@host.ARPA
+.Pp
+is allowed and
+.Pp
+.Dl host:user
+.Pp
+is converted to
+.Pp
+.Dl user@host
+.Pp
+to be consistent with the
+.Xr rcp 1
+command.
+.Pp
+Also, the syntax
+.Pp
+.Dl host!user
+.Pp
+is converted to:
+.Pp
+.Dl user@host.UUCP
+.Pp
+This is normally converted back to the ``host!user'' form before being sent
+on for compatibility with older UUCP hosts.
+.Pp
+The current implementation is not able to route messages automatically through
+the UUCP network. Until that time you must explicitly tell the mail system
+which hosts to send your message through to get to your final destination.
+.Ss Case Distinctions.
+.Pp
+Domain names (i.e., anything after the ``@'' sign) may be given in any mixture
+of upper and lower case with the exception of UUCP hostnames. Most hosts
+accept any combination of case in user names, with the notable exception of
+MULTICS sites.
+.Ss Route-addrs.
+.Pp
+Under some circumstances it may be necessary to route a message through
+several hosts to get it to the final destination. Normally this routing
+is done automatically, but sometimes it is desirable to route the message
+manually. Addresses which show these relays are termed ``route-addrs.''
+These use the syntax:
+.Pp
+.Dl <@hosta,@hostb:user@hostc>
+.Pp
+This specifies that the message should be sent to hosta, from there to hostb,
+and finally to hostc. This path is forced even if there is a more efficient
+path to hostc.
+.Pp
+Route-addrs occur frequently on return addresses, since these are generally
+augmented by the software at each host. It is generally possible to ignore
+all but the ``user@domain'' part of the address to determine the actual
+sender.
+.Ss Postmaster.
+.Pp
+Every site is required to have a user or user alias designated ``postmaster''
+to which problems with the mail system may be addressed.
+.Ss Other Networks.
+.Pp
+Some other networks can be reached by giving the name of the network as the
+last component of the domain.
+.Em This is not a standard feature
+and may
+not be supported at all sites. For example, messages to CSNET or BITNET sites
+can often be sent to ``user@host.CSNET'' or ``user@host.BITNET'' respectively.
+.Sh SEE ALSO
+.Xr mail 1 ,
+.Xr sendmail 8 ;
+.br
+Crocker, D. H.,
+.Em Standard for the Format of Arpa Internet Text Messages,
+RFC822.
+.Sh HISTORY
+.Nm Mailaddr
+appeared in 4.2 BSD.
+.Sh BUGS
+The RFC822 group syntax (``group:user1,user2,user3;'') is not supported
+except in the special case of ``group:;'' because of a conflict with old
+berknet-style addresses.
+.Pp
+Route-Address syntax is grotty.
+.Pp
+UUCP- and ARPANET-style addresses do not coexist politely.
projects / unix-history / commitdiff