📄 rfc1465.txt
字号:
<email-server> ::= "Mail-server: "<X.400 address> <CR>
The email address of the file server.
<FTP-server> ::= "FTP-server: " 'domain name' "; " \
'account-name' ["; " 'password'] <CR>
In addition to the domain name of the server, an
account name and a password is given. In most cases
this will probably be something like "anonymous" and
"guest".
Some servers request the RFC822 address of the user.
This is documented by using the string 'user@domain' as
password entry. The meaning is not to use
'user@domain' literally as password while accessing the
server (even if this would generally work too since the
software often just checks the presence of an @ sign,)
but to use ones own RFC822 email address.
<FTAM-server> ::= "FTAM-server: " <P-address> "; "\
'account-name' ["; " 'password'] \
["; X.500 " <DirectoryName>] <CR>
The account name is often case sensitive. Some FTAM
Eppenberger [Page 12]
RFC 1465 Routing Coordination for X.400 Services May 1993
servers offer anonymous access with the account-name
ANON. Documenting an FTAM server with a Distinguished
Name is only allowed if the server is registered in the
directory.
<Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' <CR>
Presentation addresses without the usage of macros are
generally unreadable. RFC1278 suggests a few macros.
All macros which are allowed in a community must be
defined in the COMMUNITY document. It is recommended
to use the proposed macros in RFC1278 and add new ones
if necessary:
Macro: Int-X25(80) TELEX+00728722+X.25(80)+01+
Macro: Janet-X25(80) TELEX+00728722+X.25(80)+02+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
<Connections> ::= {<mandatory-service>} \
{[<optional-service>]}
Note that at least one mandatory service type is
needed.
<mandatory-service> ::= "Mandatory-Service: " \
<Service-type> <CR>
<optional-service> ::= "Optional-Service: " \
<Service-type> <CR>
5.3 The RELAY-MTA document
<RELAY-MTA-document> ::= <Community-Identifier> \
<Update-info> \
<RELAY-MTA-document-Identifier> \
<RELAY-MTA-document-body>
A RELAY-MTA document contains the full description of a
single RELAY-MTA. Only one community is allowed.
Since some of the information is community dependent,
it would not be easily possible to have a single
RELAY-MTA document used in different communities.
<RELAY-MTA-document-Identifier> ::= \
"RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>
<RELAY-MTA-document-body> ::= <Status> <connection-info> \
<contact-info>
<Status> ::= "Status: " ("primary" | "secondary") <CR>
This defines if the RELAY-MTA has 'primary' or
Eppenberger [Page 13]
RFC 1465 Routing Coordination for X.400 Services May 1993
'secondary' status. See section 4.3 and 6 for more
information.
<connection-info> ::= <password> <RTS> \
{<called-connection><calling-connection>}\
[<system>] \
[<local-domain>] \
[<echo-server>]
More than one set of connection information may be
present for RELAY-MTAs supporting several networks and
protocol stacks.
<password> ::= "Password: " \
("secret" | "none" | \
"value=\"" 'password' "\"") <CR>
If the keyword none is present, then no password is
sent with the MTAname when this MTA initiates an RTS
connection or responds to an incoming connection.
Password: none
If the keyword secret is present, then the connection
needs a password which is not made publicly available.
(For example, a community might keep a list of the
passwords at the central coordination point. The list
would then be faxed to the RELAY-MTA managers.)
Password: secret
A password must be documented using the
value="password" notation. The double quotes around
the password are needed, consider the case of a single
blank as a password.
Password: value=" "
Password: value="nume-n-ine"
<RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>]
<dialog-mode> ::= "RTS-dialog-mode: " \
("TWA" | "MONOLOGUE") <CR>
<checkpoint-size> ::= "RTS-checkpoint-size: " \
'checkpoint size' <CR>
<window-size> ::= "RTS-window-size: " \
'window size' <CR>
<called-connection> ::= "Called-address: " \
<Service-type> "; " \
Eppenberger [Page 14]
RFC 1465 Routing Coordination for X.400 Services May 1993
<P-address> "; " <MTS> \
["; " <Service-priority>] <CR>
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
MTS-T: mts-transfer
MTS-TP: mts-transfer-protocol
MTS-TP-84: mts-transfer-protocol-1984
See ISO 10021-6, Section 3, chapter 11.1 for more
details on this matter. X.400(84) systems only support
mts-transfer-protocol-1984.
<Service-priority> ::= 'Integer 0..99'
The lowest Integer corresponds to the highest priority
as in DNS. It is possible to set different priorities
for each service type. This may be chosen, for
example, to distribute the load amongst different
networks according to their available bandwidth.
<calling-connection> ::= "Calling-address: " \
<Service-type> "; " \
<P-address> <CR>
Since called and calling network addresses may differ
in certain configurations and some X.400 systems do
validation on calling network addresses, it is
important to have this information in the RELAY-MTA
document. (Note: a calling X.121 address might change
if the X.25 switch is reconfigured. This will stop a
RELAY-MTA from connecting to other RELAY-MTAs using
address validation without having changed anything at
the higher layers!)
<system> ::= "System: HW=" 'computer type' "; " \
"OS=" 'operating system' "; " \
"SW=" 'MHS software' <CR>
It is optional to provide HW/SW information.
Experience, however, has shown that a number of
communication problems were more easily identified and
solved with this information present and up-to-date.
<local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
This is a useful but optional extension to the
documentation.
The <MHS-subtree> is local to the RELAY-MTA. The <MHS-
subtree> attributes might be used together with
S=nosuchuser; to do connectivity and availability
tests.
Eppenberger [Page 15]
RFC 1465 Routing Coordination for X.400 Services May 1993
<echo-server> ::= "EchoServer: " <X.400 address> <CR>
Some of the RELAY-MTAs might offer an echo server
functionality. It does make sense to document this in
the RELAY-MTA document for test purpose. This field is
optional.
<contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
The contact details for the RELAY-MTA administrator can
be found in the appropriate PERSON document. It is
possible to document a whole team using a distribution
list if this is desired. It is generally better to
document one or more 'real' persons.
5.4 The DOMAIN document
<DOMAIN-document> ::= <Community-Identifier> \
<Update-info> \
<DOMAIN-document-body>
<DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
{<Relay>}
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
Note that it is not allowed to have equal <Domain-
entry> lines in different DOMAIN documents belonging to
the same MHS community. A Domain-entry line can only
appear in one DOMAIN document.
<OR-matching> ::= ( "* " | "= " )
This qualifier defines how the following OR address
attributes should be handled for the routing algorithm.
If a '*' is present, a destination address of a message
is matched by the "Domain:" entry if at least the OR
address attributes in the "Domain:" entry are equal to
the destination address.
If a "=" is present, a destination address of a message
is matched by the "Domain:" entry if there are exactly
the same OR attributes in the destination address as in
the "Domain:" entry. (This restriction works for OU4,
OU3, OU2, OU1, O, P, A and C only.)
Example:
a) Domain: * P=switch; A=arcom; C=ch;
b) Domain: = P=switch; A=arcom; C=ch;
The address S=eppenberger; P=switch; A=arcom; C=ch;
matches both cases, a) and b).
The address S=eppenberger; O=unibe; P=switch; A=arcom;
C=ch; matches only case a).
Eppenberger [Page 16]
RFC 1465 Routing Coordination for X.400 Services May 1993
<responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
This is the person responsible for the listed domains.
His task is to get the agreement of the relaying
RELAY-MTAs and keep the DOMAIN document up-to-date.
This person is the only one authorized to make changes
to this document. Note that multiple administrators
may be listed.
<Relay> ::= "Relay: " \
( 'UniqueRELAY-MTAkey' | \
"Internet-SMTP" ) "; " \
<RELAY-MTA-Priority> <CR>
The priority is used to define the sequence in which
different RELAY-MTAs may be tried in case of failure.
A lower integer corresponds to a higher priority as in
DNS. Priorities 0..49 are used to indicate backup
RELAY-MTAs. Priorities 50..99 are used for RELAY-MTAs
not acting as backup but as relay service provider for
a network service type not supported by the main
RELAY-MTA.
The keyword "Internet-SMTP" is a placeholder for an
RFC1327 gateway connected to Internet. The RELAY-MTA
manager selects a gateway of his choice.
<RELAY-MTA-Priority> ::= <Integer 0..99>
5.5 The PERSON document
<PERSON-document> ::= <Community-Identifier> \
<Update-info> \
<PERSON-document-identifier> \
<PERSON-document-body>
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<Phone> <Fax> <Mail> <Operation>
<Name> ::= "Name: " 'name of person' <CR>
The name of the person is given. The issue of the
character set problem is not addressed in this
document. Especially international communities should
restrict themselves to IA5 or ASCII.
<RFC822> ::= "RFC822: " <RFC-822-address> <CR>
This is the RFC-822 address of the person. It is often
a big help to know the RFC822 address of someone, for
example if the X.400 system is not reachable. This is
Eppenberger [Page 17]
RFC 1465 Routing Coordination for X.400 Services May 1993
also the reason why it is possible to provide multiple
OR and RFC822 addresses. The first one is considered
the primary one.
6. Routing rules
All the users within the MHS community have the right to send
messages to each other. The general agreement is that the RELAY-MTA
infrastructure is used according to the following routing rules.
More direct connections based on bilateral agreements are fully
accepted.
A primary or secondary RELAY-MTA must allow incoming connections from
all other primary and secondary RELAY-MTAs with a common stack.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -