RFC 1327
Mapping between X.400(1988) / ISO 10021 and RFC 822
Pages: 113
Obsoletes: 0987 1026 1138 1148
Obsoleted by: 2156
Updates: 0822
Updated by: 1495
Obsoletes: 0987 1026 1138 1148
Obsoleted by: 2156
Updates: 0822
Updated by: 1495
Part 3 of 4 – Pages 59 to 91
Chapter 5 - Detailed Mappings This chapter specifies detailed mappings for the functions outlined in Chapters 1 and 2. It makes extensive use of the notations and mappings defined in Chapters 3 and 4. 5.1. RFC 822 -> X.400 5.1.1. Basic Approach A single IP Message is generated from an RFC 822 message The RFC 822 headers are used to generate the IPMS.Heading. The IP Message will have one IA5 IPMS.BodyPart containing the RFC 822 message body. Some RFC 822 fields cannot be mapped onto a standard IPM Heading field, and so an extended field is defined in Section 5.1.2. This is then used for fields which cannot be mapped onto existing services. The message is submitted to the MTS, and the services required can be defined by specifying MTS.MessageSubmissionEnvelope. A few parameters of the MTA Abstract service are also specified, which are not in principle available to the MTS User. Use of these services allows RFC 822 MTA level parameters to be carried in the analogous X.400 service elements. The advantages of this mapping far outweigh the layering violation. 5.1.2. X.400 Extension Field An IPMS Extension is defined: rfc-822-field HEADING-EXTENSION VALUE RFC822FieldList ::= id-rfc-822-field-list
RFC822FieldList ::= SEQUENCE OF RFC822Field
RFC822Field ::= IA5String
The Object Identifier id-rfc-822-field-list is defined in Appendix D.
To encode any RFC 822 Header using this extension, an RFC822Field
element is built using the 822.field omitting the trailing CRLF
(e.g., "Fruit-Of-The-Day: Kiwi Fruit"). Structured fields shall be
unfolded. There shall be no space before the ":". The reverse
mapping builds the RFC 822 field in a straightforward manner. This
RFC822Field is appended to the RFC822FieldList, which is added to the
IPM Heading as an extension field.
5.1.3. Generating the IPM
The IPM (IPMS Service Request) is generated according to the rules of
this section. The IPMS.IPM.body usually consists of one IPMS.BodyPart
of type IPMS.IA5TextBodyPart with
IPMS.IA5TextBodyPart.parameters.repertoire set to the default (ia5)
which contains the body of the RFC 822 message. The exception is
where there is a "Comments:" field in the RFC 822 header.
If no specific 1988 features are used, the IPM generated is encoded
as content type 2. Otherwise, it is encoded as content type 22. The
latter will always be the case if extension heading fields are
generated.
When generating the IPM, the issue of upper bounds must be
considered. At the MTS and MTA level, this specification is strict
about enforcing upper bounds. Three options are available at the IPM
level. Use of any of these options conforms to this standard.
1. Ignore upper bounds, and generate messages in the natural
manner. This assumes that if any truncation is done, it
will happen at the recipient UA. This will maximise
transfer of information, but is likely break some recipient
UAs.
2. Reject any inbound message which would cause a message
violating constraints to be generated. This will be robust,
but may prevent useful communication.
3. Truncate fields to the upper bounds specified in X.400.
This will prevent problems with UAs which enforce upper
bounds, but will sometimes discard useful information.
If the Free Form name is truncated, it may lead to breaking
RFC 822 comments, which will cause an awkward reverse
mapping.
These options have different advantages and disadvantages, and the
choice will depend on the exact application of the gateway.
The rest of this section concerns IPMS.IPM.heading (IPMS.Heading).
The only mandatory component of IPMS.Heading is the
IPMS.Heading.this-IPM (IPMS.IPMIdentifier). A default is generated
by the gateway. With the exception of "Received:", the values of
multiple fields are merged (e.g., If there are two "To:" fields, then
the mailboxes of both are merged to generate a single list which is
used in the IPMS.Heading.primary-recipients. Information shall be
generated from the standard RFC 822 Headers as follows:
Date:
Ignore (Handled at MTS level)
Received:
Ignore (Handled at MTA level)
Message-Id:
Mapped to IPMS.Heading.this-IPM. For these, and all other
fields containing 822.msg-id the mappings of Chapter 4 are
used for each 822.msg-id.
From:
If Sender: is present, this is mapped to
IPMS.Heading.authorizing-users. If not, it is mapped to
IPMS.Heading.originator. For this, and other components
containing addresses, the mappings of Chapter 4 are used for
each address.
Sender:
Mapped to IPMS.Heading.originator.
Reply-To:
Mapped to IPMS.Heading.reply-recipients.
To: Mapped to IPMS.Heading.primary-recipients
Cc: Mapped to IPMS.Heading.copy-recipients.
Bcc: Mapped to IPMS.Heading.blind-copy-recipients if there is at
least one BCC: recipient. If there are no recipients in
this field, it should be mapped to a zero length sequence.
In-Reply-To:
If there is one value, it is mapped to
IPMS.Heading.replied-to-IPM, using the 822.phrase or
822.msg-id mapping as appropriate. If there are several
values, they are mapped to IPMS.Heading.related-IPMs, along
with any values from a "References:" field.
References:
Mapped to IPMS.Heading.related-IPMs.
Keywords:
Mapped onto a heading extension.
Subject:
Mapped to IPMS.Heading.subject. The field-body uses the
human oriented mapping referenced in Chapter 3 from ASCII to
T.61.
Comments:
Generate an IPMS.BodyPart of type IPMS.IA5TextBodyPart with
IPMS.IA5TextBodyPart.parameters.repertoire set to the
default (ia5), containing the value of the fields, preceded
by the string "Comments: ". This body part shall precede
the other one.
Encrypted:
Mapped onto a heading extension.
Resent-*
Mapped onto a heading extension.
Note that it would be possible to use a ForwardedIPMessage
for these fields, but the semantics are (arguably) slightly
different, and it is probably not worth the effort.
Other Fields
In particular X-* fields, and "illegal" fields in common
usage (e.g., "Fruit-of-the-day:") are mapped onto a heading
extension, unless covered by another section or appendix of
this specification. The same treatment is applied to RFC
822 fields where the content of the field does not conform
to RFC 822 (e.g., a Date: field with unparseable syntax).
5.1.4. Mappings to the MTS Abstract Service
The MTS.MessageSubmissionEnvelope comprises
MTS.PerMessageSubmissionFields, and
MTS.PerRecipientMessageSubmissionFields. The mandatory parameters
are defaulted as follows.
MTS.PerMessageSubmissionFields.originator-name
This is always generated from 822-MTS, as defined in
Chapter 4.
MTS.PerMessageSubmissionFields.content-type
Set to the value implied by the encoding of the IPM (2 or
22).
MTS.PerRecipientMessageSubmissionFields.recipient-name
These will always be supplied from 822-MTS, as defined in
Chapter 4.
Optional components are omitted, and default components defaulted.
This means that disclosure of recipients is prohibited and conversion
is allowed. There are two exceptions to the defaulting. For
MTS.PerMessageSubmissionFields.per-message-indicators, the following
settings are made:
- Alternate recipient is allowed, as it seems desirable to
maximise the opportunity for (reliable) delivery.
- Content return request is set according to the issues
discussed in Section 5.2.
MTS.PerMessageSubmissionFields.original-encoded-information-types is
a set of one element BuiltInEncodedInformationTypes.ia5-text.
The MTS.PerMessageSubmissionFields.content-correlator is encoded as
IA5String, and contains the Subject:, Message-ID:, Date:, and
To: fields (if present). This includes the strings "Subject:",
"Date:", "To:", "Message-ID:", and appropriate folding. This shall
be truncated to MTS.ub-content-correlator-length (512) characters.
In addition, if there is a "Subject:" field, the
MTS.PerMessageSubmissionFields.content-identifier, is set to a
printable string representation of the contents of it. If the
length of this string is greater than MTS.ub-content-id-length (16),
it should be truncated to 13 characters and the string "..."
appended. Both are used, due to the much larger upper bound of the
content correlator, and that the content id is available in
X.400(1984).
5.1.5. Mappings to the MTA Abstract Service
There is a need to map directly onto some aspects of the MTA Abstract
service, for the following reasons:
- So the the MTS Message Identifier can be generated from the
RFC 822 Message-ID:.
- So that the submission date can be generated from the
822.Date.
- To prevent loss of trace information
- To prevent RFC 822/X.400 looping caused by distribution
lists or redirects
The following mappings are defined.
Message-Id:
If this is present, the
MTA.PerMessageTransferFields.message-identifier is generated
from it, using the mappings described in Chapter 4.
Date:
This is used to set the first component of
MTA.PerMessageTransferFields.trace-information
(MTA.TraceInformationElement). The 822-MTS originator is
mapped into an MTS.ORAddress, and used to derive
MTA.TraceInformationElement.global-domain-identifier. The
optional components of
MTA.TraceInformationElement.domain-supplied-information are
omitted, and the mandatory components are set as follows:
MTA.DomainSuppliedInformation.arrival-time
This is set to the date derived from Date:
MTA.DomainSuppliedInformation.routing-action
Set to relayed.
The first element of
MTA.PerMessageTransferFields.internal-trace-information is
generated in an analogous manner, although this can be
dropped later in certain circumstances (see the procedures
for "Received:"). The
MTA.InternalTraceInformationElement.mta-name is derived from
the 822.domain in the 822 MTS Originator address.
Received:
All RFC 822 trace is used to derive
MTA.PerMessageTransferFields.trace-information and
MTA.PerMessageTransferFields.internal-trace-information.
Processing of Received: lines follows processing of Date:,
and is be done from the the bottom to the top of the RFC 822
header (i.e., in chronological order). When other trace
elements are processed (X400-Received: in all cases and Via:
if Appendix B is supported), the relative ordering shall be
retained correctly. The initial element of
MTA.PerMessageTransferFields.trace-information will be
generated already (from Date:), unless the message has
previously been in X.400, when it will be derived from the
X.400 trace information.
Consider the Received: field in question. If the "by" part
of the received is present, use it to derive an
MTS.GlobalDomainIdentifier. If this is different from the
one in the last element of
MTA.PerMessageTransferFields.trace-information
(MTA.TraceInformationElement.global-domain-identifier)
create a new MTA.TraceInformationElement, and optionally
remove
MTA.PerMessageTransferFields.internal-trace-information.
This removal shall be done in cases where the message is
being transferred to another MD where there is no bilateral
agreement to preserve internal trace beyond the local MD.
The trace creation is as for internal trace described below,
except that no MTA field is needed.
Then add a new element (MTA.InternalTraceInformationElement)
to MTA.PerMessageTransferFields.internal-trace-information,
creating this if needed. This shall be done, even if
inter-MD trace is created. The
MTA.InternalTraceInformationElement.global-domain-identifier
is set to the value derived. The
MTA.InternalTraceInformationElement.mta-supplied-information
(MTA.MTASuppliedInformation) is set as follows:
MTA.MTASuppliedInformation.arrival-time
Derived from the date of the Received: line
MTA.MTASuppliedInformation.routing-action
Set to relayed
The MTA.InternalTraceInformationElement.mta-name is taken
from the "by" component of the "Received:" field, truncated
to MTS.ub-mta-name-length (32). For example:
Received: from computer-science.nottingham.ac.uk by
vs6.Cs.Ucl.AC.UK via Janet with NIFTP id aa03794;
28 Mar 89 16:38 GMT
Generates the string
vs6.Cs.Ucl.AC.UK
Note that before transferring the message to some ADMDs, additional
trace stripping may be required, as the implied path through multiple
MDs would violate ADMD policy. This will depend on bilateral
agreement with the ADMD.
5.1.6. Mapping New Fields
This specification defines a number of new fields for Reports,
Notifications and IP Messages in Section 5.3. As this specification
only aims to preserve existing services, a gateway conforming to this
specification does not need to map all of these fields to X.400.
Two extended fields must be mapped, in order to prevent looping.
"DL-Expansion-History:" is mapped to
MTA.PerMessageTransferFields.extensions.dl-expansion-history X400-
Received: must be mapped to MTA.PerMessageTransferFields.trace-
information and MTA.PerMessageTransferFields.internal-trace-
information. In cases where X400-Received: is present, the usual
mapping of Date: to generate the first element of trace should not be
done. This is because the message has come from X.400, and so the
first element of trace can be taken from the first X400-Received:.
Some field that shall not be mapped, and should be discarded. The
following cannot be mapped back:
- Discarded-X400-MTS-Extensions:
- Message-Type:
- Discarded-X400-IPMS-Extensions:
If Message-Type: is set to "Multiple Part", then the messge is
encoded according to RFC 934, and this may be mapped on to the
corresponding X.400 structures.
The following may cause problems, due to other information not being
mapped back (e.g., extension numbers), or due to changes made on the
RFC 822 side due to list expansion:
- X400-Content-Type:
- X400-Originator:
- X400-Recipients: - X400-MTS-Identifier: Other fields may be either discarded or mapped to X.400. It is usually desirable and beneficial to do map, particularly to facilitate support of a message traversing multiple gateways. These mappings may be onto MTA, MTS, or IPMS services. The level of support for this reverse mapping should be indicated in the gateway conformace statement. 5.2. Return of Contents It is not clear how widely supported the X.400 return of contents service will be. Experience with X.400(1984) suggests that support of this service may not be universal. As this service is expected in the RFC 822 world, two approaches are specified. The choice will depend on the use of X.400 return of contents withing the X.400 community being serviced by the gateway. In environments where return of contents is widely supported, content return can be requested as a service. The content return service can then be passed back to the end (RFC 822) user in a straightforward manner. In environments where return of contents is not widely supported, a gateway must make special provision to handle return of contents. For every message passing from RFC 822 -> X.400, content return request will not be requested, and report request always will be. When the delivery report comes back, the gateway can note that the message has been delivered to the recipient(s) in question. If a non-delivery report is received, a meaningful report (containing some or all of the original message) can be sent to the 822-MTS originator. If no report is received for a recipient, a (timeout) failure notice shall be sent to the 822-MTS originator. The gateway may retransmit the X.400 message if it wishes. When this approach is taken, routing must be set up so that error reports are returned through the same MTA. This approach may be difficult to use in conjunction with some routing strategies. 5.3. X.400 -> RFC 822 5.3.1. Basic Approach A single RFC 822 message is generated from the incoming IP Message, Report, or IP Notification. All IPMS.BodyParts are mapped onto a single RFC 822 body. Other services are mapped onto RFC 822 header fields. Where there is no appropriate existing field, new fields are
defined for IPMS, MTS and MTA services. The gateway mechanisms will correspond to MTS Delivery. As with submission, there are aspects where the MTA (transfer) services are also used. In particular, there is an optimisation to allow for multiple 822-MTS recipients. 5.3.2. RFC 822 Settings An RFC 822 Service requires to have a number of mandatory fields in the RFC 822 Header. Some 822-MTS services mandate specification of an 822-MTS Originator. Even in cases where this is optional, it is usually desirable to specify a value. The following defaults are defined, which shall be used if the mappings specified do not derive a value: 822-MTS Originator If this is not generated by the mapping (e.g., for a Delivery Report), a value pointing at a gateway administrator shall be assigned. Date: A value will always be generated From:If this is not generated by the mapping, it is assigned equal to the 822-MTS Originator. If this is gateway generated, an appropriate 822.phrase shall be added. At least one recipient field If no recipient fields are generated, a field "To: list:;", shall be added. This will ensure minimal RFC 822 compliance. When generating RFC 822 headers, folding may be used. It is recommended to do this, following the guidelines of RFC 822. 5.3.3. Basic Mappings 5.3.3.1. Encoded Information Types This mapping from MTS.EncodedInformationTypes is needed in several disconnected places. EBNF is defined as follows: encoded-info = 1#encoded-type encoded-type = built-in-eit / object-identifier built-in-eit = "Undefined" ; undefined (0)
/ "Telex" ; tLX (1)
/ "IA5-Text" ; iA5Text (2)
/ "G3-Fax" ; g3Fax (3)
/ "TIF0" ; tIF0 (4)
/ "Teletex" ; tTX (5)
/ "Videotex" ; videotex (6)
/ "Voice" ; voice (7)
/ "SFD" ; sFD (8)
/ "TIF1" ; tIF1 (9)
MTS.EncodedInformationTypes is mapped onto EBNF.encoded-info.
MTS.EncodedInformationTypes.non-basic-parameters is ignored. Built
in types are mapped onto fixed strings (compatible with X.400(1984)
and RFC 987), and other types are mapped onto EBNF.object-identifier.
5.3.3.2. Global Domain Identifier
The following simple EBNF is used to represent
MTS.GlobalDomainIdentifier:
global-id = std-or-address
This is encoded using the std-or-address syntax, for the attributes
within the Global Domain Identifier.
5.3.4. Mappings from the IP Message
Consider that an IPM has to be mapped to RFC 822. The IPMS.IPM
comprises an IPMS.IPM.heading and IPMS.IPM.body. The heading is
considered first. Some EBNF for new fields is defined:
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"
The mappings and actions for the IPMS.Heading is now specified for
each element. Addresses, and Message Identifiers are mapped
according to Chapter 4. Other mappings are explained, or are
straightforward (algorithmic). If a field with addresses contains
zero elements, it should be discarded, execpt for
IPMS.Heading.blind-copy-recipients, which can be mapped onto BCC:
(the only RFC 822 field which allows zero recipients).
IPMS.Heading.this-IPM
Mapped to "Message-ID:".
IPMS.Heading.originator
If IPMS.Heading.authorizing-users is present this is mapped
to Sender:, if not to "From:".
IPMS.Heading.authorizing-users
Mapped to "From:".
IPMS.Heading.primary-recipients
Mapped to "To:".
IPMS.Heading.copy-recipients
Mapped to "Cc:".
IPMS.Heading.blind-copy-recipients
Mapped to "Bcc:".
IPMS.Heading.replied-to-ipm
Mapped to "In-Reply-To:".
IPMS.Heading.obsoleted-IPMs
Mapped to the extended RFC 822 field "Obsoletes:"
IPMS.Heading.related-IPMs
Mapped to "References:".
IPMS.Heading.subject
Mapped to "Subject:". The contents are converted to ASCII
(as defined in Chapter 3). Any CRLF are not mapped, but are
used as points at which the subject field must be folded.
IPMS.Heading.expiry-time
Mapped to the extended RFC 822 field "Expiry-Date:".
IPMS.Heading.reply-time
Mapped to the extended RFC 822 field "Reply-By:".
IPMS.Heading.reply-recipients
Mapped to "Reply-To:".
IPMS.Heading.importance
Mapped to the extended RFC 822 field "Importance:".
IPMS.Heading.sensitivity
Mapped to the extended RFC 822 field "Sensitivity:".
IPMS.Heading.autoforwarded
Mapped to the extended RFC 822 field "Autoforwarded:".
The standard extensions (Annex H of X.420 / ISO 10021-7) are
mapped as follows:
incomplete-copy
Mapped to the extended RFC 822 field "Incomplete-Copy:".
language
Mapped to the extended RFC 822 field "Language:", filling in
the two letter code. The language-description may filled in
with a human readable description of the language, and it is
recommended to do this.
If the RFC 822 extended header is found, this shall be mapped onto an
RFC 822 header, as described in Section 5.1.2.
If a non-standard extension is found, it shall be discarded, unless
the gateway understands the extension and can perform an appropriate
mapping onto an RFC 822 header field. If extensions are discarded,
the list is indicated in the extended RFC 822 field "Discarded-X400-
IPMS-Extensions:".
The IPMS.Body is mapped into the RFC 822 message body. Each
IPMS.BodyPart is converted to ASCII as follows:
IPMS.IA5Text
The mapping is straightforward (see Chapter 3).
IPMS.MessageBodyPart
The X.400 -> RFC 822 mapping is recursively applied, to
generate an RFC 822 Message. If present, the
IPMS.MessageBodyPart.parameters.delivery-envelope is used
for the MTS Abstract Service Mappings. If present, the
IPMS.MessageBodyPart.parameters.delivery-time is mapped to
the extended RFC 822 field "Delivery-Date:".
Other
If other body parts can be mapped to IA5, either by use of
mappings defined in X.408 [CCITT88a], or by other reasonable
mappings, this shall be done unless content conversion is
prohibited.
If some or all of the body parts cannot be converted there are three
options. All of these conform to this standard. A different choice
may be made for the case where no body part can be converted:
1. The first option is to reject the message, and send a non-
delivery notification. This must always be done if
conversion is prohibited.
2. The second option is to map a missing body part to something
of the style:
*********************************
There was a foobarhere
The widget gateway ate it
*********************************
This will allow some useful information to be transferred.
As the recipient is likely to be a human (IPMS), then
suitable action will usually be possible.
3. Finally both may be done. In this case, the supplementary
information in the (positive) Delivery Report shall make
clear that something was sent on to the recipient with
substantial loss of information.
Where there is more than one IPMS.BodyPart, the mapping defined by
Rose and Stefferud in [Rose85a], is used to map the separate
IPMS.BodyParts in the single RFC 822 message body. If this is done,
a "Message-Type:" field with value "Multiple part" shall be added, which will indicate to a receiving gateway that the message may be unfolded according to RFC 934. Note:There is currently work ongoing to produce an upgrade to RFC 934, which also allows for support of body parts with non- ASCII content (MIME). When this work is released as an RFC, this specification will be updated to refer to it instead for RFC 934. For backwards compatibility with RFC 987, the following procedures shall also be followed. If there are two IA5 body parts, and the first starts with the string "RFC-822-Headers:" as the first line, then the remainder of this body part shall be appended to the RFC 822 header. An example message, illustrating a number of aspects is given below. Return-Path:<@mhs-relay.ac.uk:stephen.harrison@gosip-uk.hmg.gold-400.gb> Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <7906-0@bells.cs.ucl.ac.uk>; Thu, 30 May 1991 18:24:55 +0100 X400-Received: by mta "mhs-relay.ac.uk" in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Thu, 30 May 1991 18:23:26 +0100 X400-Received: by /PRMD=HMG/ADMD=GOLD 400/C=GB/; Relayed; Thu, 30 May 1991 18:20:27 +0100 Message-Type: Multiple Part Date: Thu, 30 May 1991 18:20:27 +0100 X400-Originator: Stephen.Harrison@gosip-uk.hmg.gold-400.gb X400-MTS-Identifier: [/PRMD=HMG/ADMD=GOLD 400/C=GB/;PC1000-910530172027-57D8] Original-Encoded-Information-Types: ia5, undefined X400-Content-Type: P2-1984 (2) Content-Identifier: Email Problems From: Stephen.Harrison@gosip-uk.hmg.gold-400.gb (Tel +44 71 217 3487) Message-ID: <PC1000-910530172027-57D8*@MHS> To: Jim Craigie <NTIN36@gec-b.rutherford.ac.uk> (Receipt Notification Requested) (Non Receipt Notification Requested), Tony Bates <tony@ean-relay.ac.uk> (Receipt Notification Requested), Steve Kille <S.Kille@cs.ucl.ac.uk> (Receipt Notification Requested) Subject: Email Problems Sender: Stephen.Harrison@gosip-uk.hmg.gold-400.gb ------------------------------ Start of body part 1 Hope you gentlemen.......
Regards, Stephen Harrison UK GOSIP Project ------------------------------ Start of forwarded message 1 From: Urs Eppenberger <Eppenberger@verw.switch.ch> Message-ID: <562*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: "Stephen.Harrison" <Stephen.Harrison@gosip-uk.hmg.gold-400.gb> Cc: kimura@bsdarc.bsd.fc.nec.co.jp Subject: Response to Email link - ------------------------------ Start of body part 1 Dear Mr Harrison...... - ------------------------------ End of body part 1 ------------------------------ End of forwarded message 1 5.3.5. Mappings from an IP Notification A message is generated, with the following fields: From: Set to the IPMS.IPN.ipn-originator. To: Set to the recipient from MTS.MessageSubmissionEnvelope. If there have been redirects, the original address should be used. Subject: Set to the string "X.400 Inter-Personal Notification" for a receipt notification and to "X.400 Inter-Personal Notification (failure)" for a non-receipt notification. Message-Type: Set to "InterPersonal Notification" References: Set to IPMS.IPN.subject-ipm The following EBNF is defined for the body of the Message. This format is defined to ensure that all information from an
interpersonal notification is available to the end user in a uniform
manner.
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"
The mappings for elements of the common fields of IPMS.IPN
(IPMS.CommonFields) onto this structure and the message header are:
subject-ipm
Mapped to "References:"
ipn-originator
Mapped to "From:".
ipn-preferred-recipient
Mapped to EBNF.preferred-recipient
conversion-eits
Mapped to EBNF.encoded-info in EBNF.ipn-extra-information
The mappings for elements of IPMS.IPN.non-receipt-fields
(IPMS.NonReceiptFields) are:
non-receipt-reason
Used to select between EBNF.ipn-discarded and
EBNF.ipn-auto-forwarded
discard-reason
Mapped to EBNF.discard-reason
auto-forward-comment
Mapped to EBNF.auto-comment
returned-ipm
This applies only to non-receipt notifications.
EBNF.ipn-content-return should always be omitted for receipt
notifications, and always be present in non-receipt
notifications. If present, the second option of
EBNF.ipn-content-return is chosen, and an RFC 822 mapping of
the message included. Otherwise the first option is chosen.
The mappings for elements of IPMS.IPN.receipt-fields
(IPMS.ReceiptFields) are:
receipt-time
Mapped to EBNF.receipt-time
acknowledgement-mode
Mapped to EBNF.acknowledgement-mode
suppl-receipt-info
Mapped to EBNF.ipn-suppl
An example notification is:
From: Steve Kille <steve@cs.ucl.ac.uk>
To: Julian Onions <jpo@computer-science.nottingham.ac.uk>
Subject: X.400 Inter-personal Notification
Message-Type: InterPersonal Notification
References: <1229.614418325@UK.AC.NOTT.CS>
Date: Wed, 21 Jun 89 08:45:25 +0100
Your message to: Steve Kille <steve@cs.ucl.ac.uk>
was automatically forwarded.
The following comment was made:
Sent on to a random destination
The following information types were converted: g3fax
5.3.6. Mappings from the MTS Abstract Service
This section describes the MTS mappings for User Messages (IPM and
IPN). This mapping is defined by specifying the mapping of
MTS.MessageDeliveryEnvelope. The following extensions to RFC 822 are
defined to support this mapping:
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"
The mappings for each element of MTS.MessageDeliveryEnvelope can now
be considered.
MTS.MessageDeliveryEnvelope.message-delivery-identifier
Mapped to the extended RFC 822 field "X400-MTS-Identifier:".
MTS.MessageDeliveryEnvelope.message-delivery-time
Discarded, as this time will be represented in an
appropriate trace element.
The mappings for elements of
MTS.MessageDeliveryEnvelope.other-fields
(MTS.OtherMessageDeliveryFields) are:
content-type
Mapped to the extended RFC 822 field "X400-Content-Type:".
The string "P2" is retained for backwards compatibility with
RFC 987. This shall not be generated, and either the
EBNF.labelled-integer or EBNF.object-identifier encoding
used.
originator-name
Mapped to the 822-MTS originator, and to the extended RFC
822 field "X400-Originator:". This is described in
Section 4.6.2.
original-encoded-information-types
Mapped to the extended RFC 822 field
"Original-Encoded-Information-Types:".
priority
Mapped to the extended RFC 822 field "Priority:".
delivery-flags
If the conversion-prohibited bit is set, add an extended RFC
822 field "Conversion:".
this-recipient-name and other-recipient-names
originally-intended-recipient-name
The handling of these elements is described in
Section 4.6.2.
converted-encoded-information-types
Discarded, as it will always be IA5 only.
message-submission-time
Mapped to Date:.
content-identifier
Mapped to the extended RFC 822 field "Content-Identifier:".
If any extensions (MTS.MessageDeliveryEnvelope.other-
fields.extensions) are present, and they are marked as critical for
transfer or delivery, then the message shall be rejected. The
extensions (MTS.MessageDeliveryEnvelope.other-fields.extensions) are
mapped as follows.
conversion-with-loss-prohibited
If set to
MTS.ConversionWithLossProhibited.conversion-with-loss-prohibited,
then add the extended RFC 822 field "Conversion-With-Loss:".
requested-delivery-method
Mapped to the extended RFC 822 field
"Requested-Delivery-Method:".
originator-return-address
Mapped to the extended RFC 822 field
"Originator-Return-Address:".
physical-forwarding-address-request
physical-delivery-modes
registered-mail-type
recipient-number-for-advice
physical-rendition-attributes
physical-delivery-report-request
physical-forwarding-prohibited
These elements are only appropriate for physical delivery.
They are represented as comments in the "X400-Recipients:"
field, as described in Section 4.6.2.2.
originator-certificate
message-token
content-confidentiality-algorithm-identifier
content-integrity-check
message-origin-authentication-check
message-security-label
proof-of-delivery-request
These elements imply use of security services not available
in the RFC 822 environment. If they are marked as critical
for transfer or delivery, then the message shall be
rejected. Otherwise they are discarded.
redirection-history
This is described in Section 4.6.2.
dl-expansion-history
Each element is mapped to the extended RFC 822 field
"DL-Expansion-History:". They shall be ordered in the
message header, so that the most recent expansion comes
first (same order as trace).
If any MTS (or MTA) Extensions not specified in X.400 are present,
and they are marked as critical for transfer or delivery, then the
message shall be rejected. If they are not so marked, they can
safely be discarded. The list of discarded fields shall be indicated
in the extended header "Discarded-X400-MTS-Extensions:".
5.3.7. Mappings from the MTA Abstract Service
There are some mappings at the MTA Abstract Service level which are
done for IPM and IPN. These can be derived from
MTA.MessageTransferEnvelope. The reasons for the mappings at this
level, and the violation of layering are:
- Allowing for multiple recipients to share a single RFC 822
message
- Making the X.400 trace information available on the RFC 822
side
- Making any information on deferred delivery available
The 822-MTS recipients are calculated from the full list of X.400
recipients. This is all of the members of
MTA.MessageTransferEnvelope.per-recipient-fields being passed through
the gateway, where the responsibility bit is set. In some cases, a
different RFC 822 message would be calculated for each recipient, due
to differing service requests for each recipient. As discussed in
4.6.2..2, this specification allows either for multiple messages to
be generated, or for the per- recipient information to be discarded.
The following EBNF is defined for extended RFC 822 headers:
mta-field = "X400-Received" ":" x400-trace
/ "Deferred-Delivery" ":" date-time
/ "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"
Note the EBNF.mta is encoded as 822.word. If the character set does
no allow encoding as 822.atom, the 822.quoted-string encoding is
used.
If MTA.PerMessageTransferFields.deferred-delivery-time is present, it
is used to generate a Deferred-Delivery: field. For some reason,
X.400 does not make this information available at the MTS level on
delivery. X.400 profiles, and in particular the CEN/CENELEC profile
for X.400(1984) [Systems85a], specify that this element must be
supported at the first MTA. If it is not, the function may
optionally be implemented by the gateway: that is, the gateway may
hold the message until the time specified in the protocol element.
Thus, the value of this element will usually be in the past. For
this reason, the extended RFC 822 field is primarily for information.
Merge MTA.PerMessageTransferFields.trace-information, and
MTA.PerMessageTransferFields.internal-trace-information to produce a
single ordered trace list. If Internal trace from other management
domains has not been stripped, this may require complex interleaving.
Where an element of internal trace and external trace are identical,
except for the MTA in the internal trace, only the internal trace
element shall be presented. Use this to generate a sequence of
"X400-Received:" fields. The only difference between external trace
and internal trace will be the extra MTA information in internal
trace elements.
When generating an RFC 822 message all trace fields (X400-Received and Received) shall be at the beginning of the header, before any other fields. Trace shall be in chronological order, with the most recent element at the front of the message. This ordering is determined from the order of the fields, not from timestamps in the trace, as there is no guarantee of clock synchronisation. A simple example trace (external) is: X400-Received: by /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; Relayed ; Tue, 20 Jun 89 19:25:11 +0100 A more complex example (internal): X400-Received: by mta "UK.AC.UCL.CS" in /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; deferred until Tue, 20 Jun 89 14:24:22 +0100 ; converted (undefined, g3fax) ";" attempted /ADMD=Foo/C=GB/ ; Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100 5.3.8. Mappings from Report Delivery Delivery reports are mapped at the MTS service level. This means that only reports destined for the MTS user will be mapped. Some additional services are also taken from the MTA service. 5.3.8.1. MTS Mappings A Delivery Report service will be represented as MTS.ReportDeliveryEnvelope, which comprises of per-report-fields (MTS.PerReportDeliveryFields) and per-recipient-fields. A message is generated with the following fields: From: An administrator at the gateway system. This is also the 822-MTS originator. To: A mapping of the MTA.ReportTransferEnvelope.report-destination-name. This is also the 822-MTS recipient. Message-Type: Set to "Delivery Report". Subject: The EBNF for the subject line is:
subject-line = "Delivery-Report" "(" status ")"
[ "for" destination ]
status = "success" / "failure" / "success and failures"
destination = mailbox / "MTA" word
The format of the body of the message is defined to ensure that all
information is conveyed to the RFC 822 user in a consistent manner.
The format is structured as if it was a message coming from X.400,
with the description in one body part, and a forwarded message
(return of content) in the second. This structure is useful to the
RFC 822 recipient, as it enables the original message to be
extracted. The first body part is structured as follows:
1. A few lines giving keywords to indicate the original
message.
2. A human summary of the status of each recipient being
reported on.
3. A clearly marked section which contains detailed information
extracted from the report. This is marked clearly, as it
will not be comprehensible to the average user. It is
retained, as it may be critical to diagnosing an obscure
problem.
This section may be omitted in positive DRs, and it is
recommended that this is appropriate for most gateways.
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 RFC 822 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 ")")
The format is defined as a fixed definition of an the outer level
(EBNF.dr-body-format). The element EBNF.dr-administrator-info-
envelope, provides a means of encapsulating a section of the header
in a manner which is clear to the end user. Each line of this
section begins with "*". Each element of EBNF.text within %EBNF.dr-
administrator-info-envelope must not contain <CRLF>. This is used to
wrap up EBNF.dr-administrator-info, which will generate a sequenece
of lines not starting with "*". EBNF.drc-fields may be folded using
the RFC 822 folding rules.
The elements of MTS.ReportDeliveryEnvelope.per-report-fields are
mapped as follows onto extended RFC 822 fields:
subject-submission-identifier
Mapped to EBNF.drc-field (Subject-Submission-Identifier)
content-identifier
Mapped to EBNF.drc-field (Content-Identifier). This should
also be used in EBNF.dr-summary if there is no Content
Correlator present.
content-type
Mapped to EBNF.drc-field (Content-Type)
original-encoded-information-types
Mapped to EBNF.drc-field (Encoded-Info)
The extensions from MTS.ReportDeliveryEnvelope.per-report-
fields.extensions are mapped as follows:
originator-and-DL-expansion-history
Mapped to EBNF.drc-field (Originator-and-DL-Expansion-
History)
reporting-DL-name
Mapped to EBNF.drc-field (Reporting-DL-Name)
content-correlator
Mapped to EBNF.content-correlator, provided that the
encoding is IA5String (this will always be the case). This
is used in EBNF.dr-summary and EBNF.drc-field-list. In the
former, LWSP may be added, in order to improve the layout of
the message.
message-security-label reporting-MTA-certificate report-origin-
authentication-check
These security parameters will not be present unless there
is an error in a remote MTA. If they are present, they
shall be discarded in preference to discarding the whole
report.
For each element of MTS.ReportDeliveryEnvelope.per-recipient-fields,
a value of EBNF.dr-recipient, and an EBNF.drc-field (Recipient-Info)
is generated. The components are mapped as follows.
actual-recipient-name
Used to generate the first EBNF.mailbox and EBNF.std-or in
EBNF.recipient-info. Both RFC 822 and X.400 forms are
given, as there may be a problem in the mapping tables. It
also generates the EBNF.mailbox in EBNF.dr-recip-success or
EBNF.dr-recip-failure.
report
If it is MTS.Report.delivery, then set EBNF.dr-recipient to
EBNF.dr-recip-success, and similarly set EBNF.report-type,
filling in EBNF.drc-success. If it is a failure, set
EBNF.dr-recipient to EBNF.dr-recip-failure, making a human
interpretation of the reason and diagnostic codes, and
including any supplementary information. EBNF.drc-failure
is filled in systematically.
converted-encoded-information-types
Set EBNF.drc-field ("converted eits")
originally-intended-recipient
Set the second ("originally intended recipient") mailbox and
std-or in EBNF.drc-field.
supplementary-info
Set EBNF.drc-field ("supplementary info"), and include this
information in EBNF.dr-recip-failure.
redirection-history
Set EBNF.drc-field ("redirection history")
physical-forwarding-address
Set ENBF.drc-field ("physical forwarding address")
recipient-certificate
Discard
proof-of-delivery
Discard
Any unknown extensions shall be discarded, irrespective of
criticality.
The original message, or an extract from it, shall be included in the
delivery port if it is available. The original message will usually
be available at the gateway, as discussed in Section 5.2. If the
original message is available, but of erroneous format, a dump of the
ASN.1 may be included. This is recommended, but not required.
5.3.8.2. MTA Mappings
The single 822-MTS recipient is constructed from
MTA.ReportTransferEnvelope.report-destination-name, using the
mappings of Chapter 4. Unlike with a user message, this information
is not available at the MTS level.
The following additional mappings are made:
MTA.ReportTransferEnvelope.report-destination-name
This is used to generate the To: field.
MTA.ReportTransferEnvelope.identifier
Mapped to the extended RFC 822 field "X400-MTS-Identifier:".
It may also be used to derive a "Message-Id:" field.
MTA.ReportTransferEnvelope.trace-information
and
MTA.ReportTransferEnvelope.internal-trace-information
Mapped onto the extended RFC 822 field "X400-Received:", as
described in Section 5.3.7. The first element is also used
to generate the "Date:" field, and the EBNF.report-point.
MTA.PerRecipientReportTransferFields.last-trace-information
Mapped to EBNF.recipient-info (last trace)
MTA.PerReportTransferFields.subject-intermediate-trace-
information Mapped to EBNF.drc-field (Subject-Intermediate-
Trace-Information). These fields are ordered so that the
most recent trace element comes first.
5.3.8.3. Example Delivery Reports
Example Delivery Report 1:
Return-Path: <postmaster@cs.ucl.ac.uk>
Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk
via Delivery Reports Channel id <27699-0@bells.cs.ucl.ac.uk>;
Thu, 7 Feb 1991 15:48:39 +0000
From: UCL-CS MTA <postmaster@cs.ucl.ac.uk>
To: S.Kille@cs.ucl.ac.uk
Subject: Delivery Report (failure) for H.Hildegard@bbn.com
Message-Type: Delivery Report
Date: Thu, 7 Feb 1991 15:48:39 +0000
Message-ID: <"bells.cs.u.694:07.01.91.15.48.34"@cs.ucl.ac.uk>
Content-Identifier: Greetings.
------------------------------ Start of body part 1
This report relates to your message: Greetings.
of Thu, 7 Feb 1991 15:48:20 +0000
Your message was not delivered to
H.Hildegard@bbn.com for the following reason:
Bad Address
MTA 'bbn.com' gives error message (USER) Unknown user
name in "H.Hildegard@bbn.com"
***** The following information is directed towards the local
***** administrator and is not intended for the end user
*
* DR generated by mta bells.cs.ucl.ac.uk
* in /PRMD=uk.ac/ADMD=gold 400/C=gb/
* at Thu, 7 Feb 1991 15:48:34 +0000
* * Converted to RFC 822 at bells.cs.ucl.ac.uk * at Thu, 7 Feb 1991 15:48:40 +0000 * ..... continued on next page * Delivery Report Contents: * * Subject-Submission-Identifier: * [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1803.665941698@UK.AC.UCL.CS>] * Content-Identifier: Greetings. * Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold 400/C=gb/; * arrival Thu, 7 Feb 1991 15:48:20 +0000 action Relayed * Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold 400/C=gb/; * arrival Thu, 7 Feb 1991 15:48:18 +0000 action Relayed * Recipient-Info: H.Hildegard@bbn.com, * /RFC-822=H.Hildegard(a)bbn.com/OU=cs/O=ucl /PRMD=uk.ac/ADMD=gold 400/C=gb/; * FAILURE reason Unable-To-Transfer (1); * diagnostic Unrecognised-ORName (0); * last trace (ia5) Thu, 7 Feb 1991 15:48:18 +0000; * supplementary info "MTA 'bbn.com' gives error message (USER) * Unknown user name in "H.Hildegard@bbn.com""; ****** End of administration information The Original Message follows: ------------------------------ Start of forwarded message 1 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <27689-0@bells.cs.ucl.ac.uk>; Thu, 7 Feb 1991 15:48:21 +0000 To: H.Hildegard@bbn.com Subject: Greetings. Phone: +44-71-380-7294 Date: Thu, 07 Feb 91 15:48:18 +0000 Message-ID: <1803.665941698@UK.AC.UCL.CS> From: Steve Kille <S.Kille@cs.ucl.ac.uk> Steve ------------------------------ End of forwarded message 1 Example Delivery Report 2:
Return-Path: <postmaster@cs.ucl.ac.uk>
Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk
via Delivery Reports Channel id <27718-0@bells.cs.ucl.ac.uk>;
Thu, 7 Feb 1991 15:49:11 +0000
X400-Received: by mta bells.cs.ucl.ac.uk in
/PRMD=uk.ac/ADMD=gold 400/C=gb/;
Relayed; Thu, 7 Feb 1991 15:49:08 +0000
X400-Received: by /PRMD=DGC/ADMD=GOLD 400/C=GB/; Relayed;
Thu, 7 Feb 1991 15:48:40 +0000
From: UCL-CS MTA <postmaster@cs.ucl.ac.uk>
To: S.Kille@cs.ucl.ac.uk
Subject: Delivery Report (failure) for
j.nosuchuser@dle.cambridge.DGC.gold-400.gb
Message-Type: Delivery Report
Date: Thu, 7 Feb 1991 15:49:11 +0000
Message-ID: <"DLE/910207154840Z/000"@cs.ucl.ac.uk>
Content-Identifier: A useful mess...
This report relates to your message: A useful mess...
Your message was not delivered to
j.nosuchuser@dle.cambridge.DGC.gold-400.gb
for the following reason:
Bad Address
DG 21187: (CEO POA) Unknown addressee.
***** The following information is directed towards the local
***** administrator and is not intended for the end user
*
* DR generated by /PRMD=DGC/ADMD=GOLD 400/C=GB/
* at Thu, 7 Feb 1991 15:48:40 +0000
*
* Converted to RFC 822 at bells.cs.ucl.ac.uk
* at Thu, 7 Feb 1991 15:49:12 +0000
*
* Delivery Report Contents:
*
* Subject-Submission-Identifier:
* [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>]
* Content-Identifier: A useful mess...
* Recipient-Info: j.nosuchuser@dle.cambridge.DGC.gold-400.gb,
* /I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=GOLD 400/C=GB/;
* FAILURE reason Unable-To-Transfer (1);
* diagnostic Unrecognised-ORName (0);
* supplementary info "DG 21187: (CEO POA) Unknown addressee.";
****** End of administration information
The Original Message is not available
5.3.9. Probe This is an MTS internal issue. Any probe shall be serviced by the gateway, as there is no equivalent RFC 822 functionality. The value of the reply is dependent on whether the gateway could service an MTS Message with the values specified in the probe. The reply shall make use of MTS.SupplementaryInformation to indicate that the probe was serviced by the gateway.
(page 91 continued on part 4)