1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
<pre>Network Working Group A. Cargille
Request for Comments: 1648 University of Wisconsin
Category: Standards Track July 1994
<span class="h1">Postmaster Convention for X.400 Operations</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
Both STD 11, <a href="./rfc822">RFC 822</a> [<a href="#ref-1" title=""Standard of the Format of ARPA Internet Text Messages"">1</a>] and STD 3, <a href="./rfc1123">RFC 1123</a> [<a href="#ref-2" title=""Requirements for Internet Hosts -- Application and Support"">2</a>] (Host Requirements)
require that the email address "postmaster" be supported at all
hosts. This paper extends this concept to X.400 mail domains which
have registered <a href="./rfc1327">RFC 1327</a> mapping rules, and which therefore appear to
have normal <a href="./rfc822">RFC822</a>-style addresses.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Postmaster Convention in <a href="./rfc822">RFC822</a></span>
Operating a reliable, large-scale electronic mail (email) network
requires cooperation between many mail managers and system
administrators. As noted in <a href="./rfc822">RFC 822</a> [<a href="#ref-1" title=""Standard of the Format of ARPA Internet Text Messages"">1</a>], often mail or system
managers need to be able to contact a responsible person at a remote
host without knowing any specific user name or address at that host.
For that reason, both <a href="./rfc822">RFC 822</a> and the Internet Host Requirements [<a href="#ref-2" title=""Requirements for Internet Hosts -- Application and Support"">2</a>]
require that the address "postmaster" be supported at every Internet
host.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Postmaster Convention and X.400</span>
However, <a href="./rfc822">RFC 822</a> is not the only email protocol being used in the
Internet. Some Internet sites are also running the X.400 (1984) [<a href="#ref-3" title=""CCITT Recommendations X.400"">3</a>]
and X.400 (1988) [<a href="#ref-4" title=""CCITT Recommendations X.400/ ISO IS 10021-1"">4</a>] email protocols. <a href="./rfc1327">RFC 1327</a> specifies how to map
between X.400 and <a href="./rfc822">RFC 822</a> addresses [<a href="#ref-5" title=""Mapping between X.400(1988) / ISO 10021 and RFC 822"">5</a>]. When mapping rules are
used, addresses map cleanly between X.400 and <a href="./rfc822">RFC 822</a>. In fact, it
is impossible to determine by inspecting the address whether the
recipient is an <a href="./rfc822">RFC 822</a> mail user or an X.400 mail user.
A paper by Rob Hagens and Alf Hansen describes an X.400 community
known as the "Global Open MHS Community" (GO-MHS) [<a href="#ref-6" title=""Operational Requirements for X.400 Management Domains in the GO-MHS Community,"">6</a>]. Many mail
domains in the GO-MHS Community have registered <a href="./rfc1327">RFC 1327</a> mapping
rules. Therefore, users in those domains have <a href="./rfc822">RFC 822</a>-style email
<span class="grey">Cargille [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1648">RFC 1648</a> X.400 Postmaster Convention July 1994</span>
addresses, and these email domains are a logical extension of the <a href="./rfc822">RFC</a>
<a href="./rfc822">822</a> Internet. It is impossible to tell by inspecting a user's
address whether the user receives <a href="./rfc822">RFC 822</a> mail or X.400 mail.
Since these addresses appear to be standard <a href="./rfc822">RFC 822</a> addresses, mail
managers, mailing list managers, host administrators, and users
expect to be able to simply send mail to "postmaster@domain" and
having the message be delivered to a responsible party. When an <a href="./rfc1327">RFC</a>
<a href="./rfc1327">1327</a> mapping rule exists, the X.400 address element corresponding to
the left-hand-side "postmaster" is "Surname=Postmaster" (both 1984
and 1988). However, neither the X.400 protocols, North America X.400
Implementor's Agreements [<a href="#ref-7" title="National Institute of Standards and Technology">7</a>], nor the other regional X.400
implementor's agreements require that "Surname=Postmaster" and
"CommonName=Postmaster" be supported. (Supporting these addresses is
recommended in X.400 (1988)).
For mapped X.400 domains which do not support the postmaster
address(es), this means that an address such as "user@some.place.zz"
might be valid, yet mail to the corresponding address
"postmaster@some.place.zz" fails. This is frustrating for remote
administrators and users, and can prevent operational problems from
being communicated and resolved. In this case, the desired seamless
integration of the Internet <a href="./rfc822">RFC 822</a> mail world and the mapped X.400
domain has not been achieved.
The X.400 mail managers participating in the Cosine MHS Project
discussed this problem in a meeting in June 1992 [<a href="#ref-8" title="June 1992">8</a>]. The discussion
recognized the need for supporting the postmaster address at any
level of the address hierarchy where these are user addresses.
However, the group only required supporting the postmaster address
down to certain levels of the O/R Address tree. This approach solved
part of the problem, but not all of it. A more complete solution is
required.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Proposed Solution</span>
To fully achieve the desired seamless integration of email domains
for which <a href="./rfc1327">RFC 1327</a> mapping rules have been defined, the following
convention must be followed,
If there are any valid addresses of the form "user@domain", then
the address "postmaster@domain" must also be valid.
To express this in terms of X.400: For every X.400 domain for which
an <a href="./rfc1327">RFC 1327</a> mapping rule exists, if any address of the form
Surname=User; <Other X.400 Address Elements>
<span class="grey">Cargille [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1648">RFC 1648</a> X.400 Postmaster Convention July 1994</span>
is a valid address, then the address
Surname=Postmaster; <Same X.400 Address Elements>
must also be a valid address. If the X.400 system is running
X.400(1988), then the address
CommonName=Postmaster; <Same X.400 Address Elements>
must also be supported. (Note that CommonName=Postmaster will not be
generated by <a href="./rfc1327">RFC 1327</a> mappings, but it is recommended in the 1988
X.400 standard).
To remain consistent with <a href="./rfc822">RFC 822</a>, "Mail sent to that address is to
be routed to a person responsible for the site's mail system or to a
person with responsibility for general site operation." [<a href="#ref-9" title=""Standard of the Format of ARPA Internet Text Messages"">9</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Software Limitations</span>
If software is unable to support this requirement, it should be
upgraded. X.400 software developers are strongly encouraged and
requested to support forwarding mail to a centralized postmaster
mailbox in products.
It may be possible to support forwarding postmaster mail to a central
mailbox in software packages which do not explicitly support it by
applying work-around solutions. For example, some packages support
creating a mailing list for "postmaster" which has one entry that
points to the desired centralized postmaster mailbox. Alternatively,
it may be possible to support a postmaster address using the X.400
Autoforwarding feature. The software package may also support
rewriting the address in some other way.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Acknowledgements</span>
This document is a product of discussion and comments from the IETF
OSI X.400 Operations Working Group. Helpful input was also received
from the European MHS Managers. Special thanks to Marko Kaittola and
Erik Lawaetz for good criticism and helpful discussion.
Security Considerations
Security issues are not discussed in this memo.
<span class="grey">Cargille [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1648">RFC 1648</a> X.400 Postmaster Convention July 1994</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Author's Address</span>
Allan Cargille
Associate Researcher
Computer Sciences Department
University of Wisconsin-Madison
1210 West Dayton Street
Madison, WI 53706 USA
Internet: cargille@cs.wisc.edu
X.400: S=Cargille; O=UW-Madison; OU1=cs; PRMD=xnren; ADMD= ; C=us;
Phone: +1 (608) 262-5084
Fax: +1 (608) 262-9777
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
[<a id="ref-1">1</a>] Crocker, D., "Standard of the Format of ARPA Internet Text
Messages", STD 11, <a href="./rfc822">RFC 822</a>, UDEL, August 1982.
[<a id="ref-2">2</a>] Braden, R., "Requirements for Internet Hosts -- Application and
Support", STD 3, <a href="./rfc1123">RFC 1123</a>, USC/Information Sciences Institute,
October 1989.
[<a id="ref-3">3</a>] CCITT, "CCITT Recommendations X.400", Message Handling Systems:
System Model--Service Elements, 1984.
[<a id="ref-4">4</a>] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1", Message
Handling: System and Service Overview, December 1988.
[<a id="ref-5">5</a>] Kille, S., "Mapping between X.400(1988) / ISO 10021 and <a href="./rfc822">RFC 822</a>",
<a href="./rfc1327">RFC 1327</a>, University College London, May 1992.
[<a id="ref-6">6</a>] Hagens, R. and A. Hansen, "Operational Requirements for X.400
Management Domains in the GO-MHS Community," ANS, UNINETT, <a href="./rfc1649">RFC</a>
<a href="./rfc1649">1649</a>, July 1994.
[<a id="ref-7">7</a>] U.S. Department of Commerce, National Institute of Standards and
Technology, Stable Implementation Agreements for Open Systems
Interconnection Protocols, Version 7, Edition 1, Special
Publication 500-214, December 1993.
[<a id="ref-8">8</a>] Minutes, Cosine MHS Managers Meeting, June 1992, (unpublished).
[<a id="ref-9">9</a>] Crocker, D., "Standard of the Format of ARPA Internet Text
Messages", STD 11, <a href="./rfc822">RFC 822</a>, UDEL, Pg. 33, August 1982.
Cargille [Page 4]
</pre>
|
