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