1.\" $NetBSD: mailaddr.7,v 1.14 2010/03/01 16:52:41 jruoho 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 postfix 1 , 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, MTAs attempt to provide backward compatibility 85for these addressing forms, but in practice many of them no longer work. 86Users should always use standard Internet style addresses. 87.Sh SEE ALSO 88.Xr mail 1 89.Rs 90.%R RFC 91.%N 822 92.%D August 1982 93.%A D. H. Crocker 94.%T "Standard for the Format of Arpa Internet Text Messages" 95.Re 96.Sh HISTORY 97.Nm 98appeared in 99.Bx 4.2 . 100.Sh BUGS 101The RFC 822 group syntax (``group:user1,user2,user3;'') is not supported 102except in the special case of ``group:;'' because of a conflict with old 103berknet-style addresses, not that anyone cares about either berknet or 104group syntax style addresses any longer. 105