RFC 2156
MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME
Pages: 144
Proposed Standard
Obsoletes: 0987 1026 1138 1148 1327 1495
Updates: 0822
Proposed Standard
Obsoletes: 0987 1026 1138 1148 1327 1495
Updates: 0822
Part 4 of 5 – Pages 87 to 119
5.3.2. RFC 822 Settings An RFC 822 Message has a number of mandatory fields in the RFC 822 Header. Some SMTP services mandate specification of an SMTP 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: SMTP 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 SMTP 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 = "Supersedes" ":" 1*msg-id
/ "Expires" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Content-Language" ":" 1#language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier
/ "Autosubmitted" ":" autosubmitted
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"
autosubmitted = "not-auto-submitted"
/ "auto-generated"
/ "auto-replied"
/ "auto-forwarded"
The mappings and actions for the IPMS.Heading are 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
shall be discarded, except 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 "Supersedes:". The replaces
the RFC 1327 field "Obsoletes:". Reverse mapping of the RFC 1327
field may be supported.
IPMS.Heading.related-IPMs
Mapped to "References:".
IPMS.Heading.subject
Mapped to "Subject:". The contents are converted to ASCII or T.61
(as defined in Section 3.5). CRLF will not be present in a valid
X.400 field. Any CRLF present are not mapped, but are used as
points at which the subject field shall be folded, unless an RFC
1522 encoding is used.
IPMS.Heading.expiry-time
Mapped to the extended RFC 822 field "Expires:". The replaces the
RFC 1327 field "Expiry-Date:". Reverse mapping of the RFC 1327
field may be supported.
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 RFC 822 field "Content-Language:", defined in RFC
1766 [7]. This mapping may be made without loss of information.
auto-submitted
Map to the extended RFC 822 field "Autosubmitted:".
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:". 5.3.4.1. Mapping the IPMS Body The mapping of the IPMS Body is defined in RFC 2157. 5.3.4.2. Example Message An example message, illustrating a number of aspects is given below. 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 X400-Content-Type: P2-1984 (2) X400-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>, Tony Bates <tony@ean-relay.ac.uk>, Steve Kille <S.Kille@cs.ucl.ac.uk> Subject: Email Problems Sender: Stephen.Harrison@gosip-uk.hmg.gold-400.gb MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=boundary-1 --boundary-1 Content-Type: text/plain; charset=US-ASCII Hope you gentlemen.......
Regards, Stephen Harrison UK GOSIP Project --boundary-1 Content-Type: message/rfc822 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 Content-Type: multipart/mixed; boundary=boundary-2 --boundary-2 Dear Mr Harrison...... --boundary-2-- --boundary-1-- 5.3.5. Mappings from an IP Notification Because of the service setting, IP Notifications will not usually need to be mapped by a MIXER gateway. 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 shall 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
Discarded-X400-IPMS-Extensions:
Used for any discarded IPN extensions.
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:"
preferred-recipient = mailbox
receipt-time = date-time
auto-comment = printablestring
ipn-suppl = printablestring
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated" / "IPM Deleted"
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 shall 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 the
message is included. In this case, the message is formatted as
multipart/mixed, and the returned message included as
message/rfc822 after the text body part. 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
/ "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 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 SMTP 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
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 RFC 822 field "X400-Content-Identifier:".
In RFC 1327, 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 RFC 822 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 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 an extended RFC 822 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 RFC 822
message
- Making the X.400 trace information available on the RFC 822
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 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 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 RFC 822 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 RFC 1327. 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 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 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 RFC 1327); 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 RFC 1327. 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 RFC 822
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 RFC 822 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 RFC 822 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 RFC 822 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 RFC 822 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 RFC 822 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 RFC 822 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 RFC 822 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 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. 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 RFC 1327, and so they also illustrate the changes
between RFC 1327 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 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.
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 RFC 822, no changes to this specification are needed. When mapping from RFC 822 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 RFC 987 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. RFC 822 extended headers which could be mapped into X.400(1988) elements, are also mapped to the body part. In an environment where RFC 822 is of major importance, it may be desirable for downgrading to consider the case where the message was originated in an RFC 822 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 RFC 822 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 RFC 1328 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 RFC 1496 (HARPOON), which shall be followed in the context of this appendix [5].
Appendix C - RFC 822 Extensions for X.400 access This appendix defines a number of optional mappings which may be provided to give access from RFC 822 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 RFC 822 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 RFC 1327, which was erroneous.
(next page on part 5)