that the gateway can handle the lower levels.
As a further mechanism to simplify the encoding of common
cases, where the only attributes to be encoded on the LHS are
Personal Name attributes which comply with the restrictions of
4.2.2, the 822.local-part may be encoded as EBNF.encoded-pn.
An example encoding is:
/PN=J.Linnimouth/GQ=5/@Marketing.Xerox.COM
encodes the P1.ORName consisting of
P1.CountryName = "US"
P1.AdministrationDomainName = "ATT"
P1.OrganisationName = "Xerox"
P1.OrganisationalUnit = "Marketing"
P1.PersonalName.surName = "Linnimouth"
P1.PersonalName.initials = "J"
P1.PersonalName.GenerationQualifier = "5"
If the GenerationQualifier was not present, the encoding
J.Linnimouth@Marketing.Xerox.COM could be used.
Note that in this example, the first three attributes are
determined by the domain Xerox.COM. The OrganisationalUnit is
determined systematically.
There has been an implicit assumption that an RFC822 domain is
either X.400 or RFC822. This is pragmatic, but undesirable,
as the namespace should be structured on a logical basis which
does not necessarily correspond to the choice of Message
Transfer protocols. The restriction can be lifted, provided
that the nameservice deals with multiple message transfer
protocols. This can happen in a straightforward manner for the
UK NRS, as explained in [Kille86a]. It could also be achieved
with the DARPA Domain Nameserver scheme by use of the WKS
mechanism.
RFC987 June 1986
Mapping between X.400 and RFC822
4.2.2. RFC822 Encoded in X.400
In some cases, the encoding defined above may be reversed, to
give a "natural" encoding of genuine RFC822 addresses. This
depends largely on the allocation of appropriate management
domains.
The general case is mapped by use of domain defined attributes.
Three are defined, according to the full environment used to
interpret the RFC822 information.
1. Domain defined type "RFC-822". This string is to be
interpreted in the context of RFC822, and RFC920
[Crocker82a,Postel84a].
2. Domain defined type "JNT-Mail". This string is to be
interpreted in the context of the JNT Mail protocol,
and the NRS [Kille84a,Larmouth83a].
3. Domain defined type "UUCP". This is interpreted
according to the constraints of the UUCP world
[Horton86a].
These three are values currently known to be of use. Further
recognised values may be defined. These will be maintained in
a list at the SRI Network Information Center.
Other O/R Name attributes will be used to identify a context in
which the O/R Name will be interpreted. This might be a
Management Domain, or some part of a Management Domain which
identifies a gateway MTA. For example:
1)
C = "GB"
ADMD = "BT"
PRMD = "AC"
"JNT-Mail" = "Jimmy(a)UK.CO.BT-RESEARCH-LABS"
2)
C = "US"
ADMD = "Telemail"
PRMD = "San Fransisco"
O = "U Cal"
OU = "Berkeley"
"RFC-822" = "postel(a)usc-isib.arpa"
RFC987 June 1986
Mapping between X.400 and RFC822
Note in each case the PrintableString encoding of "@" as "(a)".
In the first example, the "JNT-Mail" domain defined attribute
is interpreted everywhere within the (Administrative or
Private) Management Domain. In the second example, further
attributes are needed within the Management Domain to identify
a gateway. Thus, this scheme can be used with varying levels
of Management Domain co-operation.
4.2.3. RFC822 -> X.400
There are two basic cases:
1. X.400 addresses encoded in RFC822. This will also
include RFC822 addresses which are given reversible
encodings.
2. "Genuine" RFC822 addresses.
The mapping should proceed as follows, by first assuming case
1).
STAGE 1.
1. If the 822-address is not of the form:
local-part "@" domain
go to stage 2.
2. Attempt to parse domain as:
*( domain-syntax "." ) known-domain
Where known-domain is the longest possible match in a
list of gatewayed domains. If this fails, and the domain
does not explicitly identify the local gateway, go to
stage 2. If it succeeds, allocate the attributes
associated with EBNF.known-domain, and systematically
allocate the attributes implied by each
EBNF.domain-syntax component.
3. Map 822.local-part to ASCII, according to the
definition of Appendix A. This step should be applied:
A. If the source network cannot support
822.quoted-string (as discussed in Appendix A).
RFC987 June 1986
Mapping between X.400 and RFC822
B. If the address is an 822-P1 recipient.
This mapping is always applied in case B, as it
increases the functionality of the gateway, and does
not imply any loss of generality. Mapping case B
allows sites which cannot generate 822.quoted-string
to address recipients the gateway, without the gateway
having to know this explicitly. There is no loss of
functionality, as the quoting character of Appendix A
(#) is not in PrintableString. This seems desirable.
It should not be applied in to other addresses, as a
third party RFC#822 address containing the sequence
EBNF.atom-encoded (as defined in Appendix A) would be
transformed asymmetrically.
4. Map the result of 3) to EBNF.ps-encoded according to
section 3.
5. Parse the result of 4) according to the EBNF
EBNF.std-orname. If this parse fails, parse the result
of 4) according to the EBNF EBNF.encoded-pn. If this
also fails, go to stage 2. Otherwise, the result is a
set of type/value pairs.
6. Associate the EBNF.attribute-value syntax (determined
from the identified type) with each value, and check
that it conforms. If not, go to stage 2.
7. Ensure that the set of attributes conforms both to the
X.411 P1.ORName specification and to the restrictions
on this set given in X.400. If not go to stage 2.
8. Build the O/R Name from this information.
STAGE 2.
This will only be reached if the RFC822 EBNF.822-address is
not a valid X.400 encoding. If the address is an 822-P1
recipient address, it must be rejected, as there is a need to
interpret such an address in X.400. For the 822-P1 return
address, and any addresses in the RFC822 header, they should
now be encoded as RFC822 addresses in an X.400 O/R Name:
1. Convert the EBNF.822-address to PrintableString, as
specified in chapter 3.
2. The domain defined attribute ("RFC-822", "JNT-Mail" or
RFC987 June 1986
Mapping between X.400 and RFC822
"UUCP") appropriate to the gateway should be selected,
and its value set.
3. Build the rest of the O/R Name in the local Management
Domain agreed manner, so that the O/R Name will receive
a correct global interpretation.
4.2.4. X.400 -> RFC822
There are two basic cases:
1. RFC822 addresses encoded in X.400.
2. "Genuine" X.400 addresses. This may include
symmetrically encoded RFC822 addresses.
When a P1 Recipient O/R Name is interpreted, gatewaying will be
selected if there a single special domain defined attribute
present ("RFC-822", "JNT-Mail" or "UUCP"). In this case, use
mapping A. For other O/R Names which
1. Contain the special attribute.
AND
2. Identify the local gateway with the other attributes.
Use mapping A. In other cases, use mapping B.
Mapping A
1. Map the domain defined attribute value to ASCII, as
defined in chapter 3.
2. Where appropriate (P1 recipients), interpret the string
according to the semantics implied by the domain
defined attribute.
Mapping B.
This will be used for X.400 addresses which do not use the
explicit RFC822 encoding.
1. Noting the hierarchy specified in 4.3.1, determine the
maximum set of attributes which have an associated
domain specification. If no match is found, allocate
RFC987 June 1986
Mapping between X.400 and RFC822
the domain as the domain specification of the local
gateway, and go to step 4.
2. Following the 4.3.1 hierarchy, if each successive
component exists, and conforms to the syntax
EBNF.domain-syntax (as defined in 4.3.1), allocate the
next subdomain.
3. If the remaining components are personal-name
components, conforming to the restrictions of 4.2.2,
then EBNF.encoded-pn should be derived to form
822.local-part. In other cases the remaining
components should simply be encoded as a 822.local-part
using the EBNF.std-orname syntax. Where registered
domain defined types exist, the DD. syntax should not
be used.
4. If this step is reached for an 822-P1 recipient, then
the address is invalid. For other addresses, if the
derived 822.local-part can only be encoded by use of
822.quoted-string, the gateway may optionally use the
ASCII to 822.local-part mapping defined in Appendix A,
dependent on the mail protocols of the networks being
relayed to. Use of this encoding is discouraged.
4.3. Repeated Mappings
The mappings defined are symmetrical across a single gateway,
except in certain pathological cases (see chapter 3). However, it
is always possible to specify any valid address across a gateway.
This symmetry is particularly useful in cases of (mail exploder
type) distribution list expansion. For example, an X.400 user
sends to a list on an RFC822 system which he belongs to. The
received message will have the originator and any 3rd party X.400
O/R names in correct format (rather than doubly encoded). In
cases (X.400 or RFC822) where there is common agreement on
gateway identification, then this will apply to multiple gateways.
However, the syntax may be used to source route.
For example: X.400 -> RFC822 -> X.400
C = "UK"
ADMD = "BT"
PRMD = "AC"
"JNT-Mail" = "/PN=Duval/DD.Title=Manager/(a)FR.PTT.Inria"
RFC987 June 1986
Mapping between X.400 and RFC822
This will be sent to an arbitrary UK Academic Community gateway
by X.400. Then by JNT Mail to another gateway determined by
the domain FR.PTT.Inria. This will then derive the X.400 O/R
Name:
C = "FR"
ADMD = "PTT"
PRMD = "Inria"
PN.S = "Duval"
"Title" = "Manager"
Similarly: RFC822 -> X.400 -> RFC822
"/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/"
@monet.berkeley.edu
/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj#l#a#r#seismo.css.gov/
@monet.berkeley.edu
The second case uses the Appendix A encoding to avoid
822.quoted-text. This will be sent to monet.berkeley.edu by
RFC822, then to the AC PRMD by X.400, and then to
jj@seismo.css.gov by RFC822.
4.4. The full P1 / 822-P1 mapping
There are two basic mappings at the P1 level:
1. 822-P1 return address <-> P1.UMPDUEnvelope.originator
2. 822-P1 recipient <-> P1.RecipientInfo
822-P1 recipients and return addresses are encoded as
EBNF.822-address. As P1.UMPDUEnvelope.originator is encoded as
P1.ORName, mapping 1) has already been specified.
P1.RecipientInfo contains a P1.ORName and additional information.
The handling of this additional information is now specified.
4.4.1. RFC822 -> X.400
The following default settings should be made for each
component of P1.RecipientInfo.
P1.ExtensionIdentifier
This can be set systematically by the X.400 system.
RFC987 June 1986
Mapping between X.400 and RFC822
P1.RecipientInfo.perRecipientFlag
Responsibility Flag should be set. Report Request should
be set according to content return policy, as discussed
in section 5.3. User Report Request should be set to
Basic.
P1.ExplicitConversion
This optional component should be omitted.
4.4.2. X.400 -> RFC822
The mapping only takes place in cases where
P1.RecipientInfo.perRecipientFlag Responsibility Flag is set.
The following treatment should be given to the other
P1.RecipientInfo components.
P1.ExtensionIdentifier
Not used.
P1.RecipientInfo.perRecipientFlag
If ReportRequest is Confirmed or Audit-and-Confirmed then
a delivery report indicating success should be sent by
the gateway. This report should use each
P1.ReportedRecipientInfo.SupplementaryInformation to
indicate the identity of the gateway, and the nature of
the report (i.e. only as far as the gateway). Failures
will be handled by returning RFC822 messages, and so
User Report Request set to No report is ignored.
P1.ExplicitConversion
If present, the O/R name should be rejected, unless the
requested conversion can be achieved. None of the
currently recognised values of this parameter are
appropriate to a gateway using this specification.
RFC987 June 1986
Mapping between X.400 and RFC822
4.5. The full P2 / RFC822 mapping
All RFC822 addresses are assumed to use the 822.mailbox syntax.
This should include all 822.comments associated with the lexical
tokens of the 822.mailbox. All P2.ORNames are encoded within the
syntax P2.ORDescriptor, or P2.Recipient (or within Message IDs).
An asymmetrical mapping is defined between these components.
4.5.1. RFC822 -> X.400
The following sequence is followed.
1. Take the address, and extract an EBNF.822-address.
This can be derived trivially from either the
822.addr-spec or 822.route-addr syntax. This is mapped
to P2.ORName as described above.
2. A string should be built consisting of (if present):
- The 822.phrase component if it is a 822.phrase
822.route-addr construct.
- Any 822.comments, in order, retaining the
parentheses.
This string should then be encoded into T.61 (as
described in chapter 3). If the string is not null,
it should be assigned to P2.ORDescriptor.freeformName.
3. P2.ORDescriptor.telephoneNumber should be omitted.
4. In cases of converting to P2.Recipient,
P2.Recipient.replyRequest and
P2.Recipient.reportRequest should be omitted.
If the 822.group construct is present, each included
822.mailbox should be encoded as above. The 822.group should
be mapped to T.61, and a P2.ORDesciptor with only a
freeformName component built from it.
4.5.2. X.400 -> RFC822
In the basic case, where P2.ORName is present, proceed as
follows.
1. Encode P2.ORName as EBNF.822-address.
RFC987 June 1986
Mapping between X.400 and RFC822
2a. If P2.ORDescriptor.freeformName is present, convert it
to ASCII (chapter 3), and use use this as the
822.phrase component of 822.mailbox using the
822.phrase 822.route-addr construct.
2b. If P2.ORDescriptor.freeformName is absent, if
EBNF.822-address is parsed as 822.addr-spec use this as
the encoding of 822.mailbox. If EBNF.822-address is
parsed as 822.route 822.addr-spec, then a 822.phrase
taken from 822.local-part should be added.
3. If P2.ORDescriptor.telephoneNumber is present, this
should be placed in a trailing 822.comment.
4. If P2.Recipient.reportRequest has the
receiptNotification bit set, then an 822.comment
"(Receipt Notification Requested)" should be appended
to the address. The effort of correlating P1 and P2
information is too great to justify the gateway sending
Receipt Notifications.
5. If P2.Recipient.replyRequest is present, an 822.comment
"(Reply requested)" or "(Reply not requested)" should
be appended to the address, dependent on its value.
If P2.ORName is absent, P2.ORDescriptor.freeformName should be
converted to ASCII, and used with the RFC822 822.group syntax:
freeformname ":" ";"
Steps 3-5 should then be followed.
4.6. Message IDs
There is a need to map both ways between 822.msg-id and
P2.IPMessageID. A mapping is defined which is symmetrical for
non-pathological cases. The mapping allows for the fact that
P2.IPMessageID.PrintableString is mandatory for the Cen/Cenelec
profile. This allows for good things to happen when messages pass
multiple times across the X.400/RFC822 boundary. A mapping
between 822.msg-id and P1.MPDUIdentifier is defined. This allows
for X.400 error messages to reference an RFC822 ID, which is
preferable to a gateway generated ID.
RFC987 June 1986
Mapping between X.400 and RFC822
4.6.1. P2.IPMessageID -> 822.msg-id
P2.IPMessageID.ORName is used to generate an 822.addr-spec, as
defined above. P2.IPMessageID.PrintableString is mapped to
ASCII, as defined in chapter 3. This string (if it is present
and if the value is not "RFC-822") is appended to the front of
the 822.local-part of the 822.msg-id, with "*" as a separator.
If no ORName is present, an 822.msg-id of the form
"PrintableString*@gateway-domain" is generated.
4.6.2. 822.msg-id -> P2.IPMessageID
822.local-part is parsed as:
[ printablestring "*" ] real-local-part
If EBNF.printablestring is found, it is mapped to
PrintableString, and used as P2.IPMessageID.PrintableString.
Otherwise
P2.IPMessageID.PrintableString is set to "RFC-822". This
arbitrary value allows for conformance to Cen/Cenelec. If
EBNF.real-local-part is not present, no P2.IPMessageID.ORName
is generated. Otherwise, 822.local-part is replaced with
EBNF.real-local-part, and 822.addr-spec is mapped to
P2.IPMessageID.ORName as defined above.
4.6.3. 822.msg-id -> P1.MPDUIdentifier
P1.CountryName is assigned to "", P1.AdministrationDomainName
to 822.domain (from 822.msg-id) and P1.MPDUIdentifier.IA5String
to 822.local-part (from 822.msg-id).
4.6.4. P1.MPDUIdentifier -> 822.msg-id
822.local-part is set to P1.MPDUIdentifier.IA5String, with any
CRLF mapped to SPACE. If P1.CountryName is "", 822.domain is
set to P1.AdministrationDomainName; Otherwise to
P1.AdministrationDomainName ".." P1.CountryName. If there are
any specials, the domain literal encoding should be used.
RFC987 June 1986
Mapping between X.400 and RFC822
Chapter 5 -- Protocol Elements
This chapter gives detailed mappings for the functions outlined in
chapters 1 and 2. It makes extensive use of the notations and
mappings defined in chapters 3 and 4. This chapter is structured as
follows:
5.1. Basic RFC822 -> X.400 mappings
5.2. A definition of some new RFC822 elements, and their mapping
to X.400.
5.3 Some special handling associated with Return of Contents.
5.4. X.400 -> RFC822
5.1. RFC822 -> X.400
First, the basic functions of an 822-P1 protocol should be mapped
as follows:
822-P1 Originator
Mapped to P1.UMPDUEnvelope.originator (see chapter 4).
822-P1 Recipient
Mapped to P1.RecipientInfo (see chapter 4).
The RFC822 headers are used to generate both a P1.UMPDUEnvelope
and a P2.Heading. The IP Message will have either one or two
P2.BodyParts which will be type P2.IA5Text with no
P2.IA5Text.repertoire component. The last P2.BodyPart will contain
the RFC822 message body. If there are any RFC822 headers which
indicate mapping into the P2.BodyPart, then two P2.BodyParts are
generated. If a revised version of P2 allowed for extensible
header specification, this would be seen as a preferable mapping.
The first body part will start with the line:
RFC-822-Headers:
The rest of this body part will contain all of the headers not
otherwise mapped (both 822.field-name and 822.field-body). The
order of any such headers should be preserved. Similarly,
ordering within P2.Heading and P1.UMPDUEnvelope should reflect
ordering within the RFC822 header. No P1 or P2 optional fields
are generated unless specified.
RFC987 June 1986
Mapping between X.400 and RFC822
A pro-forma X.400 message is now specified. Some of these
defaults may be changed by the values in the RFC822 message being
mapped. The mandatory P1 and P2 components have the following
defaults.
P1.MPDUIdentifier
The default should be unique value generated by the gateway.
P1.OriginatorORName
Always generated from 822-P1.
P1.ContentType
P1.ContentType.p2
P1.RecipientInfo
These will always be supplied from 822-P1.
P1.Trace
The last P1.TraceInformation component is generated such
that: P1.TraceInformation.GlobalDomainIdentifier is set to
the local vaglue. P1.DomainSuppliedInfo.action is set to
relayed. P1.DomainSuppliedInfo.arrival is set to the current
time. P1.DomainSuppliedInfo.previous may be set if there is
anything sensible to set it to.
P2.IPMessageID
The default should be a unique value generated by the
gateway.
The following optional parameters should be set:
P1.PerMessageFlag
The P1.PerMessageFlag.contentReturnRequest bit should be set
according to the discussion in section 5.3. The
P1.PerMessageFlag.alternateRecipientAllowed bit should be
set, as it seems desirable to maximise opportunity for
(reliable) delivery.
RFC987 June 1986
Mapping between X.400 and RFC822
The RFC822 headings should be mapped as follows:
Received:
Fudged onto P1.TraceInformation (try not to grimace too
much). P1.DomainSuppliedInfo.action is set to relayed.
P1.DomainSuppliedInfo.arrival is set to the date-time
component P1.TraceInformation.GlobalDomainIdentifier has
P1.CountryName as a null string, and
P1..AdministrationDomainName as the domain of the receiving
host (if present - null string if not).
P1.DomainSuppliedInfo.previous has P1.CountryName as a null
string, and P1.AdministrationDomainName has the domain of
the sending host with all other information enclosed in
round parentheses. The encoding of ASCII to PrintableString
(chapter 3) should be used if needed. For example:
Received: from 44e.cs.ucl.ac.uk by vax2.Cs.Ucl.AC.UK
with SMTP id a002110; 18 Dec 85 10:40 GMT
maps to -
P1.GlobalDomainIdentifier
CountryName = ""
AdministrationDomainName = "vax2.Cs.Ucl.AC.UK"
P1.DomainSuppliedInfo
arrival = 18 Dec 85 10:40 GMT
action = relayed
previous
CountryName = ""
AdministrationDomainName =
"44e.cs.ucl.ac.uk (with SMTP id a002110)"
Date:
This is used to set the first component of
P1.TraceInformation. The mandatory components are set as
follows:
P1.GlobalDomainIdentifier
CountryName = ""
AdministrationDomainName = ""
P1.DomainSuppliedInfo
arrival = time derived from Date:
action = relayed
No optional fields are used in the trace.
RFC987 June 1986
Mapping between X.400 and RFC822
Message-Id:
Mapped to P2.IPMessageID. If the RFC822 message does not
contain a P1-Message-ID: field, the Message-Id: field is
also mapped to P1.MPDUIdentifier. For these, and all other
fields containing msg-id the mappings of chapter 4 are used
for each msg-id.
From:
If Sender: is present, this is mapped to
P2.AuthorisingUsers. If not, it is mapped to P2.Originator.
For this, and other components containing addresses, the
mappings of chapter 4 are used for each address.
Sender:
Mapped to P2.Originator.
Reply-To:
Mapped to P2.Heading.replyToUsers.
To:
Mapped to P2.Heading.primaryRecipients
Cc:
Mapped to P2.Heading.copyRecipients.
Bcc:
Mapped to P2.Heading.blindCopyRecipients.
In-Reply-To:
Mapped to P2.Heading.inReplyTo for the first (if any)
822.msg-id component. If the field contains an 822.phrase
component, or there are multiple 822.msg-id components, the
ENTIRE field is passed in the P2.BodyPart.
References:
Mapped to P2.Heading.crossReferences.
RFC987 June 1986
Mapping between X.400 and RFC822
Keywords:
Passed in the P2.BodyPart.
Subject:
Mapped to P2.Heading.subject. The field-body uses the
mapping referenced in chapter 3 from ASCII to T.61.
Comments:
Passed in the P2.BodyPart.
Encrypted:
Passed in the P2.BodyPart.
Resent-*
Passed in the P2..BodyPart <8>.
Other Fields
In particular X-* fields, and "illegal" fields in common
usage (e.g. "Fruit-of-the-day:") are passed in the
P2.BodyPart. The same treatment should be applied to
RFC822 fields where the content of the field does not
conform to RFC822 (e.g. a Date: field with unparsable
syntax).
5.2. Extended RFC822 Elements -> X.400
First an EBNF definition of a number of extended fields is given,
and then a mapping to X.400 is defined. In most cases, the
RFC822 syntax is defined to make this mapping very
straightforward, and so no detailed explanation of the mapping is
needed.
extended-field = "P1-Message-ID" ":" p1-msg-id
/ "X400-Trace" ":" x400-trace
/ "Original-Encoded-Information-Types"
":"encoded-info
/ "P1-Content-Type" ":" p1-content-type
/ "UA-Content-ID" ":" printablestring
/ "Priority" ":" priority
/ "P1-Recipient" : 1 mailbox
/ "Deferred-Delivery" ":" date-time
RFC987 June 1986
Mapping between X.400 and RFC822
/ "Bilateral-Info" ":" bilateral-info
/ "Obsoletes" ":" 1 msg-id
/ "Expiry-Date" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
p1-msg-id = global-id ";" *text
p1-content-type = "P2" / atom
x400-trace = global-id ";"
"arrival" date-time
[ "deferred" date-time ]
[ "action" action ]
[ "converted" "(" encoded-info ")" ]
[ "previous" global-id ]
action = "Relayed" / "Rerouted" / escape
global-id = c "*" admd [ "*" prmd ]
encoded-info = 1 encoded-type
encoded-type = "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)
/ escape
priority = "normal" / "non-urgent" / "urgent" / escape
bilateral-info = c "*" admd "*" *text
importance = "low" / "normal" / "high" / escape
sensitivity = "Personal" / "Private"
/ "Company-Confidential" / escape
escape = 1*DIGIT
RFC987 June 1986
Mapping between X.400 and RFC822
With the exception of "Bilateral-Info:" and "X400-Trace:", there
must be no more than one of each of these fields in an RFC822
header. Any field beginning with the String "Autoforwarded-" is
valid if the field would be syntactically valid with this string
removed.
The mappings to X.400 are as follows:
P1-Message-ID:
Mapped to P1.UMPDUEnvelope.MPDUIdentifier. This take
precedence over any value derived from Message-ID:.
X400-Trace:
Mapped to the next component of
P1.UMPDUEnvelope.Traceinformation. Care should be taken to
preserve order. If one or more of these mappings is made,
then a trace component should NOT be generated from the
Date: field which should be redundant. This is because the
message has previously come from X.400, and the Date:
information will be redundant. Note that all trace
information (Received: and "X400-Trace:") in the RFC822
message will be in strict order, with the most recent at the
top. This order should be preserved in the mapping.
Original-Encoded-Information-Types:
This is used to set P1.UMPDUEnvelope.original.
P1.EncodedInformationTypes.[0] has bits set according to
each of the encoded-info components in this field. Any
escape values should not be encoded.
P1-Content-Type:
If the value is anything other than "P2", the mapping should
not be performed (unless the new value has some semantics to
the gateway).
UA-Content-ID:
Mapped to P1.UMPDUEnvelope.UAContentID.
Priority:
Mapped to P1.UMPDUEnvelope.Priority. An escape value should
be encoded as P1.Priority.normal.
RFC987 June 1986
Mapping between X.400 and RFC822
P1-Recipient:
If this field is set, the
P1.PerMessageFlag.discloseRecipients bit should be set. Any
of the addresses here which do not correspond to 822-P1
recipients should be added to the P1 recipient list, with
the responsibility bit turned off.
Deferred-Delivery:
Mapped to P1.UMPDUEnvelope.deferredDelivery. Note that the
value of this field should always be in the past, as this
field should only be present in messages which have come
originally from X.400. Thus there should be no implied
action. See also the comments on the reverse mapping.
Bilateral-Info:
No attempt is made to reconvert this information back to
X.400.
Obsoletes:
Mapped to P2.Heading.obsoletes.
Expiry-Date:
Mapped to P2.Heading.expiryDate.
Reply-By:
Mapped to P2.Heading.replyBy.
Importance:
Mapped to P2.Heading.importance. An escape value should be
encoded as P2.Heading.importance.normal.
Sensitivity:
Mapped to P2.Heading.sensitivity. An escape value should be
encoded as P2.Heading.sensitivity.normal.
Autoforwarded:
If this field is present and the value is "TRUE", there will
be zero or more field names beginning "Autoforwarded-".
RFC987 June 1986
Mapping between X.400 and RFC822
These should be taken, and the string "Autoforwarded-"
stripped. These fields, in conjunction with the 822-P1
information should be used to build an IP Message. Any
implied actions should be taken. P2.Heading.autoforwarded is
set in this message. The other RFC822 fields are used to
build another IP Message, which is used as the single body
part of the first message. This mechanism does not nest.
5.3. Return of Contents
It is not clear how widely supported X.400 return of contents
service will be. However, profiling work suggests that most
systems will not support this service. As this service is
expected in the RFC822 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.
In environments where return of contents is widely supported, the
P1.PerMessageFlag content return request bit will be set, and the
Report Request bit in P1.PerRecipientFlag will be set to
Confirmed, for every message passing from RFC822 -> X.400. The
content return service can then be passed back to the end
(RFC822) user in a straightforward manner.
In environments where return of contents is not widely supported,
a gateway must make special provisions to handle return of
contents. For every message passing from RFC822 -> X.400, the
P1.PerMessageFlag content return request bit will be set, and the
Report Request bit in P1.PerRecipientFlag will be set to
Confirmed. 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-P1 originator. If no report is received for a
recipient, a (timeout) failure notice should be sent to the 822-P1
originator. The gateway may retransmit the X.400 message if it
wishes. Delivery confirmations should only be sent back to the
822-P1 originator if the P1.PerRecipientFlag User Report Request
bit is set to Confirmed.
RFC987 June 1986
Mapping between X.400 and RFC822
5.4. X.400 -> RFC822
5.4.1. General
This section describes how to build a pro-forma message, and
then explains how these defaults may be overridden. It should
be noted that RFC822 folding of headers should be used in an
appropriate manner.
5.4.2. Service MPDU
5.4.2.1. Probe
Any P1.ProbeMPDU should 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 a
User MPDU with the values specified in the probe. The reply
should make use of P1.SupplementaryInformation to indicate
that the probe was serviced by the gateway.
5.4.2.2. Delivery Report
The 822-P1 components are constructed as follows:
822-P1 Originator
This is set to an 822.addr-spec pointing to an
administrator at the gateway.
822-P1 Recipient
The single recipient is constructed from
P1.DeliveryReportEnvelope.originator, using the
mappings of chapter 4.
The mandatory RFC822 headers for an RFC822 pro-forma are
constructed as follows:
Date:
From the P1.DomainSuppliedInfo.arrival component of
the first P1.TraceInformation component.
From:
This is set to the same as the 822-P1 originator. An
RFC987 June 1986
Mapping between X.400 and RFC822
appropriate phrase component may be added (e.g. giving
the name of the gateway).
To:
The same as the 822-P1 recipient.
A Subject: field should be added, which contains some
appropriate words (e.g. "Delivery Report").
The other two P1.DeliveryReportEnvelope parameters should be
mapped as follows:
P1.DeliveryReportEnvelope.report
This should be mapped to a P1-Message-Id: field.
P1.DeliveryReportEnvelope.TraceInformation
Each component should be mapped to an "X400-Trace:"
field. RFC822 and X.400 ordering should be
maintained (see 5.3).
The P1.DeliveryReportContent parameters should be mapped to
a series of new RFC822 headers. These new headers are
intended for processing in the RFC822 world. No attempt
will be made to reverse the mappings.
drc-field = "Delivery-Report-Content-Original"
":" msg-id
/ "Delivery-Report-Content-Intermediate-Trace"
":" x400-trace
/ "Delivery-Report-Content-UA-Content-ID"
":" printablestring
/ "Delivery-Report-Content-Billing-Information"
":" *text
/ "Delivery-Report-Content-Reported-Recipient-Info"
":" drc-info
drc-info = mailbox ";"
last-trace ";"
"ext" 1*DIGIT
"flags" 2DIGIT
[ "intended" mailbox ] ";"
[ "info" printablestring ]
RFC987 June 1986
Mapping between X.400 and RFC822
last-trace = drc-report ";"
date-time ";"
[ "converted" "(" encoded-info ")"
drc-report = "SUCCESS" drc-success
/ "FAILURE" drc-failure
drc-success = date-time ";" 1*DIGIT
drc-failure = *text [ ";" *text ] ";"
There may be multiple
"Delivery-Report-Content-Intermediate-Trace:" and
"Delivery-Report-Content-Reported-Recipient-Info:" fields.
The msg-id for "Delivery-Report-Content-Original" is derived
according to the mapping of chapter 4. EBNF.drc-failure may
use numeric values or textual explanation. The latter is
preferred. All P1.DeliveryReportContent parameters are
mapped to the corresponding component. The order of
"Delivery-Report-Content-Intermediate-Trace:" should have
the most recently stamped one first.
The body of the RFC822 message should be a human readable
description of the critical parts of the
P1.DeliveryReportContent. In particular, the failed
recipients, and failure reason should be given. Some or all
of the original message should be included in the delivery
report. The original message will be available at the
gateway, as discussed in section 5.3.
5.4.3. User MPDU
These elements are the basis for both Status Report and IP
Message.
The 822-P1 components are constructed as follows:
822-P1 Originator
This is derived from P1.UMPDUEnvelope.originator.
822-P1 Recipient
Each recipient is constructed from the P1.RecipientInfo,
as described in chapter 4. This describes actions as
well as format mappings.
RFC987 June 1986
Mapping between X.400 and RFC822
The mandatory RFC822 field pro-forma is derived as follows.
In most cases where the P1.UMPDUContent is an IP Message, these
defaults will be overridden:
Date:
From the P1.DomainSuppliedInfo.arrival component of the
first P1.TraceInformation component.
From:
From the P1.UMPDUEnvelope.originator, as defined in
chapter 4.
To:
This default is only required if the generated RFC822
message has no destination specification. If
P1.PerMessageFlag.discloseRecipients is set then it
should contain the ORName in each P1.RecipientInfo
component. If it is not set, the it should be set to
"To: No Recipients Specified : ;".
The mappings, and any actions for each P1.UserMPDU element is
now considered.
P1.MPDUIdentifier
Mapped to the extended RFC822 field "P1-Message-ID:".
Note that the sequence CRLF is mapped to SPACE, which
makes the mapping irreversible for such cases.
P1.UMPDUEnvelope.original
Mapped to the extended RFC822 field
"Original-Encoded-Information-Types:". If it contains
only P2.IA5Text, the RFC822 field may be omitted.
P1.ContentType
As this can currently only have one value, it is not
mapped, on the basis that it is redundant. If the field
contains any value other than P2, then the UMPDU should
be rejected.
RFC987 June 1986
Mapping between X.400 and RFC822
P1.UAContentID
Mapped to the extended RFC822 field "UA-Content-Id:".
P1.Priority
Mapped to the extended RFC822 field "Priority:".
P1.PerMesageFlag
This has a number of components:
- discloseRecipients
If this bit is set, a "P1-Recipient:" field should
be generated, and contain each of the P1
recipients.
- conversionProhibited
If this bit is set, the message should be rejected
if it contains P2.BodyPart which is not P2.IA5Text
or P2.ForwardedIPMessage.
- alternateRecipientAllowed
The value of this bit is ignored.
- contentReturnRequest
The value of this bit is ignored.
P1.UMPDUEnvelope.deferredDelivery
This should be mapped to the extended RFC822 field
"Deferred-Delivery:". X.400 profiles, and in particular
the CEN/CENELEC profile [CEN/CENELEC/85a], specify that
this element must be supported at the first MTA. Thus,
it is expected that the value of this element will always
be in the past. 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 the extended RFC822 field
is just for information.
RFC987 June 1986
Mapping between X.400 and RFC822
P1.PerDomainBilateralInformation
Each component should be encoded in the extended RFC822
field "Bilateral-Info:". P1.BilateralInfo should be
mapped into ASCII in a manner appropriate to its