1 |
<?xml version="1.0" encoding="iso-2022-jp"?> |
2 |
<!DOCTYPE rfc [ |
3 |
<!ENTITY rfc.number "799"> |
4 |
<!ENTITY ja.address " address "> |
5 |
<!ENTITY ja.cache " cache "> |
6 |
<!ENTITY ja.community "$B@$4V(B"> |
7 |
<!ENTITY ja.convention "$B6(Dj(B"> |
8 |
<!ENTITY ja.dis-ambiguate " dis-ambiguate "> |
9 |
<!ENTITY ja.field "$BMs(B"> |
10 |
<!ENTITY ja.internet " internet "> |
11 |
<!ENTITY ja.internet-address " internet &ja.address;"> |
12 |
<!ENTITY ja.internet-system " internet $BBN7O(B"> |
13 |
<!ENTITY ja.model "$B%b%G%k(B"> |
14 |
<!ENTITY ja.multi-home " multi-home "> |
15 |
<!ENTITY ja.protocol "$B%W%m%H%3%k(B"> |
16 |
<!ENTITY ja.system "$B=hM}7O(B"> |
17 |
<!ENTITY ja.traffic "$B:.;((B"> |
18 |
<!ENTITY ja.domain.level "$B3,0L(B"> |
19 |
<!ENTITY ja.mail "$B%a%$%k(B"> |
20 |
<!ENTITY ja.mail.addressing "&ja.address;$B;XDj(B"> |
21 |
<!ENTITY ja.mail.bulk " bulk "> |
22 |
<!ENTITY ja.mail.header "$BF,(B"> |
23 |
<!ENTITY ja.mail.forwarder "$BE>Aw<T(B"> |
24 |
<!ENTITY ja.mail.forwarder-process "&ja.mail.forwarder;$B=hM}(B"> |
25 |
<!ENTITY ja.mail.mailbox "$B%a%$%kH"(B"> |
26 |
<!ENTITY ja.mail.mail-system "&ja.mail;&ja.system;"> |
27 |
<!ENTITY ja.mail.originate "$BH/?.(B"> |
28 |
<!ENTITY ja.mail.originator "&ja.mail.originate;$B<T(B"> |
29 |
<!ENTITY ja.net.hop "$B%[%C%W(B"> |
30 |
<!ENTITY ja.net.host "$B%[%9%H(B"> |
31 |
<!ENTITY ja.net.nickname "$B0&>N(B"> |
32 |
<!ENTITY ja.net.route "$B7PO)(B"> |
33 |
<!ENTITY ja.net.source-route "$B;OE@(B&ja.net.route;"> |
34 |
<!ENTITY ja.net.source-routing "&ja.net.source-route;$B@)8f(B"> |
35 |
]> |
36 |
<?rfc-translation show-rfc-header-category="no" ?> |
37 |
<?rfc-translation show-rfc-status="no"?> |
38 |
<?rfc-translation autoquote-samp-element="no"?> |
39 |
<rfc number="&rfc.number;" category="info" |
40 |
xmlns:ja="http://suika.fam.cx/~wakaba/lang/rfc/translation/" |
41 |
xmlns:h="http://www.w3.org/1999/xhtml"> |
42 |
<!-- xmlns:myns="mailto:julian.reschke@greenbytes.de?subject=rcf2629.xslt"--> |
43 |
<front> |
44 |
<title>Internet Name Domains</title> |
45 |
<ja:title xml:lang="ja">Internet $BL>A0%I%a%$%s(B</ja:title> |
46 |
<author initials="D. L." surname="Mills" fullname="D. L. Mills"> |
47 |
<organization>COMSAT Laboratories</organization> |
48 |
</author> |
49 |
<date month="September" year="1981" /> |
50 |
</front> |
51 |
<ja:front> |
52 |
<author fullname="$B$o$+$P(B" ja:id="wakaba"> |
53 |
<address> |
54 |
<email>w@suika.fam.cx</email> |
55 |
<uri>http://suika.fam.cx/~wakaba/</uri> |
56 |
</address> |
57 |
</author> |
58 |
<ja:copyright> |
59 |
<ja:item>Copyright © $B$o$+$P(B (2002)$B!#A48"J]N1!#(B</ja:item> |
60 |
</ja:copyright> |
61 |
<ja:change> |
62 |
<ja:item year="2002" month="07" day="27"><author ja:ref="wakaba" /> |
63 |
<t>$BK]Lu40N;!#(B</t> |
64 |
</ja:item> |
65 |
<ja:item year="2002" month="09" day="01"><author ja:ref="wakaba" /> |
66 |
<t><ja:link type="rfc" number="2629" /> $B$G%^!<%/IU$1!#(B</t> |
67 |
</ja:item> |
68 |
</ja:change><!-- $Date: 2002/09/01 09:18:48 $ --> |
69 |
</ja:front> |
70 |
<middle> |
71 |
|
72 |
<section title="Introduction"> |
73 |
<t> |
74 |
<ja:pair> |
75 |
<ja:l xml:lang="en"> |
76 |
In the long run, it will not be practicable for every internet |
77 |
host to include all internet hosts in its name-address tables. Even |
78 |
now, with over four hundred names and nicknames in the combined |
79 |
ARPANET-DCNET tables, this has become awkward. Some sort of |
80 |
hierarchical name-space partitioning can easily be devised to deal |
81 |
with this problem; however, it has been wickedly difficult to find one |
82 |
compatible with the known mail systems throughout the community. The |
83 |
one proposed here is the product of several discussions and meetings |
84 |
and is believed both compatible with existing systems and extensible |
85 |
for future systems involving thousands of hosts. |
86 |
</ja:l> |
87 |
<ja:l xml:lang="ja"> |
88 |
$BD9$$L\$G8+$l$P!"A4$F$N(B&ja.internet;&ja.net.host;$B$,A4$F$N(B&ja.internet; |
89 |
&ja.net.host;$B$rL>A0!>(B&ja.address;$BI=$K4^$a$k$3$H$O<B9T2DG=$G$O$J$$$G$7$g$&!#8=:_4{$K!"7k9g(B |
90 |
ARPANET-DCNET $BI=$K$O(B400$B0J>e$NL>A0$H(B&ja.net.nickname;$B$,$"$k$N$G!"Lq2p$K$J$C$F$$$^$9!#2?$i$+$N7A$G$N3,AXE*$JL>A06u4V$NJ,3d$G!"$3$NLdBj$r=hM}$9$k9)IW$,4JC1$K=PMh$^$9!#$7$+$7!"(B&ja.community;$BCf$N4{CN$N(B&ja.mail.mail-system;$B$H8_49@-$rJ]$D$N$OHs>o$KFq$7$$$3$H$G$9!#$3$3$KDs0F$9$k$b$N$O!"?tEY$K$o$?$k5DO@$H2q9g$N@.2L$G$"$j!"4{B8$N(B&ja.system;$B$H$N8_49@-$,$"$C$F!">-Mh$N4v@i$b$N(B&ja.net.host;$B$r4^$`(B&ja.system;$B$X$N3HD%@-$b$"$k$H?.$8$F$$$^$9!#(B |
91 |
</ja:l> |
92 |
</ja:pair> |
93 |
</t> |
94 |
</section> |
95 |
|
96 |
<section title="General Topology" ja:title-ja="$B0lHLE*0LAj(B"><!-- 2. --> |
97 |
<t> |
98 |
<ja:pair> |
99 |
<ja:l xml:lang="en"> |
100 |
We first observe that every internet host is uniquely identified |
101 |
by one or more 32-bit internet addresses and that the entire system is |
102 |
fully connected. For the moment, the issue of protocol compatibility |
103 |
will be ignored, so that all hosts can be assumed MTP-competent. We |
104 |
next impose a topological covering on the space of all internet |
105 |
addresses with a set of so-called name domains. In the natural model, |
106 |
name domains would correspond to institutions such as ARPA, UCL and |
107 |
COMSAT, and would not be necessarily disjoint or complete. While in |
108 |
principle name domains could be hierarchically structured, we will |
109 |
assume in the following only a single-level structure. |
110 |
</ja:l> |
111 |
<ja:l xml:lang="ja"> |
112 |
$B$^$:;O$a$K!"A4$F$N(B&ja.internet;&ja.net.host;$B$O(B1$B$D0J>e$N(B32$B%S%C%H(B&ja.internet-address;$B$GHfN`$J$/<1JL$5$l!"(B&ja.system;$BA4BN$O40A4$K@\B3$5$l$F$$$k$H$7$^$9!#$5$7$"$?$C$F!"(B&ja.protocol;$B8_49@-LdBj$OL5;k$9$k$N$G!"A4$F$N(B&ja.net.host;$B$,(B |
113 |
MTP $BE,9g$H2>Dj=PMh$^$9!#<!$KA4$F$N(B&ja.internet-address;$B$r$$$o$f$kL>A0%I%a%$%s$N=89g$G0LAjE*$JJ$$$$rHo$;$^$9!#<+A3(B&ja.model;$B$G$O!"L>A0%I%a%$%s$O(B |
114 |
ARPA, UCL, COMSAT $B$N$h$&$J;\@_$H0lCW$9$k$G$7$g$&$+$i!"2rBN$dO"7k$OI,MW$J$$$G$7$g$&!#86B'$H$7$FL>A0%I%a%$%s$O3,AXE*$K9=B$2==PMh$k$G$7$g$&$+$i!"0J9_$G$OC10l(B&ja.domain.level;$B9=B$$@$1$r2>Dj$7$^$9!#(B |
115 |
</ja:l> |
116 |
</ja:pair> |
117 |
</t> |
118 |
<t> |
119 |
<ja:pair> |
120 |
<ja:l xml:lang="en"> |
121 |
Every name domain is associated with one or more internet |
122 |
processes called mail forwarders and the name of that domain is the |
123 |
name for any of these processes. Each forwarder process for a |
124 |
particular domain is expected to maintain duplicate name-address |
125 |
tables containing the names of all hosts in its domain and, in |
126 |
addition, the name of at least one forwarder process for every other |
127 |
domain. Forwarder processes may be replicated in the interests of |
128 |
robustness; however, the resulting complexities in addressing and |
129 |
routing will not be discussed further here. A particular internet |
130 |
host may support a number of forwarder processes and their collective |
131 |
names represent nicknames for that host, in addition to any other |
132 |
names that host may have. In the following an internet host |
133 |
supporting one or more forwarder proceses will be called simply a |
134 |
forwarder. |
135 |
</ja:l> |
136 |
<ja:l xml:lang="ja"> |
137 |
$B3FL>A0%I%a%$%s$O(B&ja.mail;&ja.mail.forwarder;$B$K8F$P$l$k0l$D0J>e$N(B&ja.internet;$B=hM}$H4XO"IU$1$i$l$F$$$F!"$=$N%I%a%$%s$NL>A0$O$3$l$i$N=hM}$N$$$:$l$b$NL>A0$G$9!#FCDj%I%a%$%s$X$N3F(B&ja.mail.forwarder-process;$B$O!"$=$N%I%a%$%sFb$NA4$F$N(B&ja.net.host;$B$NL>A0$K2C$($F:GDc0l$D$NB>$N%I%a%$%s$X$N(B&ja.mail.forwarder-process;$B$NL>A0$+$i@.$kJ#@=$NL>A0!>(B&ja.address;$BI=$G0];}$9$k$3$H$K$J$C$F$$$^$9!#(B&ja.mail.forwarder-process;$B$O4h6/@-$N$?$a7+$jJV$7$F$b9=$$$^$;$s!#$7$+$7!"(B&ja.mail.addressing;$B$H7PO)@)8f$N7k2LJ#;(@-$O$3$3$G$O07$$$^$;$s!#$"$k(B&ja.internet;&ja.net.host;$B$O!"4v$D$b$N(B&ja.mail.forwarder-process;$B$H$=$N(B&ja.net.host;$B$N(B&ja.net.nickname;$B$rI=$9=8@.L>(B, $B99$K$=$N(B&ja.net.host;$B$,;}$AF@$kB>$NL>A0$KBP1~$7$F9=$$$^$;$s!#B3$$$F(B1$B$D0J>e$N(B&ja.mail.forwarder-process;$B$KBP1~$7$?(B&ja.internet;&ja.net.host;$B$,C1$K(B&ja.mail.forwarder;$B$r8F$V$G$7$g$&!#(B |
138 |
</ja:l> |
139 |
</ja:pair> |
140 |
</t> |
141 |
<t> |
142 |
<ja:pair> |
143 |
<ja:l xml:lang="en"> |
144 |
Every host is expected to maintain name-address tables including |
145 |
the names of at least one forwarder for every |
146 |
domain together with additional hosts as convenient. A host may |
147 |
belong to several domains, but it is not necessary that all hosts in |
148 |
any domain, be included in its tables. Following current practice, |
149 |
several nicknames may be associated with the principal name of a host |
150 |
in any domain and these names need not be unique relative to any other |
151 |
domain. Furthermore, hosts can be multi-homed, that is, respond to |
152 |
more than one address. For the purpose of mail forwarding and |
153 |
delivery, we will assume that any of these addresses can be used |
154 |
without prejudice. The use of multi-homing to facilitate source |
155 |
routing is a topic for future study. |
156 |
</ja:l> |
157 |
<ja:l xml:lang="ja"> |
158 |
$BA4(B&ja.net.host;$B$O$=$NL>A0$H:GDc0l$D$N(B&ja.mail.forwarder;$B$r$"$k$HET9g$NNI$$DI2C$N(B&ja.net.host;$B$H6&$K4^$a$?L>A0!>(B&ja.address;$BI=$r0];}$9$k$3$H$K$J$j$^$9!#$"$k(B&ja.net.host;$B$OJ#?t$N%I%a%$%s$K=jB0=PMh$^$9$,!"$9$Y$F$N(B&ja.net.host;$B$,$=$NI=$K4^$^$l$F$$$kI,MW$O$"$j$^$;$s!#8=:_$N47=,$K=>$$!"4v$D$+$N(B&ja.net.nickname;$B$r$I$N%I%a%$%s$N(B&ja.net.host;$B$N86B'L>$K4XO"IU$1$F9=$$$^$;$s$7!"$3$NL>A0$,B>$N%I%a%$%s$b4^$a$FFHFC$G$"$kI,MW$O$"$j$^$;$s!#$J$*!"(B&ja.net.host;$B$O(B&ja.multi-home;$B$G$"$k$3$H$,=PMh$^$9!#$D$^$j!"J#?t$N(B&ja.address;$B$KH?1~$9$k$3$H$,=PMh$^$9!#(B&ja.mail;$BE>Aw!&G[AwL\E*$G!"$3$N(B&ja.address;$B$N$&$A$N$$$:$l$+$,ITMx1WL5$7$KMxMQ2DG=$H2>Dj$7$^$9!#(B&ja.net.source-routing;$BB%?J$N$?$a(B&ja.multi-home;$B$G;HMQ$9$k$3$H$O>-Mh$N2]Bj$H$7$^$9!#(B |
159 |
</ja:l> |
160 |
</ja:pair> |
161 |
</t> |
162 |
</section> |
163 |
|
164 |
<section title="Naming Conventions" ja:title-ja="$BL>A0(B&ja.convention;"> |
165 |
<figure> |
166 |
<preamble> |
167 |
<ja:pair> |
168 |
<ja:l xml:lang="en"> |
169 |
In its most general form, a standard internet mailbox name has |
170 |
the syntax |
171 |
</ja:l> |
172 |
<ja:l xml:lang="ja"> |
173 |
$BHs>o$K0lHLE*$J7A$G$O!"I8=`(B&ja.internet;&ja.mail.mailbox;$BL>$O<!$NMM$J9=J8$K$J$j$^$9!#(B |
174 |
</ja:l> |
175 |
</ja:pair> |
176 |
</preamble> |
177 |
<ja:artwork> |
178 |
<artwork><user>.<host>@<domain> ,</artwork> |
179 |
<h:div class="blockcode"><h:var><user></h:var>.<h:var><host></h:var>@<h:var><domain></h:var></h:div> |
180 |
</ja:artwork> |
181 |
<postamble> |
182 |
<ja:pair> |
183 |
<ja:l xml:lang="en"> |
184 |
where <h:var><user></h:var> is the name of a user known at the host <h:var><host></h:var> in the |
185 |
name domain <h:var><domain></h:var>. This syntax is intended to suggest a |
186 |
three-level hierarchically structured name (reading from the right) |
187 |
which is unique throughout the internet system. However, hosts within |
188 |
a single domain may agree to adopt another structure, as long as it |
189 |
does not conflict with the above syntax and as long as the forwarders |
190 |
for that domain are prepared to make the requisite transformations. |
191 |
For instance, let the name of a domain including DCNET be COMSAT and |
192 |
the name of one of its hosts be COMSAT-DLM with Mills a user known to |
193 |
that host. From within the COMSAT domain the name Mills@COMSAT-DLM |
194 |
uniquely identifies that mailbox as could, for example, the name |
195 |
Mills.COMSAT-DLM@COMSAT from anywhere in the internet system. |
196 |
However, Mills@COMSAT-DLM is not necessarily meaningful anywhere |
197 |
outside the COMSAT domain (but it could be). |
198 |
</ja:l> |
199 |
<ja:l xml:lang="ja"> |
200 |
$B$3$3$G(B <h:var><user></h:var> $B$OL>A0%I%a%$%s(B <h:var><domain></h:var> $B$N(B&ja.net.host; <h:var><host></h:var> |
201 |
$B$NMxMQ<T$NL>A0$G$9!#$3$N9=J8$O(B&ja.internet-system;$BFb$GFHFC$G$"$k(B3$BCJ3,3,AX2=9=B$L>(B ($B1&$+$iFI$`(B) $B$rDs>'$9$k$H$$$&$3$H$G$9!#$7$+$7!"C10l%I%a%$%sFb$N(B&ja.net.host;$B$O!">e5-9=J8$H>WFM$7$J$$8B$j!"$^$?I,MW$JJQ7A$r;\$9Ev3:%I%a%$%sMQ(B&ja.mail.forwarder;$B$,=`Hw$5$l$k8B$j!"B>$N9=B$$r:NMQ$7$F$b9=$$$^$;$s!#Nc$($P!"(B |
202 |
<h:samp>DCNET</h:samp> $B$r4^$`%I%a%$%s$NL>A0$r(B <h:samp>COMSAT</h:samp> $B$H$7!"$=$NCf$N(B&ja.net.host;$B$N0l$D$NL>A0$r(B |
203 |
<h:samp>COMSAT-DLM</h:samp> $B$H$7!"$=$N(B&ja.net.host;$B$KMxMQ<T(B <h:samp>Millds</h:samp> $B$,$$$k$H$7$^$9!#(B |
204 |
<h:samp>COMSAT</h:samp> $B%I%a%$%sCf$+$i$O!"L>A0(B <h:samp>Mills@COMSAT-DLM</h:samp> |
205 |
$B$O$=$N(B&ja.mail.mailbox;$B$rM#0l$K<1JL$9$k$3$H$,=PMh!"L>A0(B <h:samp>Mills.COMSAT-DLM@COMSAT</h:samp> |
206 |
$B$O(B&ja.internet-system;$B$N$I$3$+$i$G$b=PMh$^$9!#$7$+$7!"(B <h:samp>Mills@COMSAT-DLM</h:samp> |
207 |
$B$O(B <h:samp>COMSAT</h:samp> $B%I%a%$%s$N30$N$$$:$3$K$*$$$F$b0UL#$r;}$C$F$$$kI,MW$O$"$j$^$;$s(B |
208 |
($B;}$?$;$k$3$H$O$G$-$^$9(B)$B!#(B |
209 |
</ja:l> |
210 |
</ja:pair> |
211 |
</postamble> |
212 |
</figure> |
213 |
<t> |
214 |
<ja:pair> |
215 |
<ja:l xml:lang="en"> |
216 |
A typical set of name domains covering the current internet |
217 |
system might include ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET, |
218 |
WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST |
219 |
(INTELPOSTNET) and the various public data networks. The ARPA |
220 |
forwarder would use a name-address table constructed from the latest |
221 |
version of the HOSTS.TXT table in the NIC data base. The other |
222 |
forwarders would construct their own, but be expected to deposit a |
223 |
copy in the NIC data base. |
224 |
</ja:l> |
225 |
<ja:l xml:lang="ja"> |
226 |
$B8=:_$N(B&ja.internet-system;$B$rJ$$&L>A0%I%a%$%s$NE57?E*=89g$O!"(B |
227 |
ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET, |
228 |
WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST |
229 |
(INTELPOSTNET), $B3F<o8xE*%G!<%?LV$r4^$`$N$,NI$$$G$7$g$&!#(B |
230 |
ARPA &ja.mail.forwarder;$B$O(B |
231 |
NIC $B%G!<%?%Y!<%9$N(B <h:code>HOSTS.TXT</h:code> |
232 |
$BI=$N:G?7HG$+$i9=C[$7$?L>A0!>(B&ja.address;$BI=$r;H$$$^$7$g$&!#(B |
233 |
</ja:l> |
234 |
</ja:pair> |
235 |
</t> |
236 |
</section> |
237 |
|
238 |
<section title="Mail Transport Principles" ja:title-ja="&ja.mail;$BE>Aw4pK\J}?K(B"> |
239 |
<t> |
240 |
<ja:pair> |
241 |
<ja:l xml:lang="en"> |
242 |
In the interests of economy and simplicity, it is expected that |
243 |
the bulk of all mail transport in the internet system will take place |
244 |
directly from originator to recipient |
245 |
host and without intermediate relay. A technique of caching will |
246 |
probably be necessary for many hosts in order to reduce the traffic |
247 |
with forwarders merely to learn the internet address associated with a |
248 |
correspondent host. This naturally encourages naming strategies |
249 |
designed to minimize duplicate names in the various domains; however, |
250 |
such duplicates are not forbidden. |
251 |
</ja:l> |
252 |
<ja:l xml:lang="ja"> |
253 |
$B<AAG7pLs$N$?$a$K!"(B&ja.internet-system;$BFb$NA4$F$N(B&ja.mail;$BE>Aw$N(B&ja.mail.bulk;$B$O(B&ja.mail.originator;$B$+$i<u?.(B&ja.net.host;$B$KCf7Q$J$7$KD>@\$7$^$7$g$&!#(B&ja.mail.forwarder;$B$K!"C1$KDL?.(B&ja.net.host;$B$K4XO"IU$1$i$l$?(B&ja.internet-address;$B$r3P$($F$*$/(B&ja.cache;$B$N5;=Q$,$*$=$i$/!"(B&ja.traffic;$B$r8:$i$9$?$a$KB?$/$N(B&ja.net.host;$B$KI,MW$G$7$g$&!#$3$l$OEvA33F%I%a%$%sCf$NL>A0$N=EJ#$r:G>.2=$9$k$h$&$K@_7W$7$?L?L>@oN,$r?d>)$9$k$3$H$K$J$j$^$9!#$7$+$7!"$3$N=EJ#$O6X;_$O$7$^$;$s!#(B |
254 |
</ja:l> |
255 |
</ja:pair> |
256 |
</t> |
257 |
<t> |
258 |
<ja:pair> |
259 |
<ja:l xml:lang="en"> |
260 |
There are several reasons why some messages will have to be |
261 |
staged at an intermediate relay, among them the following: |
262 |
</ja:l> |
263 |
<ja:l xml:lang="ja"> |
264 |
$B%a%C%;!<%8$,Cf7Q$r7P$J$1$l$P$J$i$J$$M}M3$,<!$K5s$2$kMM$K$$$/$D$+$"$j$^$9!#(B |
265 |
</ja:l> |
266 |
</ja:pair> |
267 |
|
268 |
<list style="numbers"> |
269 |
<t> |
270 |
<ja:pair> |
271 |
<ja:l xml:lang="en"> |
272 |
It may not be possible or convenient for the originator |
273 |
and recipient hosts to be up on the internet system at |
274 |
the same time for the duration of the transfer. |
275 |
</ja:l> |
276 |
<ja:l xml:lang="ja"> |
277 |
&ja.mail.originate;$B!&<u?.(B&ja.net.host;$B$,F1;~9o$K(B&ja.internet-system;$B$GE>Aw$N4V2TF0$7$F$$$J$$$H$$$1$J$$$N$O2DG=$G$J$$$+ITJX$G$"$k!#(B |
278 |
</ja:l> |
279 |
</ja:pair> |
280 |
</t> |
281 |
<t> |
282 |
<ja:pair> |
283 |
<ja:l xml:lang="en"> |
284 |
The originator host may not have the resources to |
285 |
perform all name-address translations required. |
286 |
</ja:l> |
287 |
<ja:l xml:lang="ja"> |
288 |
&ja.mail.originate;&ja.net.host;$B$OI,MW$JA4$F$NL>A0!>(B&ja.address;$BBP1~$r;}$D;q8;$,L5$$$+$b$7$l$J$$!#(B |
289 |
</ja:l> |
290 |
</ja:pair> |
291 |
</t> |
292 |
<t> |
293 |
<ja:pair> |
294 |
<ja:l xml:lang="en"> |
295 |
A direct-connection path may not be feasible due to |
296 |
regulatory economic or security constraints. |
297 |
</ja:l> |
298 |
<ja:l xml:lang="ja"> |
299 |
$BD>@\@\B37PO)$,7P:Q>e$^$?$O0BA4>e5,@)$5$l$F$$$FMxMQ=PMh$J$$$+$b$7$l$J$$!#(B |
300 |
</ja:l> |
301 |
</ja:pair> |
302 |
</t> |
303 |
<t> |
304 |
<ja:pair> |
305 |
<ja:l xml:lang="en"> |
306 |
The originator and recipient hosts may not recognize the |
307 |
same lower-level transport protocol (e.g. TCP and NCP). |
308 |
</ja:l> |
309 |
<ja:l xml:lang="ja"> |
310 |
&ja.mail.originate;$B!&<u?.(B&ja.net.host;$B$,F1$8Dc?e=`E>Aw(B&ja.protocol;$B$rG'CN$7$J$$$+$b$7$l$J$$(B |
311 |
($BNc$($P(B TCP $B$H(B NCP)$B!#(B |
312 |
</ja:l> |
313 |
</ja:pair> |
314 |
</t> |
315 |
</list> |
316 |
</t> |
317 |
|
318 |
<t> |
319 |
<ja:pair> |
320 |
<ja:l xml:lang="en"> |
321 |
A mail relay is an internet process equipped to store an MTP |
322 |
message for subsequent transmission. A mail forwarder is a mail |
323 |
relay, but not all relays are forwarders, since they might not include |
324 |
the full name-address capability required of forwarders. In addition, |
325 |
relays may not be competent in all domains. For instance, a MTP/TCP |
326 |
relay may not understand NCP. In other words, the forwarders must be |
327 |
fully connected, but the relays may not. |
328 |
</ja:l> |
329 |
<ja:l xml:lang="ja"> |
330 |
&ja.mail;$BCf7Q$O!"8eB3E>Aw$N$?$a$N(B MTP $B%a%C%;!<%8$rC_$($kI,MW$N$"$k(B&ja.internet;$B=hM}$G$9!#(B&ja.mail;&ja.mail.forwarder;$B$O(B&ja.mail;$BCf7Q<T$G$9$,!"(B |
331 |
$BA4$F$NCf7Q<T$,(B&ja.mail.forwarder;$B$G$O$"$j$^$;$s!#(B&ja.mail.forwarder;$B$N40A4L>A0!>(B&ja.address;$BG=NOMW7o$r4^$s$G$$$J$$$+$i$G$9!#$^$?!"Cf7Q<T$OA4$F$N%I%a%$%s$GM-G=$G$O$J$$$+$b$7$l$^$;$s!#Nc$($P!"(B |
332 |
MTP/TCP $BCf7Q$O(B NCP $B$rM}2r$7$^$;$s!#8@$$49$($l$P!"(B&ja.mail.forwarder;$B$O40A4$K@\B3$5$l$F$$$J$1$l$P$J$j$^$;$s$,!"Cf7Q<T$O$=$&$G$O$"$j$^$;$s!#(B |
333 |
</ja:l> |
334 |
</ja:pair> |
335 |
</t> |
336 |
<t> |
337 |
<ja:pair> |
338 |
<ja:l xml:lang="en"> |
339 |
The particular sequence of relays traversed by a message is |
340 |
determined by the sender by means of the source route specification in |
341 |
the MRCP command. There are several implications to this: |
342 |
</ja:l> |
343 |
<ja:l xml:lang="ja"> |
344 |
$B%a%C%;!<%8$,DL$jH4$1$kFCDj$NCf7QNs$O!"Aw?.<T$K$h$j(B MRCP |
345 |
$BL?Na$N(B&ja.net.source-route;$B;XDj$G7hDj$5$l$^$9!#$3$l$K$O4v$D$+$N78$o$j9g$$$,$"$j$^$9!#(B |
346 |
</ja:l> |
347 |
</ja:pair> |
348 |
|
349 |
<list style="numbers"> |
350 |
<t> |
351 |
<ja:pair> |
352 |
<ja:l xml:lang="en"> |
353 |
Advisory messages returned to the originator by a relay |
354 |
or recipient host are expected to traverse the route in |
355 |
reverse order. |
356 |
</ja:l> |
357 |
<ja:l xml:lang="ja"> |
358 |
$BCf7Q$^$?$O<u?.(B&ja.net.host;$B$+$i(B&ja.mail.originator;$B$KJV$5$l$k4+9p%a%C%;!<%8$O!"(B&ja.net.route;$B$r5U=g$GDL$k$3$H$,4|BT$5$l$k!#(B |
359 |
</ja:l> |
360 |
</ja:pair> |
361 |
</t> |
362 |
<t> |
363 |
<ja:pair> |
364 |
<ja:l xml:lang="en"> |
365 |
Relay host names follow the same naming convention as |
366 |
all host names relative to their domain. Since it may |
367 |
not be possible (see below) to use internet addresses to |
368 |
dis-ambiguate the domain, the complete standard internet |
369 |
name .<h:var><host></h:var>@<h:var><domain></h:var> is required everywhere. |
370 |
</ja:l> |
371 |
<ja:l xml:lang="ja"> |
372 |
$BCf7Q(B&ja.net.host;$BL>$O!"$=$N%I%a%$%s$K4X78$N$"$kA4$F$N(B&ja.net.host;$BL>$HF1$8L?L>5,Ls$K=>$&!#(B&ja.internet-address;$B$r(B&ja.dis-ambiguate;$B$J%I%a%$%s$K;H$&$N$OIT2DG=(B |
373 |
($B2<5-;2>H(B) $B$N$G!"40A4$JI8=`(B&ja.internet;$BL>(B |
374 |
.<h:var><host></h:var>@<h:var><domain></h:var> $B$,A4$F$N>l=j$GI,?\$G$9!#(B |
375 |
</ja:l> |
376 |
</ja:pair> |
377 |
</t> |
378 |
<t> |
379 |
<ja:pair> |
380 |
<ja:l xml:lang="en"> |
381 |
There is no current provision for strict/loose route |
382 |
specifications. If, in fact, the "ordinary" host |
383 |
specification @<h:var><host></h:var> were used, each relay or forwarder |
384 |
would use the rules outlined in the next section for |
385 |
routing. This may result in additional relay hops. |
386 |
</ja:l> |
387 |
<ja:l xml:lang="ja"> |
388 |
$B873J(B/$BE,Ev$J(B&ja.net.route;$B;XDj$,8=:_6!5k$5$l$F$$$J$$!#<B:]!"!VIaDL$N!W(B |
389 |
&ja.net.host;$B;XDj(B @<h:var><host></h:var> $B$,;H$o$l$F$$$?$J$i!"3FCf7Q<T$d(B&ja.mail.forwarder;$B$O!"<!$N@a$G35@b$9$k5,B'$r;H$C$F$$$^$7$g$&!#$3$l$OCf7Q(B&ja.net.hop;$B?t$rA}$d$97k2L$K$J$k$+$b$7$l$^$;$s!#(B |
390 |
</ja:l> |
391 |
</ja:pair> |
392 |
</t> |
393 |
</list> |
394 |
</t> |
395 |
</section> |
396 |
|
397 |
<section title="Forwarder Operations" ja:title-ja="&ja.mail.forwarder;$B$N:n6H(B"> |
398 |
<t> |
399 |
<ja:pair> |
400 |
<ja:l xml:lang="en"> |
401 |
This section describes a likely scenario involving hosts, relays |
402 |
and forwarders and typical internet routes. When a forwarder receives |
403 |
a message for <h:var><user></h:var>.<h:var><host></h:var>@<h:var><domain></h:var>, it transforms <h:var><host></h:var> if |
404 |
necessary and forwards the message to its address found in the |
405 |
name-address table for <h:var><domain></h:var>. Note that a single host can be a |
406 |
forwarder for several independent domains in this model and that these |
407 |
domains can intersect. Thus, the names Mills@USC-ISIE, |
408 |
Mills.USC-ISIE@ARPA and Mills.USC-ISIE@COMSAT can all refer to the |
409 |
same mailbox and the names USC-ISIE, ARPA and COMSAT can, conceivably, |
410 |
all be known in the same domain. Such use would be permissable only |
411 |
in case the name USC-ISIE did not conflict with other names in this |
412 |
domain. |
413 |
</ja:l> |
414 |
<ja:l xml:lang="ja"> |
415 |
$B$3$N>O$G$O!"(B&ja.net.host;, $BCf7Q<T(B, &ja.mail.forwarder;, $B$=$l$KE57?E*$J(B&ja.internet;&ja.net.route;$B$r4^$a$?(B |
416 |
$BE,Ev$J6Z=q$-$r@bL@$7$^$9!#(B&ja.mail.forwarder;$B$,(B <h:var><user></h:var>.<h:var><host></h:var>@<h:var><domain></h:var> $B$X$N(B |
417 |
$B%a%C%;!<%8$r<u?.$7$?;~!"I,MW$J$i(B <h:var><host></h:var> $B$rJQ49$7$F!"(B |
418 |
$B%a%C%;!<%8$r(B <h:var><domain></h:var> $B$NL>A0!>(B&ja.address;$BI=$K8+$($k(B&ja.address;$B$KE>Aw$7$^$9!#(B |
419 |
$BC10l$N(B&ja.net.host;$B$,$3$N%b%G%k$G$O4v$D$+$NFHN)$7$?%I%a%$%s$N(B&ja.mail.forwarder;$B$K(B |
420 |
$B$J$jF@$F!"3F%I%a%$%s$O8r:5$7F@$k$3$H$KCm0U$7$F2<$5$$!#(B |
421 |
$B$G$9$+$i!"L>A0(B Mills@USC-ISIE, Mills.USC-ISIE@ARPA, Mills.USC-ISIE@COMSAT |
422 |
$B$OA4$FF1$8(B&ja.mail.mailbox;$B$r;2>H$7F@$F!"L>A0(B USC-ISIE, ARPA, COMSAT |
423 |
$B$O$*$=$i$/A4$F!"F1$8%I%a%$%sCf$K$"$k$H$7F@$^$9!#$3$&$7$?;HMQ$O!"(B |
424 |
$BL>A0(B USC-ISIE $B$,$3$N%I%a%$%sCf$NB>$NL>A0$H>WFM$7$J$$>l9g$K8B$C$F(B |
425 |
$BG'$a$i$l$^$9!#(B |
426 |
</ja:l> |
427 |
</ja:pair> |
428 |
</t> |
429 |
<t> |
430 |
<ja:pair> |
431 |
<ja:l xml:lang="en"> |
432 |
In order for this scheme to work efficiently, it is desireable |
433 |
that messages transiting forwarders always contain standard internet |
434 |
mailbox names. When this is not feasible, as in the current ARPANET |
435 |
mail system, the forwarder must be able to determine which domain the |
436 |
message came from and edit the names accordingly. This would be |
437 |
necessary in order to compose a reply to the message in any case. |
438 |
</ja:l> |
439 |
<ja:l xml:lang="ja"> |
440 |
$B$3$NJ}<0$,G=N(E*$KF0$/$h$&$K!"%a%C%;!<%8$rM"Aw$9$k(B&ja.mail.forwarder;$B$O(B |
441 |
$B>o$KI8=`(B&ja.internet;&ja.mail.mailbox;$BL>$r4^$`$N$,K>$^$7$$$G$9!#(B |
442 |
$B$3$l$,=PMhL5$$>l9g!"8=:_$N(B ARPANET &ja.mail.mail-system;$B$N$h$&$K!"(B |
443 |
&ja.mail.forwarder;$B$O%a%C%;!<%8$,Mh$?%I%a%$%s$r7hDj$7!"$=$l$K=>$C$F(B |
444 |
$BL>A0$rJT=8=PMh$J$1$l$P$J$j$^$;$s!#$3$l$O%a%C%;!<%8$X$NJV?.$r(B |
445 |
$B9=@.$9$k$?$a$K$O$I$s$J>l9g$G$bI,MW$J$3$H$G$7$g$&!#(B |
446 |
</ja:l> |
447 |
</ja:pair> |
448 |
</t> |
449 |
<t> |
450 |
<ja:pair> |
451 |
<ja:l xml:lang="en"> |
452 |
In the RFC-780 model a message arriving at a forwarder is |
453 |
processed by the MTP server there. The server extracts the first |
454 |
entry in the recipient-route field of an MRCP command. There are two |
455 |
cases, depending on whether this entry specifies a domain name or a |
456 |
host name. If a domain name, as determined by a search of a universal |
457 |
table, it refers to one of the domains the server represents. If not, |
458 |
it must a name or nickname of the server's host relative to ooe of the |
459 |
domains to which the sender belongs. This allows a distinction to be |
460 |
made between the domains COMSAT and INTELPOST on one hand and the |
461 |
COMSAT host COMSAT-PLA on the other, all of which might be represented |
462 |
by the same internet address, and implies that domain names must be |
463 |
unique in all domains. |
464 |
</ja:l> |
465 |
<ja:l xml:lang="ja"> |
466 |
RFC 780 &ja.model;$B$G$O!"(B&ja.mail.forwarder;$B$KFO$$$?%a%C%;!<%8$O$=$3$N(B |
467 |
MTP $B%5!<%P!<$G=hM}$7$^$9!#%5!<%C%P!<$O!"(B MRCP $BL?Na$N(B |
468 |
$B<u?.<T(B&ja.net.route;&ja.field;$B$N:G=i$N9`L\$r<h$j=P$7$^$9!#$3$N9`L\$K%I%a%$%sL>$,(B |
469 |
$B;XDj$5$l$F$$$k$+(B&ja.net.host;$BL>$,;XDj$5$l$F$$$k$+$G!"(B2$B$D$N>l9g$KJ,$1$^$9!#(B |
470 |
$B%I%a%$%sL>$N>l9g!"(B universal $BI=$N8!:w$G7hDj$9$k$N$G!"(B |
471 |
$B$3$l$O%5!<%P!<$,BeI=$9$k%I%a%$%s$N0l$D$r;2>H$7$^$9!#(B |
472 |
$B$=$&$G$J$$>l9g!"$3$l$OAw?.<T$,B0$9$k%I%a%$%s$N0l$D(B<!-- (ooe |
473 |
$B$O(B one $B$N(B typo?) -->$B$H4X78$N$"$k%5!<%P!<$N(B&ja.net.host;$B$NL>A0$+(B&ja.net.nickname;$B$G$J$1$l$P$J$j$^$;$s!#$3$l$K$h$j!"0lJ}$G%I%a%$%s(B COMSAT $B$H(B INTELPOST |
474 |
$B$N6hJL$,!"B>J}$G$O(B COMSAT &ja.net.host; COMSAT-PLA $B$N6hJL$,!"(B |
475 |
$B$3$l$i$NA4$F$,F1$8(B&ja.internet-address;$B$GI=8=$5$l$k$H$7$F$b!"(B |
476 |
$BA4$F$N%I%a%$%s$N%I%a%$%sL>$,FHFC$G$"$k$H2>Dj$7$?;~!"(B |
477 |
$B6hJL$9$k$3$H$,=PMh$^$9!#(B |
478 |
</ja:l> |
479 |
</ja:pair> |
480 |
</t> |
481 |
<figure> |
482 |
<preamble> |
483 |
<ja:pair> |
484 |
<ja:l xml:lang="en"> |
485 |
The server next extracts the second entry in the recipient-route |
486 |
field of the MRCP command and resolves its address relative to the |
487 |
domain established by the first entry. If the second entry specifies |
488 |
an explicit domain, then that overrides the first entry. If not and |
489 |
the first entry specifies a domain, then that domain is effective. |
490 |
However, if the first entry specifies the server's host, it may not be |
491 |
apparent which domain is intended. For instance, consider the |
492 |
following two MRCP commands: |
493 |
</ja:l> |
494 |
<ja:l xml:lang="ja"> |
495 |
$B%5!<%P!<$O<!$K!"(B MRCP $BL?Na$N<u?.<T(B&ja.net.route;&ja.field;$B$NBh(B2 entry $B$r<h$j=P$7$F!"(B |
496 |
$B:G=i$N9`L\$G3NN)$7$?%I%a%$%s$H$N(B&ja.address;$B4X78$r2r7h$7$^$9!#(B |
497 |
$BBh(B2$B9`L\$,%I%a%$%s$rL@<($7$F;XDj$5$l$F$$$?>l9g!":G=i$N9`L\$r(B |
498 |
$B>e=q$-$7$^$9!#$=$&$G$J$/$F:G=i$N9`L\$K%I%a%$%s$,;XDj$7$F$"$k>l9g!"(B |
499 |
$B$=$N%I%a%$%s$,M-8z$K$J$j$^$9!#$7$+$7!":G=i$N9`L\$,%5!<%P!<$N(B&ja.net.host;$B$r(B |
500 |
$B;XDj$7$F$$$k>l9g!"$I$N%I%a%$%s$r0U?^$7$F$$$k$N$+L@3N$G$J$$$+$b$7$l$^$;$s!#(B |
501 |
$BNc$($P!"<!$N(B2$B$D$N(B MRCP $BL?Na$r9M$($F$_$^$7$g$&!#(B |
502 |
</ja:l> |
503 |
</ja:pair> |
504 |
</preamble> |
505 |
<ja:artwork> |
506 |
<artwork><![CDATA[MRCP to:<@COMSAT,Mills@HOST> and |
507 |
MRCP to:<@INTELPOST,Mills@HOST> , |
508 |
]]></artwork> |
509 |
<h:ul ja:list-item="none"> |
510 |
<h:li>MRCP to:<@COMSAT,Mills@HOST></h:li> |
511 |
<h:li>MRCP to:<@INTELPOST,Mills@HOST></h:li> |
512 |
</h:ul> |
513 |
</ja:artwork> |
514 |
|
515 |
<postamble> |
516 |
<ja:pair> |
517 |
<ja:l xml:lang="en"> |
518 |
where Mills.HOST@COMSAT and Mills.HOST@INTELPOST are distinct |
519 |
mailboxes on different hosts. A receiving host supporting forwarders |
520 |
for both COMSAT and INTELPOST can then preserve this distinction and |
521 |
forward correctly using the above rules. |
522 |
</ja:l> |
523 |
<ja:l xml:lang="ja"> |
524 |
$B$3$3$G!"(B <h:samp>Mills.HOST@COMSAT</h:samp> $B$H(B <h:samp>Mills.HOST@INTELPOST</h:samp> $B$O0[$J$k(B&ja.net.host;$B$NJL8D$N(B&ja.mail.mailbox;$B$H$7$^$9!#(B <h:samp>COMSAT</h:samp> $B$H(B <h:samp>INTELPOST</h:samp> $B$NAPJ}$X$N(B&ja.mail.forwarder;$B$r;}$D<u?.$7$?(B&ja.net.host; |
525 |
$B$O!">e5-$N5,B'$r;H$C$F@5$7$/$3$N6hJL$rJ];}$7(B, $BE>Aw$9$k$3$H$,=PMh$^$9!#(B |
526 |
</ja:l> |
527 |
</ja:pair> |
528 |
</postamble> |
529 |
</figure> |
530 |
<figure> |
531 |
<preamble> |
532 |
<ja:pair> |
533 |
<ja:l xml:lang="en"> |
534 |
Now let the forwarder host have the name FORWARDER in both the |
535 |
COMSAT and INTELPOST domains and consider its options when receiving |
536 |
the command |
537 |
</ja:l> |
538 |
<ja:l xml:lang="ja"> |
539 |
$B$$$^!"(B&ja.mail.forwarder;&ja.net.host;$B$,L>A0(B <h:samp>FORWARDER</h:samp> $B$r(B <h:samp>COMSAT</h:samp> $B$H(B <h:samp>INTERPOST</h:samp> $BN>%I%a%$%s$K(B |
540 |
$B;}$C$F$$$F!"<!$NL?Na$r<u?.$7$?;~$r9M$($F$_$^$7$g$&!#(B |
541 |
</ja:l> |
542 |
</ja:pair> |
543 |
</preamble> |
544 |
<ja:artwork> |
545 |
<artwork><![CDATA[MRCP to:<@FORWARDER,Mills@HOST> .]]></artwork> |
546 |
<h:ul ja:list-item="none"> |
547 |
<h:li>MRCP to:<@FORWARDER,Mills@HOST></h:li> |
548 |
</h:ul> |
549 |
</ja:artwork> |
550 |
<postamble> |
551 |
<ja:pair> |
552 |
<ja:l xml:lang="en"> |
553 |
The forwarder is being asked simply to relay within the domain of the |
554 |
sender; however, it belongs to more than one domain! The obvious way |
555 |
to resolve this issue would be to forbid the use of implicit domains, |
556 |
as represented by Mills@HOST, and require the full internet mailbox |
557 |
names Mills.HOST@COMSAT or Mills.HOST@INTELPOST. It is also possible |
558 |
to dis-ambiguate the domain by inspecting the first entry of the |
559 |
sender-route field of the MAIL command (see below). |
560 |
</ja:l> |
561 |
<ja:l xml:lang="ja"> |
562 |
&ja.mail.forwarder;$B$OC1$KAw?.<T$N%I%a%$%s$NCf$KCf7Q$9$k$3$H$r5a$a$i$l$F$$$^$9!#(B |
563 |
$B$7$+$7!"$3$$$D$OJ#?t$N%I%a%$%s$KB0$7$F$$$^$9(B! |
564 |
$B$3$NLdBj$r2r7h$9$kL@$i$+$JJ}K!$O!"(B <h:samp>Mills@HOST</h:samp> |
565 |
$B$N$h$&$J0EL[%I%a%$%s$N;HMQ$r6X;_$7$F!"(B |
566 |
<h:samp>Mills.HOST@COMSAT</h:samp> $B$+(B <h:samp>Mills.HOST@INTELPOST</h:samp> $B$N$h$&$K40A4(B&ja.internet;&ja.mail.mailbox;$B$r;HMQ$9$k$3$H$rI,?\$H$9$k$3$H$G$7$g$&!#(B |
567 |
$B$^$?!"(B MAIL $BL?Na$NAw?.<T(B&ja.net.route;&ja.field;$B$N:G=i$N9`L\(B ($B2<5-;2>H(B) |
568 |
$B$rD4$Y$k$3$H$G(B&ja.dis-ambiguate;$B$9$k$N$b2DG=$G$7$g$&!#(B |
569 |
</ja:l> |
570 |
</ja:pair> |
571 |
</postamble> |
572 |
</figure> |
573 |
</section> |
574 |
|
575 |
<section title="Source and Return Routing" ja:title-ja="$B;OE@!&5"E@@)8f(B"> |
576 |
<!-- return routing $B$NLu$O2?(B? --> |
577 |
<t> |
578 |
<ja:pair> |
579 |
<ja:l xml:lang="en"> |
580 |
In the RFC-780 model, routes can be specified in the |
581 |
recipient-route field of the MRCP command and in the sender-route |
582 |
field of the MAIL command. In point of fact, neither the |
583 |
recipient-route or sender-route is necessary if the originator |
584 |
specifies standard internet mailbox names. So long as the routes, |
585 |
when used, consist only of domain names, there is no conflict with the |
586 |
current RFC-780 specification. If for some reason forwarding must be |
587 |
done via other hosts, then the use of a complete and unambigous syntax |
588 |
like .<h:var><host></h:var>@<h:var><domain></h:var> is required in order to avoid problems like that |
589 |
described above. |
590 |
</ja:l> |
591 |
<ja:l xml:lang="ja"> |
592 |
<ja:link type="rfc" number="780" /> $B%b%G%k$G$O!"(B&ja.net.route;$B$O(B MRCP $BL?Na$N<u?.<T(B&ja.net.route;&ja.field;$B$H(B |
593 |
MAIL $BL?Na$NAw?.<T(B&ja.net.route;&ja.field;$B$K;XDj$G$-$^$9!#<B:]$O!"(B |
594 |
$B<u?.<T(B&ja.net.route;$B$bAw?.<T(B&ja.net.route;$B$b!"(B&ja.mail.originator;$B$,I8=`(B&ja.internet;&ja.mail.mailbox;$BL?$r(B |
595 |
$B;XDj$7$F$$$l$PI,MW$"$j$^$;$s!#(B&ja.net.route;$B$,;H$o$l$F$$$k>l9g$K(B |
596 |
$B%I%a%$%sL>$N$_$G@.$C$F$$$k8B$j$K$*$$$F$O!"8=9T$N(B <ja:link type="rfc" number="780" /> |
597 |
$B;EMM$H$O>WFM$7$^$;$s!#2?$i$+$NM}M3$GE>Aw$,B>$N(B&ja.net.host;$B$r7P$F(B |
598 |
$B9T$o$l$?>l9g$O!"(B <h:samp>.<h:var><host></h:var>@<h:var><domain></h:var></h:samp> $B$N$h$&$J40A4$G[#Kf$G$J$$9=J8$,!"(B |
599 |
$B>e$G@bL@$7$?$h$&$JLdBj$rHr$1$k$?$a$KI,MW$G$9!#(B |
600 |
</ja:l> |
601 |
</ja:pair> |
602 |
</t> |
603 |
<t> |
604 |
<ja:pair> |
605 |
<ja:l xml:lang="en"> |
606 |
The present RFC-780 specification requires the receiver to |
607 |
construct a name for the sender and insert this at the beginning of |
608 |
the sender-route. Presumably, the only information it has to |
609 |
construct this name is the internet address of the sender. Consider |
610 |
the case, as in the example above, where multiple domains are |
611 |
supported by a single server on a particular host. If hosts receiving |
612 |
a message relayed via that server were to map its address into a name, |
613 |
there would be no way to determine which domain was intended. We |
614 |
conclude that the sending host must update the sender-route as well as |
615 |
the recipient-route. It does this simply by copying the first entry |
616 |
in the recipient-route as received as the new first entry in the |
617 |
sender-route. |
618 |
</ja:l> |
619 |
<ja:l xml:lang="ja"> |
620 |
$B8=9T$N(B <ja:link type="rfc" number="780" /> $B$N;EMM$G$O!"<u?.<T$,Aw?.<T$NL>A0$rAH$_N)$F!"(B |
621 |
$BAw?.<T(B&ja.net.route;$B$N;O$a$K$3$l$rA^F~$9$kI,MW$,$"$j$^$9!#$*$=$i$/!"(B |
622 |
$B$3$NL>A0$rAH$_N)$F$kM#0l$N>pJs$OAw?.<T$N(B&ja.internet-address;$B$G$7$g$&!#(B |
623 |
$B>e$NNc$N$h$&$K!"J#?t$N%I%a%$%s$,FCDj(B&ja.net.host;$B$NC10l%5!<%P!<$G(B |
624 |
$B;Y$($i$l$F$$$k>l9g$r9M$($F$_$F2<$5$$!#$=$N%5!<%P!<$GCf7Q$5$l$?(B |
625 |
$B%a%C%;!<%8$r<u?.$7$?(B&ja.net.host;$B$,$=$N(B&ja.address;$B$rL>A0$KBP1~$5$;$k;~$K!"(B |
626 |
$B$I$N%I%a%$%s$r0U?^$7$F$$$?$N$+H=CG$9$kJ}K!$O$J$$$G$7$g$&!#(B |
627 |
$B$G$9$+$i!"Aw?.$9$k(B&ja.net.host;$B$O<u?.<T(B&ja.net.route;$BF1MM$KAw?.<T(B&ja.net.route;$B$r$b(B |
628 |
$B99?7$7$J$1$l$P$J$i$J$$$H7kO@IU$1$i$l$^$9!#<u?.<T(B&ja.net.route;$B$N:G=i$N9`L\$r<u?.$7$?$^$^Aw?.<T(B&ja.net.route;$B$N:G=i$N9`L\$KJ#<L$9$k$3$H$G4JC1$K=PMh$^$9!#(B |
629 |
</ja:l> |
630 |
</ja:pair> |
631 |
</t> |
632 |
</section> |
633 |
|
634 |
<section title="Editing the RFC-733 Header" ja:title-ja="RFC 733 &ja.mail.header;$B$NJT=8(B"> |
635 |
<t> |
636 |
<ja:pair> |
637 |
<ja:l xml:lang="en"> |
638 |
Every effort should be made to avoid editing the RFC-733 header, |
639 |
since this is an invasive procedure requiring extensive analysis. It |
640 |
is expected that newly developed mail systems will be aware of the |
641 |
standard internet mailbox syntax and ensure its use everywhere in the |
642 |
RFC-733 and RFC-780 fields. On the occasions where this is not |
643 |
possible, such as in many current ARPANET hosts, the necessary editing |
644 |
should be performed upon first entry to the internet mail system from |
645 |
the local mail system. This avoids the problems mentioned above and |
646 |
simplifies reply functions. |
647 |
</ja:l> |
648 |
<ja:l xml:lang="ja"> |
649 |
<ja:link type="rfc" number="733" /> |
650 |
&ja.mail.header;$B$rJT=8$9$k$3$H$OHr$1$k$h$&$K:GBg8B$NEXNO$rJ'$&$Y$-$G$7$g$&!#(B |
651 |
$B$J$<$J$i!"$3$l$O9-HO0O$NJ,@O$rMW$9$k?/N,E*=hM}$@$+$i$G$9!#(B |
652 |
$B?7$?$K3+H/$5$l$k(B&ja.mail.mail-system;$B$O!"I8=`(B&ja.internet;&ja.mail.mailbox;$B9=J8$K(B |
653 |
$BCm0U$rJ'$$!"(B <ja:link type="rfc" number="733" /> $B$H(B <ja:link type="rfc" number="780" /> $B$NMs$N$I$3$K$*$$$F$b(B |
654 |
$B$3$l$r;H$&$3$H$r3N<B$K$9$k$3$H$,4|BT$5$l$^$9!#(B |
655 |
$B$3$l$,2DG=$G$J$$>l9g!"Nc$($PB?$/$N8=:_$N(B ARPANET &ja.net.host;$B$G$O!"(B |
656 |
$BI,MW$JJT=8$r6ICO(B&ja.mail.mail-system;$B$+$i(B&ja.internet;&ja.mail.mail-system;$B$X(B |
657 |
$B:G=i$N9`L\$K;\$9$Y$-$G$9!#$3$l$K$h$C$F>e$G=R$Y$?LdBj$,Hr$1$i$l!"(B |
658 |
$BJV?.5!G=$,4JC1$K$J$j$^$9!#(B |
659 |
</ja:l> |
660 |
</ja:pair> |
661 |
</t> |
662 |
<t> |
663 |
<ja:pair> |
664 |
<ja:l xml:lang="en"> |
665 |
In the case of ARPANET hosts, the editing operations assume that |
666 |
all names in the form <h:var><anything></h:var>@<h:var><domain></h:var>, where <h:var><domain></h:var> is the name |
667 |
of a domain, are unchanged. Names in the form <h:var><anything></h:var>@<h:var><host></h:var>, |
668 |
where <h:var><host></h:var> is the name of a host in the ARPA domain, are transformed |
669 |
to the form <h:var><anything></h:var>.<h:var><host></h:var>@ARPA. Anything else is an error. |
670 |
Before handing off to an ARPANET NCP mailer, an ARPA MTP forwarder |
671 |
might optionally transform <h:var><anything></h:var>.<h:var><host></h:var>@ARPA to <h:var><anything></h:var>@<h:var><host></h:var> |
672 |
in order to reduce the forwarder traffic when local mail systems are |
673 |
available. Similar situations might exist elsewhere. |
674 |
</ja:l> |
675 |
<ja:l xml:lang="ja"> |
676 |
ARPANET &ja.net.host;$B$N>l9g!"JT=8=hM}$O!"(B <h:var><anything></h:var>@<h:var><domain></h:var> |
677 |
(<h:var><domain></h:var> $B$O%I%a%$%s$NL>A0!#(B) $B$N7A<0$NA4$F$NL>A0$OJQ99$7$J$$$H$7$^$9!#(B |
678 |
<h:var><anything></h:var>@<h:var><host></h:var> (<h:var><host></h:var> $B$O(B ARPA $B%I%a%$%sCf$N(B&ja.net.host;$B$NL>A0!#(B) |
679 |
$B$N7A<0$NL>A0$O(B <h:var><anything></h:var>.<h:var><host></h:var>@ARPA $B$N7A<0$KJQ49$7$^$9!#(B |
680 |
$BB>$N$b$N$O8m$j$G$9!#(B ARPANET NCP mailer $B$K<jEO$9A0$K!"(B |
681 |
ARPA MTP &ja.mail.forwarder;$B$O(B <h:var><anything></h:var>.<h:var><host></h:var>@ARPA $B$+$i(B <h:var><anything></h:var>@<h:var><host></h:var> |
682 |
$B$K!"6ICO(B&ja.mail.mail-system;$B$,MxMQ2DG=$J;~$K(B&ja.mail.forwarder;$B$N:.;($r8:$i$9$?$a$K!"(B |
683 |
$BG$0U$GJQ49$7$F$b9=$$$^$;$s!#F1MM$N>u67$OB>$N>l=j$G$b$"$k$+$b$7$l$^$;$s!#(B |
684 |
</ja:l> |
685 |
</ja:pair> |
686 |
</t> |
687 |
</section> |
688 |
|
689 |
<section title="Concluding Remarks" ja:title-ja="$B$^$H$a(B"> |
690 |
<t> |
691 |
<ja:pair> |
692 |
<ja:l xml:lang="en"> |
693 |
This memorandum is intended to stimulate discussion, not simulate |
694 |
it. |
695 |
</ja:l> |
696 |
<ja:l xml:lang="ja"> |
697 |
$B$3$N3P=q$O5DO@$r;I7c$;$s$H$9$k$b$N$G$"$C$F!"$=$l$r5<BV$7$h$&$H$9$k(B |
698 |
$B$b$N$G$O$"$j$^$;$s!#(B |
699 |
</ja:l> |
700 |
</ja:pair> |
701 |
</t> |
702 |
</section> |
703 |
|
704 |
<!-- |
705 |
------- |
706 |
--> |
707 |
</middle> |
708 |
</rfc> |