156 lines
5.7 KiB
Groff
156 lines
5.7 KiB
Groff
|
.\" Copyright (c) 1983, 1987, 1990, 1993
|
||
|
|
.\" 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 8.1 (Berkeley) 6/16/93
|
||
|
|
.\"
|
||
|
|
.Dd June 16, 1993
|
||
|
|
.Dt MAILADDR 7
|
||
|
|
.Os BSD 4.2
|
||
|
|
.Sh NAME
|
||
|
|
.Nm mailaddr
|
||
|
|
.Nd mail addressing description
|
||
|
|
.Sh DESCRIPTION
|
||
|
|
Mail addresses are based on the Internet 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, a valid address is:
|
||
|
|
.Pp
|
||
|
|
.Dl eric@CS.Berkeley.EDU
|
||
|
|
.Pp
|
||
|
|
Unlike some other forms of addressing, domains do not imply any routing.
|
||
|
|
Thus, although this address is specified as an Internet 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 CS over the Ethernet rather than going via the Berkeley Internet
|
||
|
|
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@CS''
|
||
|
|
without adding the ``berkeley.edu'' since it is the same on both sending
|
||
|
|
and receiving hosts.
|
||
|
|
.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
|
||
|
|
.Pp
|
||
|
|
and
|
||
|
|
.Dl user@host.domain
|
||
|
|
.Pp
|
||
|
|
are allowed;
|
||
|
|
.Pp
|
||
|
|
.Dl host.domain!user
|
||
|
|
.Pp
|
||
|
|
is converted to
|
||
|
|
.Pp
|
||
|
|
.Dl user@host.domain
|
||
|
|
.Pp
|
||
|
|
and
|
||
|
|
.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
|
||
|
|
.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@hostc'' part of the address to determine the actual
|
||
|
|
sender.
|
||
|
|
.Pp
|
||
|
|
[Note: the route-addr syntax is officially deprecated
|
||
|
|
in RFC 1123 and should not be used.]
|
||
|
|
.Pp
|
||
|
|
Many sites also support the ``percent hack'' for simplistic routing:
|
||
|
|
.Pp
|
||
|
|
.Dl user%hostc%hostb@hosta
|
||
|
|
.Pp
|
||
|
|
is routed as indicated in the previous example.
|
||
|
|
.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 Internet-style addresses do not coexist politely.
|