xref: /netbsd-src/share/man/man7/mailaddr.7 (revision 23c8222edbfb0f0932d88a8351d3a0cf817dfb9e)
1.\"	$NetBSD: mailaddr.7,v 1.13 2003/09/07 16:22:29 wiz 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. Neither the name of the University nor the names of its contributors
15.\"    may be used to endorse or promote products derived from this software
16.\"    without specific prior written permission.
17.\"
18.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
19.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
20.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
21.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
22.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
23.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
24.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
25.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
26.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
27.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28.\" SUCH DAMAGE.
29.\"
30.\"     @(#)mailaddr.7	8.1 (Berkeley) 6/16/93
31.\"
32.Dd June 16, 1998
33.Dt MAILADDR 7
34.Os
35.Sh NAME
36.Nm mailaddr
37.Nd mail addressing description
38.Sh DESCRIPTION
39Mail addresses are based on the Internet protocol listed at the end of this
40manual page.
41These addresses are in the general format
42.Pp
43.Dl user@domain
44.Pp
45where a domain is a hierarchical dot separated list of subdomains.
46For example, a valid address is:
47.Pp
48.Dl eric@CS.Berkeley.EDU
49.Pp
50Unlike some other (now obsolete) forms of addressing, domains do not
51imply any routing, or the existence of a particular host.
52Simply because mail may be sent to ``user@somedomain.com'' does not imply
53that there is any actual host named ``somedomain.com'', and does not
54imply a particular routing of the message.
55Routing is performed by Mail Transport Agents, such as
56.Xr sendmail 8 ,
57based on policies set in the MTA's configuration.
58.Ss Abbreviation
59Under certain circumstances it may not be necessary to type the entire
60domain name.
61In 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.
66Whether abbreviation is permitted depends on how your site is configured.
67.Ss Case Distinctions
68Domain names (i.e., anything after the ``@'' sign) may be given in any mixture
69of upper and lower case.
70Most hosts accept any combination of case in user names, although there
71are exceptions.
72.Ss Postmaster
73Every site is required to have a user or user alias designated ``postmaster''
74to which problems with the mail system may be addressed, for example:
75.Pp
76.Dl postmaster@CS.Berkeley.EDU
77.Ss Obsolete Formats
78Certain old address formats, such as UUCP ``bang path'' addresses,
79explicitly routed internet addresses (so-called ``route-addrs'' and
80the ``percent hack'') and others have been used historically.
81All these addressing formats are now considered obsolete, and should no
82longer be used.
83.Pp
84To some extent,
85.Xr sendmail 8
86(when running with normal configuration files) attempts to provide
87backward compatibility for these addressing forms, but in practice
88many of them no longer work.
89Users should always use standard Internet style addresses.
90.Sh SEE ALSO
91.Xr mail 1 ,
92.Xr sendmail 8
93.Rs
94.%R RFC
95.%N 822
96.%D August 1982
97.%A D. H. Crocker
98.%T "Standard for the Format of Arpa Internet Text Messages"
99.Re
100.Sh HISTORY
101.Nm
102appeared in
103.Bx 4.2 .
104.Sh BUGS
105The RFC 822 group syntax (``group:user1,user2,user3;'') is not supported
106except in the special case of ``group:;'' because of a conflict with old
107berknet-style addresses, not that anyone cares about either berknet or
108group syntax style addresses any longer.
109