| 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> |
Parent Directory
| 
Revision Log