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