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 RFC822 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
/ "X400-Content-Identifier" ":" printablestring
/ "Priority" ":" priority
/ "Originator-Return-Address" ":" 1#mailbox
/ "DL-Expansion-History" ":" mailbox ";" date-time
";"
/ "Conversion" ":" prohibition
/ "Conversion-With-Loss" ":" prohibition
/ "Delivery-Date" ":" date-time
/ "Discarded-X400-MTS-Extensions" ":"
1#( object-identifier / labelled-integer )
prohibition = "Prohibited" / "Allowed"
mts-msg-id = "[" global-id ";" *text "]"
mts-content-type = "P2" / labelled-integer
/ object-identifier
priority = "normal" / "non-urgent" / "urgent"
The mappings for each element of MTS.MessageDeliveryEnvelope can now
be considered. Where the specified action does not result in an
extended element being mapped, the criticality associated with this
element shall be considered. If the element is marked as critical
for transfer or for delivery, the message shall be non delivered by
the gateway because a critical extension cannot be correctly handled.
MTS.MessageDeliveryEnvelope.message-delivery-identifier
Mapped to the extended RFC822 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 RFC822 field "X400-Content-Type:". The
string "P2" is retained for backwards compatibility with RFC987.
This shall not be generated, and either the EBNF.labelled-integer
or EBNF.object-identifier encoding used.
originator-name
Mapped to the SMTP originator, and to the extended RFC822 field
"X400-Originator:". This is described in Section 4.6.2.
original-encoded-information-types
Mapped to the extended RFC822 field "Original-Encoded-
Information-Types:".
priority
Mapped to the extended RFC822 field "Priority:".
delivery-flags
If the conversion-prohibited bit is set, add an extended RFC822
field "Conversion:".
this-recipient-name and other-recipient-names
The handling of these elements is described in Section 4.6.2.
originally-intended-recipient-name
The handling of this element is described in Section 4.6.2.
converted-encoded-information-types
Discarded. This information will be mapped in the trace.
message-submission-time
Mapped to Date:.
content-identifier
Mapped to the extended RFC822 field "X400-Content-Identifier:".
In RFC1327, this was "Content-Identifier:". This has been
changed to avoid confusion with MIME defined fields. Gateways
which reverse map, may support the old field.
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 RFC822 field "Conversion-With-
Loss:".
requested-delivery-method
Mapped to a comment, as described in Section 4.6.2.2.
originator-return-address
Mapped to the extended RFC822 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
RFC822 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 an extended RFC822 field "DL-
Expansion-History:". These fileds 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 RFC822
message
- Making the X.400 trace information available on the RFC822
side
- Making any information on deferred delivery available
The SMTP 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 RFC822 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 RFC822 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
not 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. X.400 does not make
this information available at the MTS level on delivery, because it
requires that this service is provided by the first MTA. In the event
that the first MTA does not provide this service, 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 RFC822 field is primarily for information.
If MTA.PerMessageTransferFields.extensions.dl-expansion-prohibited is
present and set to dl-expansion-probited, the gateway may reject that
message on the basis that it is unable to control distribution list
expansion beyond the gateway. The service relating to this is
described in Section 2.3.1.2. This approach was not specified in RFC
1327. If it is found to be useful, it may be made mandatory in
future versions of MIXER.
If MTA.PerMessageTransferFields.extensions.recipient-reassignment-
prohibited is present and set to recipeint-reassignment-probited, the
gateway may reject that message on the basis that it is unable to
control distribution list expansion beyond the gateway. The service
relating to this is described in Section 2.3.1.2. This approach was
not specified in RFC1327. If it is found to be useful, it may be
made mandatory in future versions of MIXER.
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 RFC822 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 MD /ADMD=Foo/C=GB/ ;
Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100
The gateway itself shall add a single line of trace information,
indicating MIXER conversion by use of a comment. For example:
Received: from isode.com by isode.com
(MIXER Conversion following RFC1327);
Thu, 2 Jan 1997 14:46:03 +0000
If SMTP is being used, Appendix A shall also be followed, which
includes optional mappings to extension parameters.
5.3.8. Mappings from Report Delivery
that only reports destined for the MTS user will be mapped. Some
additional services are also taken from the MTA service. X.400
Delivery Reports are Mapped onto Delivery Status Notifications, as
defined by NOTARY [28].
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.
The enclosing message is a MIME message of content type
multipart/report, with report-type=delivery-status, which is
generated with the following fields:
From:
An administrator at the gateway system.
To: A mapping of the
MTA.ReportTransferEnvelope.report-destination-name. This is
also the SMTP recipient.
Message-Type:
Set to "Delivery Report". This is strictly redundant, but
retained for backwards compatibility with RFC1327.
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 subject is intended to give a clear indication as to the nature
of the message, and summarise its contents. EBNF.status is set
according to whether the recipients reported on are all successes,
all failures, or a mixture. It is common for a report to reference a
single recipient, in which case a subject line giving using all of
the options of EBNF.status can be used. This gives useful
information to the recipient. Where information varies between
reported recpients, the options cannot be used. The EBNF.destination
is used to indicate the addresses in the reports. If the report is
for a single address, EBNF.mailbox is used to give the RFC822
representation of the address. If all of the reported recpients
reference the same MTA this is included in EBNF.word. The MTA is
determined from the delivery report's trace.
The format of the body of the message follows the NOTARY delivery
status notification format, and is defined to ensure that all
information is conveyed to the RFC822 user in a consistent manner.
The format is structured as if it was a message coming from the
gateway, with three body parts. The first body part is ASCII text
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.
The second (mandatory) body part is the NOTARY delivery status
notification, which contains detailed information extracted from the
report. This information may be critical to diagnosing an obscure
problem.
The third (optional) body part contains the returned message (return
of content). This structure is useful to the RFC822 recipient, as
it enables the original message to be extracted. For negative
reports it shall be included if the original message is available.
For positive reports headers from the message shall be included if
the original message is available.
The first body part containing the user oriented description is of
type text/plain. The format of this body part is defined below as
EBNF.dr-user-info.
dr-user-info = dr-summary <CRLF>
dr-recipients <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 report-point
= [ "mta" mta-name "in" ] global-id content-correlator = *word
mta-name = word
EBNF.dr-summary
The EBNF.content-correlator is taken from the content correlator
(or content identifier if there is no content correlator) and the
EBNF.date-time from the trace, as described in Section 5.3.8.3.
LWSP may be added to improve the layout of the body part.
EBNF.dr-recipients
There is an element for each recipient in the delivery report. In
each case, EBNF.mailbox is taken from the RFC822 form of the
originally specified recipient, which is taken from the originally
specified recipient element if present or from the actual
recipient. When reporting success, the message delivery time is
used to derive EBNF.date-time. When reporting failure, the
information includes a human readable interpretation of the X.400
diagnostic and reason codes, and the supplementary information.
EBNF.dr-content-return
This is set according to whether or not the content is being
returned.
The EBNF of this body part is designed for english-speaking users.
The language of the strings in the EBNF may be altered.
The EBNF used in the delivery status notification is:
dr-per-message-fields =
/ "X400-Conversion-Date" ":" date-time
/ "X400-Subject-Submision-Identifier" ":"
mts-msg-id
/ "X400-Content-Identifier" ":" printablestring
/ "X400-Content-Type" ":" mts-content-type
/ "X400-Original-Encoded-Information-Types" ":"
encoded-info
/ "X400-Originator-and-DL-Expansion-History" ":"
mailbox ";" date-time ";"
/ "X400-Reporting-DL-Name" ":" mailbox
/ "X400-Content-Correlator" ":" content-correlator
/ "X400-Recipient-Info" ":" recipient-info
/ "X400-Subject-Intermediate-Trace-Information" ":"
x400-trace
/ dr-extensions
dr-per-recipient-fields =
/ "X400-Redirect-Recipient" ":" "x400" ";" std-or
/ "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";" mailbox
/ "X400-Converted-EITs" ":" encoded-info ";"
/ "X400-Delivery-Time" ":" date-time
/ "X400-Type-of-MTS-User" ":" labelled-integer
/ "X400-Last-Trace" ":" [ encoded-info ] date-time
/ "X400-Supplementary-Info" ":"
<"> printablestring <"> ";"
/ "X400-Redirection-History" ":" redirect-history-item
/ "X400-Physical-Forwarding-Address" ":" mailbox
/ "X400-Originally-Specified-Recipient-Number" ":"
integer
/ dr-extensions
dr-extensions = "X400-Discarded-DR-Extensions" ":"
1# (object-identifier / labelled-integer)
dr-diagnostic = "Reason" labelled-integer-2
[ ";" "Diagnostic" labelled-integer-2 ]
A body part of type delivery status, as defined by NOTARY, is
generated. MIXER extends this delivery status notification (DSN)
specification, by defining additional per message fields in EBNF.dr-
per-message-fields and additional per recipient fields in EBNF.dr-
per-recipient-fields. These are used as extensions to DSN.per-
message-fields and DSN.per-recipient-fields. MIXER also defines a
new NOTARY address type "x400", with encoding of EBNF.std-or. A
directory name may be inluded as an RFC822 comment.
The following DSN.per-message-fields are always generated:
DSN.reporting-mta-field
The DSN.mta-name-type is set to "x400", and this string is
reserved by MIXER. The DSN.mta-name has its syntax specified by
EBNF.report-point, with the information derived from the first
element of the DR's trace.
DSN.arrival-date-field
This is derived from the date of the
MTA.PerRecipientReportTransferFields.last-trace-info.arrival-time
of the first recipient in the report.
The following two EBNF.per-message-fields are generated by the MIXER
gateway:
DSN.dsn-gateway-field
The type is set to "dns" and the domain set to the local domain
of the gateway.
X400-Conversion-Date:
The EBNF.date-time is set to the time of the MIXER conversion.
The elements of MTS.ReportDeliveryEnvelope.per-report-fields are
mapped as follows onto the DSN per message fields as follows:
subject-submission-identifier
Mapped to DSN.original-envelope-id-field. The encoding of this
MTS Identifier follows the format EBNF.mts-msg-id.
content-identifier
Mapped to X400-Content-Identifier:
content-type
Mapped to X400-Content-Type:
original-encoded-information-types
Mapped to X400-Encoded-Info:
The extensions from MTS.ReportDeliveryEnvelope.per-report-
fields.extensions are mapped as follows:
originator-and-DL-expansion-history
Each element is mapped to an "X400-Originator-and-DL-Expansion-
History:" They shall be ordered so that the most recent expansion
comes first in the header (same order as trace).
reporting-DL-name
Mapped to X400-Reporting-DL-Name:
content-correlator
If the content correlator starts with the string "SMTP/NOTARY
ENVID: ", then the remainder of the content correlator is mapped
to the DSN original-envelope-id field. If this is not the case,
the content correlator is mapped to X400-Content-Correlator:,
provided that the encoding is IA5String (this will always be the
case).
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. They
shall be listed in the X400-Discarded-DR-Extensions: field.
If there are any other DR extensions, they shall also be discarded
and listed in the X400-Discarded-DR-Extensions: field.
For each element of MTS.ReportDeliveryEnvelope.per-recipient-fields,
a set of DSN.per-recipient-fields is generated. The fields are
filled in as follows:
actual-recipient-name
If originally-intended-recipient-name is not present, generate a
DSN.original-recipient-field fields, with DSN.address-type of
"rfc822", and with an RFC822 mailbox generated from the address
encoded as specified by NOTARY. Also generate a DSN.final-
recipient-field field, which holds the X.400 representation of the
same address. If the directory name is present, it shall be added
as a trailing comment in the X.400 form.
If originally-intended-recipient-name is present, generate an
"X400-Mapped-Redirect-Recipient:" field, with DSN.address-type of
"rfc822", and with an RFC822 mailbox generated from the address
encoded as specified by NOTARY. Also generate an "X400-Redirect-
Recipient:" field, which holds the X.400 representation of the
same address. If the directory name is present, it shall be added
as a trailing comment in the X.400 form.
report
If it is MTS.Report.delivery, then set DSN.action-field to
"delivered", and set "X400-Delivery-Time:" and "X400-Type-of-MTS-
User:" from the information in the report. DSN.status field is
set to "2.0.0".
If it is MTS.Report.non-delivery, then set DSN.action-field to
"failed". DSN.diagnostic-code-field is encoded according to the
syntax EBNF.dr-diagnostic, with the labelled integers set from the
reason and diagnostic codes. DSN.status-field is derived from the
reason and diagnostic codes, as described below.
converted-encoded-information-types
Set X400-Converted-EITs:
originally-intended-recipient
Generate a DSN.final-recipient-field field, with DSN.address-type
of "rfc822", and with an RFC822 mailbox generated from the
address encoded as specified by NOTARY. Also generate a
DSN.original-recipient-field field, which holds the X.400
representation of the same address. If the directory name is
present, it shall be added as a trailing comment in the X.400
form.
supplementary-info
Set X400-Supplementary-Info:
redirection-history
Generate an "X400-Redirection-History:" field for each redirect
history element. The fields are ordered with the earliest
redirect first.
physical-forwarding-address
Set X400-Physical-Forwarding-Address as a mailbox, with directory
name in comment if present.
recipient-certificate
Discard
proof-of-delivery
Discard
Any unknown extensions shall be discarded, irrespective of
criticality. All discarded extensions shall be included in a "X400-
Discarded-DR-Extensions:" field.
The number from the MTA.PerRecipientReportTransferFields.originally-
specified-recipient-number shall be mapped to "X400-Originally-
Specified-Recipient-Number:", in order to facilitate reverse mapping
of delivery reports.
The original message shall be included in the delivery status
notification 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 is not a legal message format, a
dump of the ASN.1 may be included, encoded as application/octet-
string. This is recommended, but not required.
Where the original message is included, it shall be encoded according
to the MIME specifications as content type message/rfc822.
5.3.8.2. Status Code Mappings
This section defines the mappings from X.400 diagnostic and status
codes to the NOTARY Status field.
C/D X400 meaning DSN code Means
0/Any Transfer failure (may be temporary) 4.4.0 Other net/route
1/Any Unable to transfer 5.0.0 Other, unknown
2/Any Conversion not performed 5.6.3 Conv not supported
3/Any Physical rendition not performed 5.6.0 Other media error
4/Any Physical delivery not performed 5.1.0 Other address
status
5/Any Restricted delivery 5.7.1
6/Any Directory operation unsuccessful 5.4.3 Routing server
failure
7/Any Deferred delivery not performed 5.3.3 Not capable
1/0 Unrecognized OR name 5.1.1
1/1 Ambiguous OR name 5.1.4
1/2 MTS congestion 4.3.1
1/3 Loop detected 5.4.6
1/4 Recipient unavailable 4.2.1
1/5 Delivery time expired 4.4.7
1/6 Encoded information types unsupported 5.6.1 Media unsupp.
1/7 Content too long 5.2.3
2/8 Conversion impractical 5.6.3
2/9 Conversion prohibited 5.6.3
1/10 Implicit conversion not subscribed 5.6.3
1/11 Invalid arguments 5.5.2
1/12 Content syntax error 5.5.2
1/13 Size constraint violation 5.5.2
1/14 Protocol violation 5.5.0
1/15 Content type not supported 5.6.1 Media unsupp.
1/16 Too many recipients 5.5.3
1/17 No bilateral agreement 5.4.4
1/18 Unsupported critical function 5.3.3 System not capable
2/19 Conversion with loss prohibited 5.6.2
2/20 Line too long 5.6.0
2/21 Page split 5.6.0
2/22 Pictorial symbol loss 5.6.2
2/23 Punctuation symbol loss 5.6.2
2/24 Alphabetic character loss 5.6.2
2/25 Multiple information loss 5.6.2
1/26 Recipient reassignment prohibited 5.4.0 Undefined net/route
1/27 Redirection loop detected 5.4.6
1/28 DL expansion prohibited 5.7.2
1/29 No DL submit permission 5.7.1 Delivery not
authorized
1/30 DL expansion failure 4.2.4
4/31 Physical rendition attrs not supported 5.6.0 Undefined media
error
4/32-45 Various physical mail stuff 5.1.0 Other address
status
1/43 New address unknown 5.1.6 Destination mbox
moved
1/46 Secure messaging error 5.7.0 Other security
status
2/47 Unable to downgrade 5.3.3 System not capable
0/48 Unable to complete transfer 5.3.4 Message too big
0/49 Transfer attempts limit reached 4.4.7 Delivery time
expired
5.3.8.3. MTA Mappings
The single SMTP 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, which results in fields
in the outer header of the DSN.
MTA.ReportTransferEnvelope.report-destination-name
This is used to generate the To: field.
MTA.ReportTransferEnvelope.identifier
Mapped to the extended RFC822 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 RFC822 field "X400-Received:", as
described in Section 5.3.7. Date: is generated from the first
element of trace.
The following additional mappings are made, which result in per
message fields in the DSN body part:
MTA.PerRecipientReportTransferFields.last-trace-information
Mapped to X400-Last-Trace:".
MTA.PerReportTransferFields.subject-intermediate-trace-
information Mapped to "X400-Subject-Intermediate-Trace-
Information:". These fields are ordered so that the most recent
trace element comes first.
5.3.8.4. Example Delivery Reports
This section contains sample delivery reports. These are the same
examples used in RFC1327, and so they also illustrate the changes
between RFC1327 and this document. Example Delivery Report 1:
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> X400-Content-
Identifier: Greetings. MIME-Version: 1.0 Content-Type:
multipart/report; report-type=delivery-status;
boundary=boundary-1
--boundary-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 Original Message follows:
--boundary-1 content-type: message/delivery-status
Reporting-MTA: x400; bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold
400/C=gb/ Arrival-Date: Thu, 7 Feb 1991 15:48:34 +0000 DSN-Gateway:
dns; bells.cs.ucl.ac.uk X400-Conversion-Date: Thu, 7 Feb 1991
15:48:40 +0000 Original-Envelope-Id:
[/PRMD=uk.ac/ADMD=gold
400/C=gb/;<1803.665941698@UK.AC.UCL.CS>] X400-Content-Identifier:
Greetings. X400-Subject-Intermediate-Trace-Information:
/PRMD=uk.ac/ADMD=gold 400/C=gb/;
arrival Thu, 7 Feb 1991 15:48:20 +0000 action Relayed X400-
Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold
400/C=gb/;
arrival Thu, 7 Feb 1991 15:48:18 +0000 action Relayed
Original-Recipient: rfc822; H.Hildegard@bbn.com Final-Recipient:
x400;
/RFC-822=H.Hildegard(a)bbn.com/OU=cs/O=ucl/PRMD=uk.ac/ADMD=gold
400/C=gb/; Action: failure Status: 5.1.1 Diagnostic-Code: x400;
Reason 1 (Unable-To-Transfer);
Diagnostic 0 (Unrecognised-ORName) X400-Last-Trace: (ia5) Thu, 7
Feb 1991 15:48:18 +0000; X400-Originally-Specified-Recipient-Number:
1 X400-Supplementary-Info: "MTA 'bbn.com' gives error message (USER)
Unknown user name in "H.Hildegard@bbn.com"";
--boundary-1 Content-Type: message/rfc822
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
--boundary-1--
Example Delivery Report 2:
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:46:11 +0000
Message-ID: <"DLE/910207154840Z/000"@cs.ucl.ac.uk>
X400-Content-Identifier: A useful mess...
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=boundary-1
--boundary-1
This report relates to your message:
A useful mess...
of Thu, 7 Feb 1991 15:43:20 +0000
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 Original Message is not available
--boundary-1
content-type: message/delivery-status
Reporting-MTA: x400; /PRMD=DGC/ADMD=GOLD 400/C=GB/
Arrival-Date: Thu, 7 Feb 1991 15:48:40 +0000
DSN-Gateway: dns; bells.cs.ucl.ac.uk
X400-Conversion-Date: Thu, 7 Feb 1991 15:49:12 +0000
Original-Envelope-Id:
[/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>]
X400-Content-Identifier: A useful mess...
Original-Recipient: rfc822; j.nosuchuser@dle.cambridge.DGC.gold-400.gb
Final-Recipient: x400;
/I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=GOLD 400/C=GB/
Action: failure
Status: 5.1.1
Diagnostic-Code: x400; Reason 1 (Unable-To-Transfer);
Diagnostic 0 (Unrecognised-ORName)
X400-Supplementary-Info: "DG 21187: (CEO POA) Unknown addressee."
X400-Originally-Specified-Recipient-Number: 1
--boundary-1--
5.3.9. Probe
This is an MTS internal issue. Any probe shall be serviced by the
gateway, as there is no equivalent RFC822 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.
Appendix A - Mappings Specific to SMTP
This Appendix is specific to the Simple Mail Transfer Protocol (RFC
821). It describes specific changes in the context of this protocol.
When MIXER is used with SMTP, conformance to this appendix is
mandatory.
1. Probes
When servicing a probe, as described in section 5.3.9, use may be
made of the SMTP VRFY command to increase the accuracy of information
contained in the delivery report.
2. Long Lines
SMTP is a text oriented protocol, and is required to support a line
length of at least 1000 characters. Some implementations do not
support line lengths greater than 1000 characters. This can cause
problems. Where body parts have long lines, it is recommended to use
a MIME encoding that folds lines (quoted printable).
3. SMTP Extensions
There are several RFCs that specify extensions to SMTP. Most of these
are not relevant to MIXER. The NOTARY work to support delivery
report defines extensions which are relevant [29]. Use of these
extensions by a MIXER gateway is optional. If these extensions are
used, they shall be used in the manner described below.
3.1. SMTP Extension mapping to X.400
Mappings are defined for the following extensions:
NOTIFY
This is used to set the report and non-delivery bits of
MTA.PerRecipientMessageTransferFields.per-recipient-indicators.
If the value is NEVER, both bits are zero. If SUCCESS is present,
the report bit is set. Otherwise, the non-delivery-report bit is
set. If the gateway uses the NOTIFY command, it shall perform
this mapping in all cases.
ORCPT
If the address type of the original recipient is "x400" or
"rfc822", this may be used at the MTS level, to generate an
element of redirection history, with the redirection date being
the date of conversion and the reason set to "alias".
ENVID
If present, this may be used to generate a content correlator.
This is used rather than the MTS Identifier, as the ENVID is
unique for the UA only and is likely to be too large to map to an
MTS identifier. The content correlator is encoded as an IA5 String
containing the ENVID and prefixed by the string:
"SMTP/NOTARY ENVID: "
If the ENVID starts with the string "X400-MTS-Identifier: ", then
this ENVID was generated from an X.400 MTS Identifier. The
reverse mapping defined in Section 3.2 of Appendix A shall not be
used, as this may cause problems in certain situations (e.g.,
where the message was expanded by an Internet mailing list).
3.2. X.400 Mapping to SMTP Extensions
The following extensions may be used as a part of the MIXER mapping:
NOTIFY
The originator-report and originator-non-delivery-report bits of
MTA.PerRecipientMessageTransferFields.per-recipient-indicators
determine how this is used. If both bits are zero, the parameter
is NEVER. If the report bit is set, SUCCESS is used. Otherwise,
FAILURE is used. If this is done, the gateway shall not generate
a delivery report for this recipient, unless this is needed in the
case where the originating MTA service report requirements differ
from the user requirements. Additional originating MTA
requrirements are satisfied by the gateway.
ORCPT
If the MTS.perRecipientDeliveryFields.originally-intended-
recipient-name is present, the ORCPT command may be used to carry
this value, using the "x400" syntax.
ENVID
This may be generated, with the value taken from the
MTS.MessageDeliveryEnvelope.message-delivery-identifer. If this
is done, it shall be encoded as EBNF.mts-msg-id, preceded by the
string "X400-MTS-Identifier: ".
RET
If MTA.PerMessageTransferFields.per-message-indicators.content-
return-request is set to FALSE, the parameter RET may be set to
HDRS, to specify return of headers only.
Appendix B - Mapping with X.400(1984)
This appendix defines modifications 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. The heading extension feature is used at the IPMS level, and
this shall be replaced by the RFC987 approach. All header
information which would usually be mapped into the rfc-822-heading-
list extension 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. RFC822 extended headers
which could be mapped into X.400(1988) elements, are also mapped to
the body part.
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 shall 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 shall be treated as an RFC822
address, which will usually lead to encoding as a DDA "RFC-822".
It is possible that attributes of zero length may be present
in an OR Address. This is not legal in 1988, except for ADMD
where the case is explicitly described in Section 4.3.5.
Attributes of zero length are deprecated (the attribute shall be
omitted), and will 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 shall be
mapped onto a Domain Defined Attribute "Common". This is in line
with RFC1328 on X.400 1988 to 1984 downgrading [22].
This specification defines a mapping of the Internet message
framework to X.400. Body part mappings are defined in RFC
2157 [6], which relies on X.400(88) features. Downgrading to
X.400(84) for body parts is defined in RFC1496 (HARPOON), which
shall be followed in the context of this appendix [5].
Appendix C - 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 access 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
/ "X400-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 X400-Content-Return
allow for override of the default settings for
MTS.PerMessageIndicators.
Use of NOTARY mechanisms is a preferred meachanism for controlling
these parameters.
Appendix D - Object Identifier Assignment
The following Object Identifiers shall be used.
internet ::= OBJECT IDENTIFIER { iso org(3) dod(6) 1 } -- from RFC
1155
mail OBJECT IDENTIFIER ::= { internet 7 } -- IANA assigned
mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC
1495
mixer-core OBJECT IDENTIFIER ::= { mixer core(3) }
id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2}
id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3}
id-dsn-field-list OBJECT IDENTIFIER ::= {mixer-core 4}
eit-mixer OBJECT IDENTIFIER ::= {mixer-core 5}
-- the MIXER pseudo-EIT
This object identifier for id-rfc-822-field-list is different to
the one assigned in RFC1327, which was erroneous.
Appendix E - BNF Summary
boolean = "TRUE" / "FALSE"
numericstring = *(DIGIT / " ")
printablestring = *( ps-char )
ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
ps-delim = "(" / ")"
ps-char = ps-delim / ps-restricted-char
ps-encoded = *( ps-restricted-char / ps-encoded-char )
ps-encoded-char = "(a)" ; (@)
/ "(p)" ; (%)
/ "(b)" ; (!)
/ "(q)" ; (")
/ "(u)" ; (_)
/ "(l)" ; "("
/ "(r)" ; ")"
/ "(" 3DIGIT ")"
teletex-string = *( ps-char / t61-encoded )
t61-encoded = "{" 1* t61-encoded-char "}"
t61-encoded-char = 3DIGIT
teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]
labelled-integer ::= [ key-string ] "(" numericstring ")"
labelled-integer-2 ::= [ numericstring ] "(" key-string ")"
key-string = *key-char
key-char = <a-z, A-Z, 0-9, and "-">
object-identifier ::= oid-comp object-identifier
| oid-comp
oid-comp ::= [ key-string ] "(" numericstring ")"
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)
encoded-pn = [ given "." ] *( initial "." ) surname
given = 2*<ps-char not including ".">
initial = ALPHA
surname = printablestring
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "RFC-822"
/ dd-key "." std-printablestring
std-or-address-input = [ sep pair ] sep pair *( sep pair )
sep [ pair sep ]
sep = "/" / ";"
pair = input-attribute "=" value
input-attribute = attribute
/ dd-key ":" std-printablestring
standard-type = key-string
dd-key = key-string
value = std-printablestring
std-printablestring
= *( std-char / std-pair )
std-char = <"{", "}", "*", and any ps-char
except "/" and "=" >
std-pair = "$" ps-char
global-id = std-or-address