S.Kille@CS.UCL.AC.UK (Steve Kille) (07/14/89)
Two extended fields must be mapped, in order to prevent |
looping. "DL-Expansion-History:" is mapped to |
MTA.PerMessageTransferFields.extensions.dl-expansion-history. |
"Redirection-History:" is mapped to |
MTA.PerRecipientMessageTransferFields.extensions .redirection- |
history.
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 these |
fields to X.400, with the exception of "DL-Expansion-History" and |
"Redirection-History" described in the previous section.
However, it is usually desirable and beneficial to do so,
particularly to facilitate support of a message traversing
multiple gateways. These mappings may be onto MTA, MTS, or IPMS
services.
5.2. Return of Contents
It is not clear how widely supported the X.400 return of contents
service will be. However, profiling work and early experience
suggests that many systems will not support this service. As
this service is expected in the RFC 822 world, two approaches are
specified (it is not so necessary in the X.400 world, as delivery
reports are distinguished from messages). The choice will depend
on the service level of the X.400 community being serviced by the
gateway.
Kille [page 71]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 should 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 should be used if the
Kille [page 72]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 should be assigned.
Date:
A value will always be generated
From:If this is not generated by the mapping, it should be
assigned equal to the 822-MTS Originator. If this is
gateway generated, an appropriate 822.phrase should be
added.
At least one recipient field
If no recipient fields are generated, a field "To: list:;",
should be added.
This will ensure minimal RFC 822 compliance. When generating RFC
822 headers, folding should be used in an appropriate manner.
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)
Kille [page 73]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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
Kille [page 74]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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).
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
Kille [page 75]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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. If possible, the language-description
should be filled in with a human readable description of the
language.
If the RFC 822 extended header is found, this should be
mapped onto an RFC 822 header, as described in Section 5.1.2. |
If a non-standard extension is found, it should 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 should be 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).
Kille [page 76]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
IPMS.MessageBodyPart
The X.400 -> RFC 822 mapping should be recursively applied,
to generate an RFC 822 Message. If present, the
IPMS.MessageBodyPart.parameters.delivery-envelope should be
used for the MTS Abstract Service Mappings. If present, the
IPMS.MessageBodyPart.parameters.delivery-time should be
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 [CCITT88b], or by other reasonable
mappings, this should 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. The first option is to reject the message, and |
send a non-delivery notification. This must always be done if |
conversion is prohibited. The second option is to map a missing |
body part to something of the style:
*********************************
There was a foobar here
The widget gateway ate it |
*********************************
This will allow some useful information to be transferred. As
the recipient is a human (IPMS), then suitable action should be
available. Finally both can be done. In this case, the |
supplementary information in the Delivery Report should 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], should be 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" should be added, which will indicate to a |
receiving gateway that the message may be unfolded according to |
RFC 934.
Kille [page 77]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
For backwards compatibility with RFC 987, the following
procedures should 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 should be
appended to the RFC 822 header.
5.3.5. Mappings from an IP Notification
A message is generated, with the following fields: |
From: |
Set to the MTS.MessageDeliveryEnvelope.other- |
fields.originator-name. |
To: Set to the IPMS.IPN.ipm-originator. |
Subject: |
Set to something of the form "X.400 Inter Personal 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.
Kille [page 78]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
ipn-body-format = ipn-description <CRLF> ||
[ ipn-extra-information <CRLF> ] ||
ipn-content-return ||
ipn-preamble = * ( printablestring <CRLF> ) ||
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 ||
Kille [page 79]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
preferred-recipient = mailbox ||
receipt-time = date-time ||
auto-comment = printablestring ||
ipn-suppl = printablestring ||
non-receipt-reason = "Discarded" / "Auto-Forwarded"
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:" |
ipm-originator
Mapped to "To:". |
ipm-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
Kille [page 80]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
If present, the second option of EBNF.ipn-content-return |
should be chosen, and an RFC 822 mapping of the message |
included. Otherwise the first option should be 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: X400 Inter-personal Receipt 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
The Original Message is not available
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:
Kille [page 81]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 ";"||
/ "Redirection-History" ":" redirection ||
/ "Conversion" ":" prohibition ||
/ "Conversion-With-Loss" ":" prohibition ||
/ "Requested-Delivery-Method" ":" ||
1*( labelled-integer ) ||
/ "Discarded-X400-MTS-Extensions" ":" 1#oid ||
prohibition = "Prohibited" / "Allowed" |
mts-msg-id = global-id ";" *text |
mts-content-type = "P2" / labelled-integer |
/ object-identifer |
priority = "normal" / "non-urgent" / "urgent"
redirection = mailbox ";" "reason" "=" |
redirection-reason |
redirection-reason =
"Recipient Assigned Alternate Recipient" |
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient" |
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
Kille [page 82]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 for backwards compatibility with RFC 987.
If the content type is 22, then a labelled-integer encoding
should be 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
These fields are used together, to generate the extended RFC
822 field "X400-Recipients:". Note that the latter will |
only be present if disclosure of recipients is allowed.
originally-intended-recipient-name
Mapped to a comment associated with the recipient in |
question, as described in Section 4.6.2.2.
converted-encoded-information-types
Discarded, as it will always be IA5 only. |
message-submission-time
Mapped to Date:.
content-identifier
Kille [page 83]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Mapped to the extended RFC 822 field "Content-Identifier:". |
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:".
physical-forwarding-prohibited
Mapped to a comment associated with the recipient in |
question, as described in Section 4.6.2.2.
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
These elements are only appropriate for physical delivery. |
They are represented as comments in the "X400-Recipients:" |
field, as described in Chapter 4.
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
Kille [page 84]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
for transfer or delivery, then the message should be
rejected. Otherwise they should be discarded.
redirection-history
Each element is mapped to an extended RFC 822 field |
"Redirection-History:". They should be ordered in the |
message header, so that the most recent redirection comes |
first (same order as trace).
dl-expansion-history
Each element is mapped to the extended RFC 822 field |
"DL-Expansion-History:". They should be ordered in the |
message header, so that the most recent redirection 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 delivery, then the |
message should be rejected. If they are not so marked, they can |
safely be discarded. The list of discarded fields should 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 should be 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. If this is due to differing service requests for
each recipient, then a different message should be generated.
Kille [page 85]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
If it is due to the request for non-disclosure of recipients,
then the MTS-Recipients: field should be omitted, and only one
message sent.
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" [ "mta" mta "in" ] global-id ";" |
[ "deferred until" date-time ";" ] |
[ "converted" "(" encoded-info ")" ]
[ "attempted domain" global-id ";" ] |
action-list |
";" date-time |
mta = word |
arrival-time = date-time |
routing-action = |
other-action-list = 1#action |
action = "Redirected" |
/ "Expanded" |
/ "Relayed" |
/ "Rerouted" |
If MTA.PerMessageTransferFields.deferred-delivery-time is
present, use it 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 should hold the message until the time specified
in the protocol element. Thus, it is expected that the value of
Kille [page 86]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
this element will often 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. Use this to generate a sequence of |
X400-Received:" fields. The only difference between external an |
internal will be the extra MTA information.
When generating an RFC 822 message all trace fields (X400- |
Received and Received) should be at the beginning of the header,
before any other fields. Trace should be in chronological order,
with the most recent element at the front of the message. 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 domain /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. 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 should be generated with the following fields: |
From: |
An administrator at the gateway system. This is also the |
822-MTS originator. |
Kille [page 87]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
To: A mapping of the |
MTA.ReportTransferEnvelope.report-destination-name. This is |
also the 822-MTS recipient. |
Message-Type: |
Set to "Delivery Report". |
Subject: |
Something of the form "X.400 Delivery Report from the Foobar |
Gateway V 27".
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. This gives a summary of critical information, |
and then a full listing of all parameters:
dr-body-format = dr-summary <CRLF> ||
dr-recipients <CRLF> ||
dr-extra-information <CRLF> ||
dr-content-return ||
dr-content-return = "The Original Message is not available"||
/ "The Original Message follows:" ||
<CRLF> <CRLF> message ||
dr-summary = "This report relates to your message:" <CRLF> ||
content-correlator <CRLF> <CRLF> ||
"Which failed at" failure-point <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 ||
dr-recip-failure = "Your message was not delivered to:" ||
mailbox <CRLF> ||
"for the following reason:" *word ||
Kille [page 88]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
dr-extra-information = ||
"The following information is derived from the Report" <CRLF>||
"It may be useful for problem diagnosis:" <CRLF> <CRLF> ||
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 ||
recipient-info = mailbox "," std-or ";" ||
report-type ||
[ "converted eits" encoded-info ";" ] ||
[ "originally intended recipient" ||
mailbox "," std-or ";" ] ||
[ "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 ";" ] |
failure-point = [ "mta" word "in" ] global-id
content-correlator = *word
dl-history = 1#mailbox
Kille [page 89]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
The format is defined as a fixed definition. The only exception |
is that the EBFN.drc-fields should follow 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) |
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 should 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 should not be present. If they
are, they should be discarded in preference to discarding
the whole report.
Kille [page 90]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
For each element of |
MTS.ReportDeliveryEnvelope.per-recipient-fields, a value of |
EBNF.dr-recipient, and an EBNF.drc-field (Recipient-Info) should |
be 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 delivery codes, and including any |
supplementary information. EBNF.drc-failure should be |
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") |
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
The original message should be included in the delivery |
Kille [page 91]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
port. The original message will usually be available at the |
gateway, as discussed in Section 5.2.
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 should be made:
MTA.ReportTransferEnvelope.report-destination-name
This should be 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 should also |
be used to generate the "Date:" field, and the |
EBNF.failure-point. |
5.3.8.3. Example Delivery Report |
This is an example, of a moderately complex report. |
Kille [page 92]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
From: The Postmaster <postmaster@cs.ucl.ac.uk>
To: jpo@computer-science.nottingham.ac.uk
Subject: X.400 Delivery Report
Message-Type: Delivery Report
Date: Wed, 21 Jun 89 08:45:25 +0100
X400-MTS-Identifier: /PRMD=UK.AC/ADMD=Gold 400/C=GB/;13412345235
This report relates to your message:
Date: Wed, 21 Jun 89 06:15:43 +0000
Message-ID: <8907140715.aa09015@CS.Nott.AC.UK>
Subject: Now it's the fine tuning .... !
To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
Your message was successfully delivered to: pb@computer-lab.cambridge.ac.uk
Your message was not delivered to: bad-user@nowhere
for the following reason: Rendition problem with punctuation
(Umlaut failure)
The following information is derived from the Report
It may be useful for problem diagnosis:
Subject-Submision-Identifier: /PRMD=UK.AC/ADMD=Gold 400/C-GB/;148996
Content-Identifier: X.400 Delivery Report
Content-Type: P2-1988 (22)
Original-Encoded-Information-Types: ia5
Content-Correlator: Date: Wed, 21 Jun 89 06:15:43 +0000
Message-ID: <8907140715.aa09015@CS.Nott.AC.UK>
Subject: Now it's the fine tuning .... !
To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
Recipient-Info: pb@computer-lab.cambridge.ac.uk ,
/S=PB/OU=computer-lab/O=cambridge/PRMD=UK.AC/ADMD=Gold 400/C=GB/ ;
SUCCESS delivered at Wed, 21 Jun 89 08:45:25 +0100 ;
Recipient-Info: bad-user@nowhere, /S=bad-user/PRMD=nowhere/ADMD=DBP/C=DE/ ;
FAILURE reason Physical-Rendition-Not-Performed (3) ;
diagnostic Punctuation-Symbol-Loss (23) ;
supplementary info Umlaut failure
The Original Message follows:
Subject: Now it's the fine tuning .... !
Date: Wed, 21 Jun 89 06:15:43 +0000
Kille [page 93]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
From: Julian Onions <jpo@computer-science.nottingham.ac.uk>
To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
Cc: bad-user@nowhere
Message-ID: <8907140715.aa09015@CS.Nott.AC.UK>
A short test
5.3.9. Probe
This is an MTS internal issue. Any probe should 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 should make use of MTS.SupplementaryInformation to
indicate that the probe was serviced by the gateway.