+++ /dev/null
-.\" $OpenBSD: mailaddr.7,v 1.16 2014/09/16 21:11:56 jmc Exp $
-.\" $NetBSD: mailaddr.7,v 1.3 1994/11/30 19:07:17 jtc Exp $
-.\"
-.\" 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. 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 $Mdocdate: September 16 2014 $
-.Dt MAILADDR 7
-.Os
-.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
-.Dq calder.berkeley.edu
-could send to
-.Dq eric@CS
-without adding the
-.Dq berkeley.edu
-since it is the same on both sending
-and receiving hosts.
-.Ss Compatibility
-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
-.Dq host!user
-form before being sent
-on for compatibility with older UUCP hosts.
-.Ss Case distinctions
-Domain names (i.e., anything after the
-.Dq @
-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
-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
-.Dq route-addrs .
-These use the syntax:
-.Pp
-.Dl <@hosta,@hostb:user@hostc>
-.Pp
-This specifies that the message should be sent to
-.Dq hosta ,
-from there to
-.Dq hostb ,
-and finally to
-.Dq hostc .
-This path is forced even if there is a more efficient
-path to
-.Dq 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
-.Dq 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
-.Dq percent hack
-for simplistic routing:
-.Pp
-.Dl user%hostc%hostb@hosta
-.Pp
-is routed as indicated in the previous example.
-.Ss Postmaster
-Every site is required to have a user or user alias designated
-.Dq postmaster
-to which problems with the mail system may be addressed.
-.Ss Other networks
-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
-.Dq user@host.CSNET
-or
-.Dq user@host.BITNET ,
-respectively.
-.Sh SEE ALSO
-.Xr mail 1 ,
-.Xr smtpd 8
-.Sh STANDARDS
-.Rs
-.%A P. Resnick
-.%D 2008
-.%R RFC 5322
-.%T Internet Message Format
-.Re
-.Sh HISTORY
-.Nm
-appeared in
-.Bx 4.2 .
-.Sh BUGS
-The RFC 5322 group syntax
-.Pq Dq group:user1,user2,user3;
-is not supported
-except in the special case of
-.Dq 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.