![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to mailaddr.7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDTahoe / man / man7|
Return to mailaddr.7 CVS log | Up to [CSRG BSD Unix] / 43BSDTahoe / man / man7 |
1.1 root 1: .\" Copyright (c) 1983, 1987 Regents of the University of California.
2: .\" All rights reserved. The Berkeley software License Agreement
3: .\" specifies the terms and conditions for redistribution.
4: .\"
5: .\" @(#)mailaddr.7 6.4 (Berkeley) 7/27/87
6: .\"
7: .TH MAILADDR 7 "July 27, 1987"
8: .UC 5
9: .SH NAME
10: mailaddr \- mail addressing description
11: .SH DESCRIPTION
12: Mail addresses are based on the ARPANET protocol listed at the end of this
13: manual page. These addresses are in the general format
14: .PP
15: user@domain
16: .PP
17: where a domain is a hierarchical dot separated list of subdomains. For
18: example, the address
19: .PP
20: [email protected]
21: .PP
22: is normally interpreted from right to left: the message should go to the
23: ARPA name tables (which do not correspond exactly to the physical ARPANET),
24: then to the Berkeley gateway, after which it should go to the local host
25: monet. When the message reaches monet it is delivered to the user ``eric''.
26: .PP
27: Unlike some other forms of addressing, this does not imply any routing.
28: Thus, although this address is specified as an ARPA address, it might
29: travel by an alternate route if that were more convenient or efficient.
30: For example, at Berkeley, the associated message would probably go directly
31: to monet over the Ethernet rather than going via the Berkeley ARPANET
32: gateway.
33: .SS Abbreviation.
34: .PP
35: Under certain circumstances it may not be necessary to type the entire
36: domain name. In general, anything following the first dot may be omitted
37: if it is the same as the domain from which you are sending the message.
38: For example, a user on ``calder.berkeley.edu'' could send to ``eric@monet''
39: without adding the ``berkeley.edu'' since it is the same on both sending
40: and receiving hosts.
41: .PP
42: Certain other abbreviations may be permitted as special cases. For
43: example, at Berkeley, ARPANET hosts may be referenced without adding
44: the ``berkeley.edu'' as long as their names do not conflict with a local
45: host name.
46: .SS Compatibility.
47: .PP
48: Certain old address formats are converted to the new format to provide
49: compatibility with the previous mail system. In particular,
50: .PP
51: [email protected]
52: .PP
53: is allowed and
54: .PP
55: host:user
56: .PP
57: is converted to
58: .PP
59: user@host
60: .PP
61: to be consistent with the \fIrcp\fP(1) command.
62: .PP
63: Also, the syntax
64: .PP
65: host!user
66: .PP
67: is converted to:
68: .PP
69: [email protected]
70: .PP
71: This is normally converted back to the ``host!user'' form before being sent
72: on for compatibility with older UUCP hosts.
73: .PP
74: The current implementation is not able to route messages automatically through
75: the UUCP network. Until that time you must explicitly tell the mail system
76: which hosts to send your message through to get to your final destination.
77: .SS Case Distinctions.
78: .PP
79: Domain names (i.e., anything after the ``@'' sign) may be given in any mixture
80: of upper and lower case with the exception of UUCP hostnames. Most hosts
81: accept any combination of case in user names, with the notable exception of
82: MULTICS sites.
83: .SS Route-addrs.
84: .PP
85: Under some circumstances it may be necessary to route a message through
86: several hosts to get it to the final destination. Normally this routing
87: is done automatically, but sometimes it is desirable to route the message
88: manually. Addresses which show these relays are termed ``route-addrs.''
89: These use the syntax:
90: .PP
91: <@hosta,@hostb:user@hostc>
92: .PP
93: This specifies that the message should be sent to hosta, from there to hostb,
94: and finally to hostc. This path is forced even if there is a more efficient
95: path to hostc.
96: .PP
97: Route-addrs occur frequently on return addresses, since these are generally
98: augmented by the software at each host. It is generally possible to ignore
99: all but the ``user@domain'' part of the address to determine the actual
100: sender.
101: .SS Postmaster.
102: .PP
103: Every site is required to have a user or user alias designated ``postmaster''
104: to which problems with the mail system may be addressed.
105: .SS Other Networks.
106: .PP
107: Some other networks can be reached by giving the name of the network as the
108: last component of the domain. \fIThis is not a standard feature\fP and may
109: not be supported at all sites. For example, messages to CSNET or BITNET sites
110: can often be sent to ``[email protected]'' or ``[email protected]'' respectively.
111: .SH BUGS
112: The RFC822 group syntax (``group:user1,user2,user3;'') is not supported
113: except in the special case of ``group:;'' because of a conflict with old
114: berknet-style addresses.
115: .PP
116: Route-Address syntax is grotty.
117: .PP
118: UUCP- and ARPANET-style addresses do not coexist politely.
119: .SH SEE ALSO
120: mail(1), sendmail(8);
121: Crocker, D. H.,
122: .ul
123: Standard for the Format of Arpa Internet Text Messages,
124: RFC822.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.