/ "Latest-Delivery-Time" ":" date-time
x400-trace = "by" md-and-mta ";"
[ "deferred until" date-time ";" ]
[ "converted" "(" encoded-info ")" ";" ]
[ "attempted" md-or-mta ";" ]
action-list
";" arrival-time
md-and-mta = [ "mta" mta "in" ] global-id
mta = word
arrival-time = date-time
md-or-mta = "MD" global-id
/ "MTA" mta
Action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
dr-body-format = dr-summary <CRLF>
dr-recipients <CRLF>
dr-administrator-info-envelope <CRLF>
dr-content-return
dr-content-return = "The Original Message is not available"
/ "The Original Message follows:"
dr-summary = "This report relates to your message:" <CRLF>
content-correlator <CRLF> <CRLF>
"of" date-time <CRLF> <CRLF>
dr-recipients = *(dr-recipient <CRLF> <CRLF>)
dr-recipient = dr-recip-success / dr-recip-failure
dr-recip-success =
"Your message was successfully delivered to:"
mailbox "at" date-time
dr-recip-failure = "Your message was not delivered to:"
mailbox <CRLF>
"for the following reason:" *word
dr-administrator-info-envelope = 3*( "*" text <CRLF> )
dr-administrator-info =
"**** The following information is directed towards"
"the local administrator" <CRLF>
"**** and is not intended for the end user" <CRLF> <CRLF>
"DR generated by:" report-point <CRLF>
"at" date-time <CRLF> <CRLF>
"Converted to RFC822 at" mta <CRLF>
"at" date-time <CRLF> <CRLF>
"Delivery Report Contents:" <CRLF> <CRLF>
drc-field-list <CRLF>
"***** End of administration information"
drc-field-list = *(drc-field <CRLF>)
drc-field = "Subject-Submision-Identifier" ":"
mts-msg-id
/ "Content-Identifier" ":" printablestring
/ "Content-Type" ":" mts-content-type
/ "Original-Encoded-Information-Types" ":"
encoded-info
/ "Originator-and-DL-Expansion-History" ":"
dl-history
/ "Reporting-DL-Name" ":" mailbox
/ "Content-Correlator" ":" content-correlator
/ "Recipient-Info" ":" recipient-info
/ "Subject-Intermediate-Trace-Information" ":"
x400-trace
recipient-info = mailbox "," std-or ";"
report-type
[ "converted eits" encoded-info ";" ]
[ "originally intended recipient"
mailbox "," std-or ";" ]
[ "last trace" [ encoded-info ] date-time ";" ]
[ "supplementary info" <"> printablestring <"> ";" ]
[ "redirection history" 1#redirection ";"
[ "physical forwarding address"
printablestring ";" ]
report-type = "SUCCESS" drc-success
/ "FAILURE" drc-failure
drc-success = "delivered at" date-time ";"
[ "type of MTS user" labelled-integer ";" ]
drc-failure = "reason" labelled-integer ";"
[ "diagnostic" labelled-integer ";" ]
report-point = [ "mta" word "in" ] global-id
content-correlator = *word
dl-history = 1#( mailbox "(" date-time ")")
mts-field = "X400-MTS-Identifier" ":" mts-msg-id
/ "X400-Originator" ":" mailbox
/ "X400-Recipients" ":" 1#mailbox
/ "Original-Encoded-Information-Types" ":"
encoded-info
/ "X400-Content-Type" ":" mts-content-type
/ "Content-Identifier" ":" printablestring
/ "Priority" ":" priority
/ "Originator-Return-Address" ":" 1#mailbox
/ "DL-Expansion-History" ":" mailbox ";" date-time ";"
/ "Conversion" ":" prohibition
/ "Conversion-With-Loss" ":" prohibition
/ "Requested-Delivery-Method" ":"
1*( labelled-integer )
/ "Delivery-Date" ":" date-time
/ "Discarded-X400-MTS-Extensions" ":"
1#( oid / labelled-integer )
prohibition = "Prohibited" / "Allowed"
mts-msg-id = "[" global-id ";" *text "]"
mts-content-type = "P2" / labelled-integer
/ object-identifer
priority = "normal" / "non-urgent" / "urgent"
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
[ ipn-content-return ]
ipn-description = ipn-receipt / ipn-non-receipt
ipn-receipt = "Your message to:" preferred-recipient <CRLF>
"was received at" receipt-time <CRLF> <CRLF>
"This notification was generated"
acknowledgement-mode <CRLF>
"The following extra information was given:" <CRLF>
ipn-suppl <CRLF>
ipn-non-receipt "Your message to:"
preferred-recipient <CRLF>
ipn-reason
ipn-reason = ipn-discarded / ipn-auto-forwarded
ipn-discarded = "was discarded for the following reason:"
discard-reason <CRLF>
ipn-auto-forwarded = "was automatically forwarded." <CRLF>
[ "The following comment was made:"
auto-comment ]
ipn-extra-information =
"The following information types were converted:"
encoded-info
ipn-content-return = "The Original Message is not available"
/ "The Original Message follows:"
<CRLF> <CRLF> message
preferred-recipient = mailbox
receipt-time = date-time
auto-comment = printablestring
ipn-suppl = printablestring
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated"
acknowledgement-mode = "Manually" / "Automatically"
ipms-field = "Obsoletes" ":" 1#msg-id
/ "Expiry-Date" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Language" ":" language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":" 1#oid
importance = "low" / "normal" / "high"
sensitivity = "Personal" / "Private" /
"Company-Confidential"
language = 2*ALPHA [ language-description ]
language-description = printable-string
message-type = "Delivery Report"
/ "InterPersonal Notification"
/ "Multiple Part"
redirect-comment =
[ "Originally To:" ] mailbox "Redirected"
[ "Again" ] "on" date-time
"To:" redirection-reason
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
subject-line = "Delivery-Report" "(" status ")"
[ "for" destination ]
status = "success" / "failure" / "success and failures"
destination = mailbox / "MTA" word
extended-heading =
"Prevent-NonDelivery-Report" ":"
/ "Generate-Delivery-Report" ":"
/ "Alternate-Recipient" ":" prohibition
/ "Disclose-Recipients" ":" prohibition
/ "Content-Return" ":" prohibition
Appendix F - Format of address mapping tables
1. Global Mapping Information
The consistent operation of gateways which follow this
specification relies of the existence of three globally defined
mappings:
1. Domain Name Space -> O/R Address Space
2. O/R Address Space -> Domain Name Space
3. Domain Name Space -> O/R Address of preferred gateway
All gateways conforming to this specification shall have access to
these mappings. The gateway may use standardised or private
mechanisms to access this mapping information.
One means of distributing this information is in three files.
This appendix defines a format for these files. Other
standardised mechanisms to distribute the mapping information are
expected. In particular, mechanisms for using the Domain Name
Scheme, and X.500 are planned.
The definition of global mapping information is being co-
ordinated by the COSINE-MHS project, on behalf of the Internet and
other X.400 and RFC822 users. For information on accessing this
information contact:
COSINE MHS Project Team
SWITCH
Weinbergstrasse 18
8001 Zuerich
Switzerland
tel: +41 1 262 3143
fax: +41 1 262 3151
email:
C=ch;ADMD=arcom;PRMD=switch;O=switch;OU=cosine-mhs;
S=project-team
or
project-team@cosine-mhs.switch.ch
2. Syntax Definitions
An address syntax is defined, which is compatible with the syntax
used for 822.domains. By representing the O/R addresses as
domains, all lookups can be mechanically implemented as domain ->
domain mappings. This syntax defined is initially for use in
table format, but the syntax is defined in a manner which makes it
suitable to be adapted for use with the Domain Name Service.
This syntax allows for a general representation of O/R addresses,
so that it can be used in other applications. Not all attributes
are used in the table formats defined.
To allow the mapping of null attributes to be represented, the
pseudo-value "@" (not a printable string character) is used to
indicate omission of a level in the hierarchy. This is distinct
from the form including the element with no value, although a
correct X.400 implementation will interpret both in the same
manner.
This syntax is not intended to be handled by users.
dmn-or-address = dmn-part *( "." dmn-part )
dmn-part = attribute "$" value
attribute = standard-type
/ "~" dmn-printablestring
value = dmn-printablestring
/ "@"
dmn-printablestring =
= *( dmn-char / dmn-pair )
dmn-char = <"{", "}", "*", and any ps-char
except ".">
dmn-pair = "\."
An example usage:
~ROLE$Big\.Chief.ADMD$ATT.C$US
PRMD$DEC.ADMD$@.C$US
The first example illustrates quoting of a ".", and the second
omission of the ADMD level. There must be a strict ordering of all
components in this table, with the most significant components on
the RHS. This allows the encoding to be treated as a domain.
Various further restrictions are placed on the usage of dmn-or-
address in the address space mapping tables.
1. Only C, ADMD, PRMD, O, and up to four OUs may be used.
2. No components shall be omitted from this hierarchy, although
the hierarchy may terminate at any level. If the mapping is
to an omitted component, the "@" syntax is used.
3. Table Lookups
When determining a match, there are aspects which apply to all
lookups. Matches are always case independent. The key for all
three tables is a domain. The longest possible match shall be
obtained. Suppose the table has two entries with the following
keys:
K.L
J.K.L
Domain "A.B.C" will not return any matches. Domain "I.J.K.L" will
match the entry "J.K.L:.
4. Domain -> O/R Address format
The BNF is:
domain-syntax "#" dmn-or-address "#"
Note that the trailing "#" is used for clarity, as the dmn-or-
address syntax might lead to values with trailing blanks. Lines
staring with "#" are comments.
For example:
AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB#
XEROX.COM#O$Xerox.ADMD$ATT.C$US#
GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE#
A domain is looked up to determine the top levels of an O/R
Address. Components of the domain which are not matched are used
to build the remainder of the O/R address, as described in Section
4.3.4.
5. O/R Address -> Domain format
The syntax of this table is:
dmn-or-address "#" domain-syntax "#"
For example:
#
# Mapping table
#
PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK#
The O/R Address is used to generate a domain key. It is important
to order the components correctly, and to fill in missing
components in the hierarchy. Use of this mapping is described in
Section 4.3.2.
6. Domain -> O/R Address of Gateway table
This uses the same format as the domain -> O/R address mapping.
In this case, the two restrictions (omitted components and
restrictions on components) do not apply. Use of this mapping is
described in Section 4.3.4.
Appendix G - Mapping with X.400(1984)
This appendix defines modification to the mapping for use with
X.400(1984).
The X.400(1984) protocols are a proper subset of X.400(1988). When
mapping from X.400(1984) to RFC822, no changes to this specification
are needed.
When mapping from RFC822 to X.400(1984), no use can be made of 1988
specific features. No use of such features is made at the MTS
level. One feature is used at the IPMS level, and this must be
replaced by the RFC987 approach. All header information which would
usually be mapped into the rfc-822-heading-list extension, together
with any Comments: field in the RFC822 header is mapped into a
single IA5 body part, which is the first body part in the message.
This body part will start with the string "RFC-822-Headers:" as the
first line. The headers then follow this line. This specification
requires correct reverse mapping of this format, either from 1988 or
1984.
In an environment where RFC822 is of major importance, it may be
desirable for downgrading to consider the case where the message was
originated in an RFC822 system, and mapped according to this
specification. The rfc-822-heading-list extension may be mapped
according to this appendix.
When parsing std-or, the following restrictions must be observed:
- Only the 84/88 attributes identified in the table in
Section 4.2 are present.
- No teletex encoding is allowed.
If an address violates this, it should be treated as an RFC822
address, which will usually lead to encoding as a DDA "RFC-822".
It is possible that null attributes may be present in an O/R Address.
This is not legal in 1988, except for ADMD where the case is
explicitly described in Section 4.3.5. Null attributes are
deprecated (the attribute should be omitted), and should therefore be
unusual. However, some systems generate them and rely on them.
Therefore, any null attribute shall be enoded using the std-or
encoding (e.g., /O=/).
If a non-Teletex Common Name (CN) is present, it should be mapped
onto a Domain Defined Attribute "Common". This is in line with RFC
1328 on X.400 1988 to 1984 downgrading [Hardcastle-K92].
Appendix H - RFC822 Extensions for X.400 access
This appendix defines a number of optional mappings which may be
provided to give access from RFC822 to a number of X.400 services.
These mappings are beyond the basic scope of this specification.
There has been a definite demand to use extended RFC822 as a
mechanism to acccess X.400, and these extensions provide access to
certain features. If this functionality is provided, this appendix
shall be followed. The following headings are defined:
extended-heading =
"Prevent-NonDelivery-Report" ":"
/ "Generate-Delivery-Report" ":"
/ "Alternate-Recipient" ":" prohibition
/ "Disclose-Recipients" ":" prohibition
/ "Content-Return" ":" prohibition
Prevent-NonDelivery-Report and Generate-Delivery-Report allow setting
of MTS.PerRecipientSubmissionFields.originator-report-request. The
setting will be the same for all recipients.
Alternate-Recipient, Disclose-Recipients, and Content-Return allow
for override of the default settings for MTS.PerMessageIndicators.
Appendix I - Conformance
This appendix defines a number of options, which a conforming gateway
should specify. Conformance to this specification shall not be
claimed if any of the mandatory features are not implemented. In
particular:
- Formats for all fields shall be followed.
- Formats for subject lines, delivery reports and IPNs shall
be followed. A system which followed the syntax, but
translated text into a language other than english would be
conformant.
- RFC1137 shall not be followed when mapping to SMTP or to
JNT Mail
- All mappings of trace shall be implemented.
- There must be a mechanism to access all three global
mappings.
A gateway should specify:
- Which 822-MTS protocols are supported. The relevant
appendices must be followed to claim support of a given
protocol: SMTP (A); JNT Mail (B); UUCP (C).
- Which X.400 versions are supported (84 and/or 88).
- The means by which it can access the global mappings.
Currently, the tables of the formats define in Appendix F
is the only means available.
- The approach taken when upper bounds are exceeded at the IPM
level (5.1.3)
- The approach taken to return of contents (5.2)
- The approach taken to body parts which cannot be converted
(5.3.4)
- The approach taken to multiple copies vs non-disclosure
(4.6.2.2)
The following are optional parts of this specification. A conforming
implementation should specify which of these it supports.
- Generation of extended RFC822 fields is mandatory.
Optionally, they may be parsed and mapped back to X.400. A
gateway should should indicate if this is done.
- Support for the extension mappings of Appendix H.
- Support for returning illegal format content in a delivery
report
- Which address interpretation heuristics are supported
(4.3.4.1)
- If RFC987 generated message ids are handled in a backwards
compatible manner (4.7.3.6)
Appendix J - Change History: RFC987, 1026, 1138, 1148
RFC987 was the original document, and contained the key elements of
this specification. It was specific to X.400(1984). RFC1026
specified a small number of necessary changes to RFC987.
RFC1138 was based on the RFC987 work. It contained an editorial
error, and was reissued a few months later as RFC1148. RFC1148
will be referred to here, as it is the document which is widely
referred to elsewhere. The major goal of RFC1148 was to upgrade RFC
987 to X.400(1988). It did this, but did not obsolete RFC987, which
was recommended for use with X.400(1984). This appendix summarises
the changes made in going from RFC987 to RFC1148.
RFC1148 noted the following about its upgrade from RFC987:
Unnecessary change is usually a bad idea. Changes on the RFC822
side are avoided as far as possible, so that RFC822 users do not
see arbitrary differences between systems conforming to this
specification, and those following RFC987. Changes on the X.400
side are minimised, but are more acceptable, due to the mapping onto
a new set of services and protocols.
1. Introduction
The model has shifted from a protocol based mapping to a service
based mapping. This has increased the generality of the
specification, and improved the model. This change affects the
entire document.
A restriction on scope has been added.
2. Service Elements
- The new service elements of X.400 are dealt with.
- A clear distinction is made between origination and
reception
3. Basic Mappings
- Add teletex support
- Add object identifier support
- Add labelled integer support
- Make PrintableString <-> ASCII mapping reversible
- The printable string mapping is aligned to the NBS mapping
derived from RFC987.
4. Addressing
- Support for new addressing attributes
- The message ID mapping is changed to not be table driven
5. Detailed Mappings
- Define extended IPM Header, and use instead of second body
part for RFC822 extensions
- Realignment of element names
- New syntax for reports, simplifying the header and
introducing a mandatory body format (the RFC987 header
format was unusable)
- Drop complex autoforwarded mapping
- Add full mapping for IP Notifications, defining a body
format
- Adopt an MTS Identifier syntax in line with the O/R Address
syntax
- A new format for X400 Trace representation on the RFC822
side
6. Appendices
- Move Appendix on restricted 822 mappings to a separate RFC
- Delete Phonenet and SMTP Appendixes
Appendix K - Change History: RFC1148 to this Document
1. General
- The scope of the document was changed to cover X.400(1984),
and so obsolete RFC987.
- Changes were made to allow usage to connect RFC822 networks
using X.400
- Text was tightened to be clear about optional and mandatory
aspects
- A good deal of clarification
- A number of minor EBNF errors
- Better examples are given
- Further X.400 upper bounds are handled correctly
2. Basic Mappings
- The encoding of object identifier is changed slightly
3. Addressing
- A global mapping of domain to preferred gateway is
introduced.
- An overflow mechanism is defined for RFC822 addresses of
greater than 128 bytes.
- Changes were made to improve compatability with the PDAM on
writing O/R Addresses.
+ The PD and Terminal Type keywords were aligned to the
PDAM. It is believed that minimal use has been made of
the RFC1148 keywords.
+ P and A are allowed as alternate keys for PRMD and ADMD
+ Where keywords are different, the PDAM keywords are
alternatives on input. This is mandatory.
4. Detailed Mappings
- The format of the Subject: lines is defined.
- Illegal use (repetition) of the heading EXTENSION is
corrected, and a new object identifier assigned.
- The Delivery Report format is extensively revised in light
of operational experience.
- The handling of redirects is significantly changed, as the
previous mechanism did not work.
5. Appendices
- An SMTP appendix is added, allowing optional use of the VRFY
command to improve probe information.
- Handling of JNT Mail Acknowledge-To is changed slightly.
- A DDA JNT-MAIL is allowed on input.
- The format definitions of Appendix F are explained further,
and a third table definition added.
- An appendix on use with X.400(1984) is added.
- Optional extensions are defined to give RFC822 access to
further X.400 facilities.
- An appendix on conformance is added.
References
CCITT88a.
CCITT, "CCITT Recommendations X.408," Message Handling
Systems: Encoded Information Type Conversion Rules, December
1988.
CCITT/ISO88a.
CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
Message Handling: System and Service Overview , December
1988.
CCITT/ISO88b.
CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7,"
Message Handling Systems: Interpersonal Messaging System,
December 1988.
CCITT/ISO88c.
CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-4,"
Message Handling Systems: Message Transfer System: Abstract
Service Definition and Procedures, December 1988.
CCITT/ISO88d.
CCITT/ISO, "Specification of Abstract Syntax Notation One
(ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December
1988.
CCITT/ISO91a.
CCITT/ISO, "Representation of O/R Addresses for Human
Usage," PDAM to CCITT X.401 / ISO/IEC 10021-2, February
1991.
Crocker82a.
Crocker, D., "Standard of the Format of ARPA Internet Text
Messages," RFC822, UDEL, August 1982.
Hardcastle-K92.
Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading," RFC
1328, UCL, May 1992.
Horton86a.
Horton, M., "UUCP Mail Interchange Format Standard," RFC
976, February 1986.
Kille84b.
Kille, S., "Gatewaying between RFC822 and JNT Mail," JNT
Mailgroup Note 15, May 1984.
Kille84a.
Kille, S., (Editor), JNT Mail Protocol (revision 1.0), Joint
Network Team, Rutherford Appleton Laboratory, March 1984.
Kille86a.
Kille, S., "Mapping Between X.400 and RFC822," UK Academic
Community Report (MG.19) / RFC987, June 1986.
Kille87a.
Kille, S., "Addendum to RFC987," UK Academic Community
Report (MG.23) / RFC1026, August 1987.
Kille89a.
Kille, S., "A String Encoding of Presentation Address," UCL
Research Note 89/14, March 1989.
Kille89b.
Kille, S., "Mapping between full RFC822 and RFC822 with
restricted encoding," RFC1137, October 1989.
Kille90a.
Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822," RFC1148, March 1990.
Larmouth83a.
Larmouth, J., "JNT Name Registration Technical Guide,"
Salford University Computer Centre, April 1983.
Postel84a.
Postel J., and J. Reynolds, "Domain Requirements," RFC920,
USC/Information Sciences Institute, October 1984.
Postel82a.
Postel, J., "Simple Mail Transfer Protocol", RFC821,
USC/Information Sciences Institute, August 1982.
Rose85a.
Rose M., and E. Stefferud, "Proposed Standard for Message
Encapsulation," RFC934, January 1985.
Systems85a.
CEN/CENELEC/Information Technology/Working Group on Private
Message Handling Systems, "FUNCTIONAL STANDARD A/3222,"
CEN/CLC/IT/WG/PMHS N 17, October 1985.
SECURITY CONSIDERATIONS
Security issues are not discussed in this memo.
AUTHOR'S ADDRESS
Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK