xref: /netbsd-src/share/man/man7/mailaddr.7 (revision 1d7a94623f99c9e3518d84df1a0cd6ded8639589)

.\"	$NetBSD: mailaddr.7,v 1.14 2010/03/01 16:52:41 jruoho 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 June 16, 1998
.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 (now obsolete) forms of addressing, domains do not
imply any routing, or the existence of a particular host.
Simply because mail may be sent to ``user@somedomain.com'' does not imply
that there is any actual host named ``somedomain.com'', and does not
imply a particular routing of the message.
Routing is performed by Mail Transport Agents, such as
.Xr postfix 1 ,
based on policies set in the MTA's configuration.
.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.
Whether abbreviation is permitted depends on how your site is configured.
.Ss Case Distinctions
Domain names (i.e., anything after the ``@'' sign) may be given in any mixture
of upper and lower case.
Most hosts accept any combination of case in user names, although there
are exceptions.
.Ss Postmaster
Every site is required to have a user or user alias designated ``postmaster''
to which problems with the mail system may be addressed, for example:
.Pp
.Dl postmaster@CS.Berkeley.EDU
.Ss Obsolete Formats
Certain old address formats, such as UUCP ``bang path'' addresses,
explicitly routed internet addresses (so-called ``route-addrs'' and
the ``percent hack'') and others have been used historically.
All these addressing formats are now considered obsolete, and should no
longer be used.
.Pp
To some extent, MTAs attempt to provide backward compatibility
for these addressing forms, but in practice many of them no longer work.
Users should always use standard Internet style addresses.
.Sh SEE ALSO
.Xr mail 1
.Rs
.%R RFC
.%N 822
.%D August 1982
.%A D. H. Crocker
.%T "Standard for the Format of Arpa Internet Text Messages"
.Re
.Sh HISTORY
.Nm
appeared in
.Bx 4.2 .
.Sh BUGS
The RFC 822 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, not that anyone cares about either berknet or
group syntax style addresses any longer.