example:
/I=J/S=Linnimouth/GQ=5/@Marketing.Widget.COM
encodes the MTS.ORAddress consisting of:
MTS.CountryName = "TC"
MTS.AdministrationDomainName = "BTT"
MTS.OrganizationName = "Widget"
MTS.OrganizationalUnitNames.value = "Marketing"
MTS.PersonalName.surname = "Linnimouth"
MTS.PersonalName.initials = "J"
MTS.PersonalName.generation-qualifier = "5"
on the basis of an MCGAM pair between:
Domain: Widget.COM
OR Address: O="Widget", ADMD="BTT", C="TC"
Given the OR address, the domain Widget.COM is determined from the
equivalence mapping and the next component is determined
algorithmically to give Marketing.Widget.COM. The remaining
attributes are encoded on the LHS in 822.local-part.
There is a further mechanism to simplify the encoding of common
cases, where the only attributes to be encoded on the LHS are (non-
Teletex) Personal Name attributes which comply with the restrictions
of 4.1.2. To achieve this, the 822.local-part shall be encoded as
EBNF.encoded-pn. In the previous example, if the GenerationQualifier
was not present in the OR Address, it would map with the RFC822
address: J.Linnimouth@Marketing.Widget.COM.
From the standpoint of the RFC822 Message Transfer System, the
domain specification is used to route the message in the standard
manner. The standard domain mechanisms are used to select
appropriate gateways for the corresponding OR Address space. It is
the responsibility of the management that defines the equivalence
mapping to define routing in the manner which will enable the message
to be delivered.
4.3.2. RFC822 encoded in X.400
The previous section showed a mapping from X.400 to RFC822. In the
case where the mapping was symmetrical and based on the equivalence
mapping, this has also shown how RFC822 is encoded in the X.400.
This equivalence cannot be used for all RFC822 addresses.
The general case is mapped by use of domain defined attributes. A
(Printable String) Domain defined type "RFC-822" is defined. The
associated attribute value is an ASCII string encoded according to
Section 3.3.3 of this specification. The interpretation of the ASCII
string follows RFC822, and RFC1123 [10,16]. Domains shall always
be fully qualified.
Other OR Address attributes will be used to identify a context in
which the OR Address will be interpreted. This might be a Management
Domain, or some part of a Management Domain which identifies a
gateway MTA. For example:
C = "GB"
ADMD = "GOLD 400"
PRMD = "UK.AC"
O = "UCL"
OU = "CS"
"RFC-822" = "Jimmy(a)WIDGET-LABS.CO.UK"
OR
C = "TC"
ADMD = "Wizz.mail"
PRMD = "42"
"rfc-822" = "postel(a)venera.isi.edu"
Note in each case the PrintableString encoding of "@" as "(a)". In
the second example, the "RFC-822" domain defined attribute is
interpreted everywhere within the (Private) Management Domain. In
the first 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.
There is a limit of 128 characters in the length of value of a domain
defined attribute, and an OR Address can have a maxmimum of four
domain defined attributes. Where the printable string generated from
the RFC822 address exceeds 128 characters, additional domain defined
attributes are used to enable up to 512 characters to be encoded.
These attributes shall be filled completely before the next one is
started. The (Printable String) DDA keywords are: RFC822C1;
RFC822C2; RFC822C3. Longer addresses cannot be encoded.
MIXER defines a representation of RFC822 addresses in printable
string domain defined attributes. Teletex domain defined attributes
with a key of RFC-822, RFC822C1; RFC822C2; RFC822C3 shall not be
generated. This is for backwards compatibility reasons.
Reception of these attributes in the manner defined below is
mandatory. This is to allow the possibility for future versions of
MIXER to allow generation of teletex domain defined attributes.
Where the values of all of these teletex domain defined attributes
are printable string characters, they shall be interpreted in the
same way as the printable string domain defined attributes. If this
is not the case, the printable string encoding translation shall be
omitted. If both teletex and printable string attributes are
present, this is valid if and only if they represent exactly the same
RFC822 address.
4.3.3. Component Ordering
In most cases, ordering of OR Address components is not significant
for the mappings specified. However, Organizational Units (printable
string and teletex forms) and Domain Defined Attributes are specified
as SEQUENCE in MTS.ORAddress, and so their order may be significant.
This specification needs to take account of this:
1. To allow consistent mapping into the domain hierarchy
2. To ensure preservation of order over multiple mappings.
There are three places where an order is specified:
1. The text encoding (std-or-address) of MTS.ORAddress as used
in the local-part of an RFC822 address. An order is needed
for those components which may have multiple values
(Organizational Unit, and Domain Defined Attributes). When
generating an 822.std-or-address, components of a given type
shall be in hierarchical order with the most significant
component on the RHS (right hand side or domain part). If
there is an Organization Attribute, it shall be to the right
of any Organizational Unit attributes. These requirements
are for the following reasons:
- Alignment to the hierarchy of other components in RFC
822 addresses (thus, Organizational Units will appear
in the same order, whether encoded on the RHS or LHS).
- Backwards compatibility with RFC987/1026.
- To ensure that gateways generate consistent addresses.
This is both to help end users, and to generate
identical message ids.
Further, it is recommended that all other attributes are generated
according to this ordering, so that all attributes so encoded follow
a consistent hierarchy. When generating 822.msg-id, this order shall
be followed.
2. For the Organizational Units (OU) in MTS.ORAddress, the
first OU in the SEQUENCE is the most significant, as specified
in X.400.
3. For the Domain Defined Attributes in MTS.ORAddress, the
First Domain Defined Attribute in the SEQUENCE is the most
significant.
Note that although this ordering is mandatory for this mapping, MIXER
does not give additional implications on the ordering significance
within X.400.
4.3.4. RFC822 -> X.400 Basic Address Mapping
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 shall proceed as follows, by first assuming case 1).
STAGE I.
1. If the 822-address is not of the form:
local-part "@" domain
take the domain which will be routed on and apply step 2 of stage
1 to derive (a possibly null) set of attributes. Then go to stage
II.
The gateway may reduce a source route address to this form by
removal of all but the last domain. In terms of the design
intentions of RFC822, this would be an incorrect action. (Note
that an address of the form local%part@domain is not a source
route). However, in most cases, it will provide a better service
to the end user, and is in line with the Internet Host
Requirements. This is a reflection on the common inappropriate
use of source routing in RFC822 based systems, despite the
discussion in the Host Requirements [10]. Either approach, or
the intermediate approach of stripping only domain references
which reference the local gateway are conformant to this
specification.
2. If the 822.local-part uses the 822.quoted-string encoding,
remove this quoting. If the resulting unquoted
822.local-part has leading space, trailing space, or two
adjacent spaces go to stage II.
3. If the unquoted 822.local-part contains any characters not
in PrintableString, "{", "}", "*", and "$", go to stage II.
4. Parse the (unquoted) 822.local-part according to the EBNF
EBNF.std-or-address-input. Checking of upper bounds shall
not be done at this point. If this parse fails, parse the
local-part according to the EBNF EBNF.encoded-pn. If this
parse fails, go to stage II. The result is a set of
type/value pairs.
5. Associate the EBNF.attribute-value syntax (determined from
the identified type) with each value, and check that it
conforms. If not, go to stage II.
6. If the set of attributes forms a valid X.400 address,
according to X.402, then go to step 9. All forms of X.400
address are allowed at this stage. Steps 7-8 default
attributes for certain types of OR Address.
7. If the set of attributes cannot form a mnemonic form of
X.400 address after addition of attributes which may be
derived from the EBNF.domain (C, ADMD, PRMD, O, OU), go to
stage II.
8. Attempt to parse EBNF.domain as:
*( domain-syntax "." ) known-domain
Where EBNF.known-domain is the longest possible match in the set
of MCGAMs being used by the gateway (described in Section 4.2).
EBNF.domain-syntax is the restricted domain syntax defined in
Section 4.2, to which all of the domain components shall conform
for the parse to be successful. If this fails, go to stage II.
For each component, systematically allocate the attribute
implied by each EBNF.domain-syntax component in the order: C,
ADMD, PRMD, O, OU. Note that if the MCGAM used identifies an
"omitted attribute", then this attribute shall be omitted in the
systematic allocation. If this new component exceed an upper
bound (ADMD: 16; PRMD: 16; O: 64; OU: 32) or it would lead to
more than four OUs, then go to stage II with the attributes
derived.
The attributes derived in this step (referred to as RHS
attributes) are merged with the ones derived from the LHS (step
6). In some cases, not all of the RHF attributes are used. LHS
attributes are all used. C will not be in the LHS attributes.
If ADMD is in the LHS attributes, only C is taken from the RHS
attributes. If PRMD is in the LHS attributes, C and ADMD are
taken from the RHS attributes. If O is on the LHS, C, ADMD and
PRMD (if present) are taken from the RHS attributes. In other
cases all RHS attributes are taken.
9. Ensure that the set of attributes conforms both to the
MTS.ORAddress specification and to the restrictions on this
set given in X.400, and that no upper bounds are exceeded
for any attribute. If not go to stage II.
10. Build the OR Address from this information.
STAGE II.
This will only be reached if the RFC822 EBNF.822-address is not a
valid X.400 encoding. This implies that the address refers to a
recipient on an RFC822 system or that the encoding of the address is
invalid. Such addresses shall be encoded in an X.400 OR Address
using a domain defined attribute.
1. Convert the EBNF.822-address to PrintableString, as
specified in Chapter 3.
2. Generate the "RFC-822" domain defined attribute from this
string.
3. Build the rest of the OR Address in the manner described
below.
It is not always possible to encode the domain defined attribute
due to length restrictions. If the limit is exceeded by a
mapping at the MTS level, then the gateway shall reject the
message in question. If this occurs at the IPMS level, then the
action will depend on the policy being taken for IPMS encoding,
which is discussed in Section 5.1.3.
Use Stage I, step 8, to generate a set of attributes to build the
remainder of the address. The administrative equivalence of the
mappings will ensure correct routing through X.400 to a gateway
back to RFC822.
If Stage I, step 8 does not generate a set of attributes or
the address generated is unroutable, the remained of the OR
address is generated as follows. The remainder of the OR address
effectively identifies a source route to a gateway from the X.400
side. There are three cases, which are handled differently:
SMTP Return Address
This shall be set up so that errors are returned through the
same gateway. Therefore, the OR Address of the local
gateway shall be used.
IPMS Addresses
These are optimised for replying. In general, the message
may end up anywhere within the X.400 world, and so this
optimisation identifies a gateway appropriate for the RFC
822 address being converted. The 822.domain to which the
address would be routed is used to select an appropriate
gateway.
In this case, it may be useful to use a non-local gateway,
which will optimise the reply address. This information
may be looked up in gateway tables in a manner equivalent to
the MCGAM lookup. Because of the similarity of lookup, the
three MCGAM lookup mechanisms (table, X.500, DNS) are also
available to look up this information. This information is
local, and a gateway may insert any appropriate (gateway)
OR Address. The longest possible match on the 822.domain
defines which gateway to use. This mechanism is used for
any part of the X.400 namespace for which it is desirable to
identify a preferred X.400 gateway in order to optimise
routing.
If no mapping is found for the 822.domain, a default value
(typically that of the local gateway) is used. It is never
appropriate to ignore the locally used MCGAMs.
SMTP Recipient
As the RFC822 and X.400 worlds are in principle fully
connected, there is no technical reason for this situation
to occur. In practice, this is not the case. In some cases,
routing may be configured to use X.400 to connect an RFC822
island to the Internet. The information that this part of
the domain space is to be routed by X.400 rather than
remaining within the RFC822 world shall be configured
privately into the gateway in question. X.400 routing shall
not make use of the presence of the RFC-822 DDA to perform
X.400 routing. The OR address shall then be generated in
the same manner as for an IPMS address, using the locally
available MCGAMs. It is to support this case that the
definition of the global domain to gateway mapping is
important, as the use of this mapping will lead to a remote
X.400 address, which can be routed by X.400 routing
procedures. The information in this mapping shall not be
used as a basis for deciding to convert a message from RFC
822 to X.400.
Three examples are given, neither of which has applicable MCGAMs.
Example 1: (Address not in "localpart" "@" "domainpart")
@relay.co.uk:userb@host2
maps to
c=gb; a= ; p=uk.ac; o=mr; dd.rfc-822=(a)relay.co.uk:userb(a)host2;
Example 2: (Address with non printablestring characters)
Tom_Harris@cs.widget.com
maps to
c=us; a=MCI; P=relay; dd.rfc-822=Tom(u)Harris(a)cs.widget.com;
Example 3: (Address with an entry for alter.net into the OR Address
of Preferred Gateway table, pointing to c=gb; A=BTglobal; P=relay)
postmaster@UK.alter.net
maps to
c=gb; a=BTglobal; P=relay; dd.rfc-822=postmaster(a)UK.alter.net;
4.3.4.1. Heuristic for mapping RFC822 to X.400
The following heuristic, which relates to ordering of address
components, may be used when mapping from RFC822 to X.400. The
ordering of attributes may be inverted or mixed, and so the following
heuristics may be applied:
If there is an Organization attribute to the left of any Org Unit
attribute, assume that the hierarchy is inverted. This is to
facilitate the situation where a user has input the attributes in
reverse hierarchical order. To do this the gateway shall first
map according to the order defined in 4.3.3. If this mapping
generates an address which X.400 address verification shows to be
invalid, this heuristic may be applied as an alternative to
immediate rejection of the address.
4.3.5. X.400 -> RFC822 Basic Address Mapping
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 an MTS Recipient OR Address is interpreted, gatewaying will be
selected if there is a single "RFC-822" domain defined attribute
present. In this case, use mapping A and in other cases, use mapping
B.
RFC1327 specified that this shall only be done when the gateway
identfied is local or otherwise known, and identified the approach
specified here as a pragmatic option. Experience has shown that this
is effective in practice, despite theoretical problems.
If a gateway wishes to make a mapping in a manner similar to RFC
1327, but does not wish for this global interpretation (e.g., to
support an RFC822 local system, which does not use global
addressing), then it may choose a private domain defined attribute,
different to "RFC-822". An RFC1327 gateway might be configurable to
operate in this manner.
Mapping A
1. Map the domain defined attribute value to ASCII, as defined
in Chapter 3, and drop all other attributes.
Mapping B
This is used for X.400 addresses which do not use the explicit RFC
822 encoding.
1. For all string encoded attributes, remove any leading or
trailing spaces, and replace adjacent spaces with a single
space.
The only attribute which is permitted to have zero length is
the ADMD. This shall be mapped onto a single space.
These transformations are for lookup only. If an
EBNF.std-or-address mapping is used as in 4), then the
original values shall be used.
2. The numeric country codes may be mapped to the two letter
values (as defined in ISO 3166). Global mappings are
usually only defined in terms of the ISO 3166 codes.
3. Noting the hierarchy specified in 4.3.1 and including
omitted attributes, determine the maximum set of attributes
which have an associated domain specification in the local
set of MCGAMs. If no match is found, allocate the domain as
described below, and go to step 5. The default domain to be
used is the specification of the local gateway. A gateway
may use other domains according to private mapping tables or
heuristics. For example, it may choose a domain which it
knows to provide a free gateway service to the mapped
address.
In cases where the address refers to an X.400 UA, it is
important that the generated domain will correctly route to
a gateway. In general, this is achieved by carefully co-
ordinating RFC822 routing with the definition of the
MCGAMs, as there is no easy way for the gateway to make this
check. One rule that shall be used is that domains with
only one component will not route to a gateway. If the
generated domain does not route correctly, the address is
treated as if no match is found.
The gateway may also make use of a mapping equivalent to the
MCGAM mapping to determine the domain to use. This mapping
is done from the OR Address hierarchy. This is not a
global mapping, but is a routing style mapping from the OR
Address space, to enable a best choice domain to be
inserted. This mapping is supported by the three MCGAM
lookup mechanisms.
4. The mapping identified in 3) gives a domain, and an OR
address prefix. Follow the hierarchy: C, ADMD, PRMD, O, OU.
For each successive component below the OR address prefix, which
conforms to the syntax EBNF.domain-syntax (as defined in 4.3.1),
allocate the next subdomain. At least one attribute of the
X.400 address shall not be mapped onto subdomain, as 822.local-
part cannot be null. If there are omitted attributes in the OR
address prefix, these will have correctly and uniquely mapped to
a domain component. Where there is an attribute omitted below
the prefix, all attributes remaining in the OR address shall be
encoded on the LHS. This is to ensure a reversible mapping. For
example, if there is an address /S=XX/O=YY/ADMD=A/C=NN/ and a
mapping for /ADMD=A/C=NN/ is used, then /S=XX/O=YY/ is encoded
on the LHS.
5. If the address contains any attribute not used in mnemonic
form, then all of the attributes in the address shall be encoded
on the LHS in EBNF.std-or-address syntax, as described below.
For addresses of mnemonic form, if the remaining components are
personal-name components, conforming to the restrictions of
4.2.1, then EBNF.encoded-pn is derived to form 822.local-part.
In other cases the remaining components are simply encoded as
822.local-part using the EBNF.std-or-address syntax. If
necessary, the 822.quoted-string encoding is used. The
following are examples of legal quoting: "a b".c@x; "a b.c"@x.
Either form may be generated. Generation of the latter style is
strongly recommended.
Four examples are given.
Example 1: (Address with missing X.400 elements and no specific
mapping rule for "o=sales; a=Master400; C=it", where a mapping exists
for a=master400; C=it;)
S=Support; O=sales; A=Master400; C=it;
maps to
/S=Support/o=sales/@Master400.it
Example 2: (Address with illegal characters in RFC822 generated
domain if default hierarchical translation (specific mapping rule is
existing for c=fr; a=atlas; p=autoroutes) is used)
S=renseignements; O=Region Parisienne; P=autoroutes; A=atlas; C=fr;
maps to
"/S=renseignements/o=Region Parisienne/"@autoroutes.fr
Example 3: (Address containing elements not mappable into RFC822
local part)
S=Rossi; DD.cap=20100; DD.ph1=Via Larga 11; DDA.city=Milano;
A=PtPostel; C=it;
maps to
"/DD.cap=20100/DD.ph1=Via Larga
11/DD.city=Milano/S=Rossi/"@ptpostel.it
Example 4: (Address with an entry for A=ATT; C=us; into the domain
of Preferred Gateway table, pointing to attmail.com)
G=Andy; S=Wharol; O=MMNY; A=ATT; C=us;
maps to
/G=Andy/S=Wharol/O=MMNY@attmail.com
4.4. Repeated Mappings
There are two types of repeated mapping:
1. A recursive mapping, where the repeat is within one gateway
2 A source route, where the repetition occurs across multiple
gateways
4.4.1. Recursive Mappings
It is possible to supply an address which is recursive at a single
gateway. For example:
C = "XX"
ADMD = "YY"
O = "ZZ"
"RFC-822" = "Smith(a)ZZ.YY.XX"
This is mapped first to an RFC822 address, and then back to the
X.400 address:
C = "XX"
ADMD = "YY"
O = "ZZ"
Surname = "Smith"
In some situations this type of recursion may be frequent. It is
important where this occurs, that no unnecessary protocol conversion
occurs. This will minimise loss of service.
4.4.2. Source Routes
The mappings defined are symmetrical and reversible across a single
gateway. The 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 OR
Addresses 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.
When a message traverses multiple gateways, the mapping will always
be reversible, in that a reply can be generated which will correctly
reverse the path. In many cases, the mapping will also be
symmetrical, which will appear clean to the end user. For example,
if countries "AB" and "XY" have RFC822 networks, but are
interconnected by X.400, the following may happen: The originator
specifies:
Joe.Soap@Widget.PTT.XY
This is routed to a gateway, which generates:
C = "XY"
ADMD = "PTT"
PRMD = "Griddle MHS Providers"
Organization = "Widget Corporation"
Surname = "Soap"
Given Name = "Joe"
This is then routed to another gateway where the mapping is reversed
to give:
Joe.Soap@Widget.PTT.XY
Here, use of the gateway is transparent.
Mappings will only be symmetrical where mapping equivalences are
defined. In other cases, the reversibility is more important, due to
the (far too frequent) cases where RFC822 and X.400 services are
partitioned.
The syntax may be used to source route. THIS IS STRONGLY
DISCOURAGED. For example:
X.400 -> RFC822 -> X.400
C = "UK"
ADMD = "Gold 400"
PRMD = "UK.AC"
"RFC-822" = "/PN=Duval/DD.Title=Manager/(a)Inria.ATLAS.FR"
This will be sent to an arbitrary UK Academic Community gateway by
X.400. Then it will be sent by JNT Mail to another gateway
determined by the domain Inria.ATLAS.FR (FR.ATLAS.Inria). This will
then derive the X.400 OR Address:
C = "FR"
ADMD = "ATLAS"
PRMD = "Inria"
PN.S = "Duval"
"Title" = "Manager"
Similarly:
RFC822 -> X.400 -> RFC822
"/RFC-822=jj(a)seismo.css.gov/PRMD=AC/ADMD=BT/C=GB/"@monet.berkeley.edu
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.5. Directory Names
Directory Names are an optional part of OR Name, along with OR
Address. The RFC822 addresses are mapped onto the OR Address
component. As there is no functional mapping for the Directory Name
on the RFC822 side, a textual mapping is used. There is no
requirement for reversibility in terms of the goals of this
specification. There may be some loss of functionality in terms of
third party recipients where only a directory name is given, but this
seems preferable to the significant extra complexity of adding a full
mapping for Directory Names.
The Directory Name shall be represented within an RFC822 comment
using the comaptible formats of RFC1484 or RFC1485. It is
recommended that the directory string format of RFC1485 is used
[24]. The User Friendly Name form of RFC1484 may be used [25].
4.6. MTS Mappings
The basic mappings at the MTS level are:
1) SMTP originator ->
MTS.PerMessageSubmissionFields.originator-name
MTS.OtherMessageDeliveryFields.originator-name ->
SMTP originator
2) SMTP recipient ->
MTS.PerRecipientMessageSubmissionFields
MTS.OtherMessageDeliveryFields.this-recipient-name ->
SMTP recipient
SMTP recipients and return addresses are encoded as EBNF.822-address.
The MTS Originator is always encoded as MTS.OriginatorName, which
maps onto MTS.ORAddressAndOptionalDirectoryName, which in turn maps
onto MTS.ORName.
4.6.1. RFC822 -> X.400 MTS Mappings
From the SMTP Originator, use the basic ORAddress mapping, to
generate MTS.PerMessageSubmissionFields.originator-name (MTS.ORName),
without a DirectoryName.
For recipients, the following settings are made for each component of
MTS.PerRecipientMessageSubmissionFields.
recipient-name
This is derived from the SMTP recipient by the basic ORAddress
mapping.
originator-report-request
This may either be set to "delivery-report", or set according to
SMTP extensions as set out in Appendix A.
explicit-conversion
This optional component is omitted, as this service is not needed
extensions
The default value (no extensions) is used
4.6.2. X.400 -> RFC822 MTS Mappings
The basic functionality is to generate the SMTP originator and
recipients. There is information present on the X.400 side, which
cannot be mapped into analogous SMTP services. For this reason, new
RFC822 fields are added for the MTS Originator and Recipients. The
information discarded at the SMTP level will be present in these
fields. In some cases a (positive) delivery report will be generated.
4.6.2.1. SMTP Mappings
Use the basic ORAddress mapping, to generate the SMTP originator
(return address) from MTS.OtherMessageDeliveryFields.originator-name
(MTS.ORName). If MTS.ORName.directory-name is present, it is
discarded. (Note that it will be presented to the user, as described
in 4.6.2.2).
The mapping uses the MTA level information, and maps each value of
MTA.PerRecipientMessageTransferFields.recipient-name, where the
responsibility bit is set, onto an SMTP recipient.
Note:The SMTP recipient is conceptually generated from
MTS.OtherMessageDeliveryFields.this-recipient-name. This is done
by taking MTS.OtherMessageDeliveryFields.this-recipient-name, and
generating an SMTP recipient according to the basic ORAddress
mapping, discarding MTS.ORName.directory-name if present.
However, if this model was followed exactly, there would be no
possibility to have multiple SMTP recipients on a single message.
This is unacceptable, and so layering is violated.
4.6.2.2. Generation of RFC822 Headers
Not all per-recipient information can be passed at the SMTP level.
For this reason, two new RFC822 headers are created, in order to
carry this information to the RFC822 recipient. These fields are
"X400-Originator:" and "X400-Recipients:".
The "X400-Originator:" field is set to the same value as the SMTP
originator. In addition, if
MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) contains
MTS.ORName.directory-name then this Directory Name shall be
represented in an 822.comment.
Recipient names, taken from each value of
MTS.OtherMessageDeliveryFields.this-recipient-name and
MTS.OtherMessageDeliveryFields.other-recipient-names are made
available to the RFC822 user by use of the "X400-Recipients:" field.
By taking the recipients at the MTS level, disclosure of recipients
will be dealt with correctly. However, this conflicts with a desire
to optimise mail transfer. There is no problem when disclosure of
recipients is allowed. Similarly, there is no problem if there is
only one RFC822 recipient, as the "X400-Recipients" field is only
given one address.
There is a problem if there are multiple RFC822 recipients, and
disclosure of recipients is prohibited. In this case, discard the
per-recipient information.
If any MTS.ORName.directory-name is present, it shall be represented
in an 822.comment.
If MTS.OtherMessageDeliveryFields.orignally-intended-recipient-name
is present, then there has been redirection, or there has been
distribution list expansion. Distribution list expansion is a per-
message option, and the information associated with this is
represented by the "DL-Expansion-History:" field described in Section
5.3.6. Other information is represented in an 822.comment associated
with MTS.OtherMessageDeliveryFields.this-recipient-name, The message
may be delivered to different RFC822 recipients, and so several
addresses in the "X400-Recipients:" field may have such comments.
The non-commented recipient is the RFC822 recipient. The EBNF of the
comment is defined by redirect-comment.
redirect-comment = redirect-first *( redirect-subsequent )
redirect-first = "Originally To:" mailbox "Redirected on"
date-time "To:" redirection-reason
redirect-subsequent = mailbox "Redirected Again on"
date-time "To:" redirection-reason
redirection-history-item = "intended recipient" mailbox
"redirected to" redirection-reason
"on" date-time
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
/ "Directory Look Up"
/ "Alias"
It is derived from
MTA.PerRecipientMessageTransferFields.extension.redirection-history.
The values are taken from the X.400(92) Implementor's guide (Version
13, July 1995). The first three values are in X.400(88). The
fourth value is in X.400(92), but has the name "recipient-directory-
substitution-alternate-recipient". An example of this with two
redirects is:
X400-Recipients: postmaster@widget.com (Originally To:
sales-manager@sales.widget.com
Redirected on Thu, 30 May 91 14:39:40 +0100
To: Originator Requested Alternate Recipient
postmaster@sales.widget.com
Redirected Again on Thu, 30 May 91 14:41:20 +0100
To: Recipient MD Assigned Alternate Recipient)
In addition the following per-recipient services from
MTS.OtherMessageDeliveryFields.extensions are represented in comments
if they are used. None of these services can be provided on RFC822
networks, and so in general these will be informative strings
associated with other MTS recipients. In some cases, string values
are defined. For the remainder, the string value shall be chosen by
the implementor. If the parameter has a default value, then no
comment shall be inserted when the parameter has that default value.
requested-delivery-method
physical-forwarding-prohibited
"(Physical Forwarding Prohibited)".
physical-forwarding-address-request
"(Physical Forwarding Address Requested)".
physical-delivery-modes
registered-mail-type
recipient-number-for-advice
physical-rendition-attributes
physical-delivery-report-request
"(Physical Delivery Report Requested)".
proof-of-delivery-request
"(Proof of Delivery Requested)".
4.6.2.3. Delivery Report Generation
If SMTP is used, the behaviour is specified in Appendix A. In other
cases, if MTA.PerRecipientMessageTransferFields.per-recipient-
indicators requires a positive delivery notification, this shall be
generated by the gateway. Supplementary Information shall be set to
indicate that the report is gateway generated. This information
shall include the name of the gateway generating the report.
4.6.3. Message IDs (MTS)
A mapping from 822.msg-id to MTS.MTSIdentifier is defined. The
reverse mapping is not needed, as MTS.MTSIdentifier is always mapped
onto new RFC822 fields. The value of MTS.MTSIdentifier.local-part
will facilitate correlation of gateway errors.
To map from 822.msg-id, apply the standard mapping to 822.msg-id, in
order to generate an MTS.ORAddress. The Country, ADMD, and PRMD
components of this are used to generate MTS.MTSIdentifier.global-
domain-identifier. MTS.MTSIdentifier.local-identifier is set to the
822.msg-id, including the braces "<" and ">". If this string is
longer than MTS.ub-local-id-length (32), then it is truncated to this
length.
The reverse mapping is not used in this specification. It would be
applicable where MTS.MTSIdentifier.local-identifier is of syntax
822.msg-id, and it algorithmically identifies MTS.MTSIdentifier.
4.7. IPMS Mappings
All RFC822 addresses are assumed to use the 822.mailbox syntax.
This includes all 822.comments associated with the lexical tokens of
the 822.mailbox. In the IPMS OR Names are encoded as MTS.ORName.
This is used within the IPMS.ORDescriptor, IPMS.RecipientSpecifier,
and IPMS.IPMIdentifier. An asymmetrical mapping is defined between
these components.
4.7.1. RFC822 -> X.400
To derive IPMS.ORDescriptor from an RFC822 address.
1. Take the address, and extract an EBNF.822-address. Any
source routing shall be removed. This can be derived trivially
from either the 822.addr-spec or 822.route-addr syntax. This is
mapped to MTS.ORName as described above, and used as
IMPS.ORDescriptor.formal-name.
2. A string shall be built consisting of (if present):
- The 822.phrase component if the 822.address is an
822.phrase 822.route-addr construct.
- Any 822.comments, in order, retaining the parentheses.
This string is then encoded into T.61 using a human oriented
mapping (as described in Section 3.5). If the string is not
null, it is assigned to IPMS.ORDescriptor.free-form-name.
3. IPMS.ORDescriptor.telephone-number is omitted.
If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier,
IPMS.RecipientSpecifier.reply-request and
IPMS.RecipientSpecifier.notification-requests are set to default
values (false and none).
If the 822.group construct is present, any included 822.mailbox is
encoded as above to generate a separate IPMS.ORDescriptor. The
822.group is mapped to T.61 (as described in Section 3.5), and a
IPMS.ORDescriptor with only an free-form-name component built from
it.
4.7.2. X.400 -> RFC822
Mapping from IPMS.ORDescriptor to RFC822 address. In the basic
case, where IPMS.ORDescriptor.formal-name is present, proceed as
follows.
1. Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as
EBNF.822-address.
2a. If IPMS.ORDescriptor.free-form-name is present, convert it
to ASCII or T.61 (Section 3.5), and use this as the 822.phrase
component of 822.mailbox using the 822.phrase 822.route-addr
construct.
2b. If IPMS.ORDescriptor.free-form-name 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 an 822.phrase taken from
822.local-part is added.
3 If IPMS.ORDescriptor.telephone-number is present, this is
placed in an 822.comment, with the string "Tel ". The normal
international form of number is used. For example:
(Tel +44-181-333-7777)
4. If IPMS.ORDescriptor.formal-name.directory-name is present,
then a text representation is placed in a trailing 822.comment.
5. If IPMS.RecipientSpecifier.report-request has any non-
default values, then an 822.comment "(Receipt Notification
Requested)", and/or "(Non Receipt Notification Requested)",
and/or "(IPM Return Requested)" may be appended to the address.
"(Receipt Notification Requested)" may be used to infer "(Non
Receipt Notification Requested)". The effort of correlating P1
and P2 information is too great to justify the gateway sending
Receipt Notifications.
In RFC1327, inclusion of these comments was mandatory.
Experience has shown that the clutter and confusion caused to
RFC822 users does not justify the information conveyed.
Implementors are recommended to not include these comments.
Unless an application is found where retention of these comments
is desirable, they will be dropped from the next version.
6. If IPMS.RecipientSpecifier.reply-request is True, an
822.comment "(Reply requested)" is appended to the address.
If IPMS.ORDescriptor.formal-name is absent, IPMS.ORDescriptor.free-
form-name is converted to ASCII (see section 3.5), and used as
822.phrase within the RFC822 822.group syntax. For example:
Free Form Name ":" ";"
Steps 3-6 are then followed.
4.7.3. IP Message IDs
There is a need to map both ways between 822.msg-id and
IPMS.IPMIdentifier. This allows for X.400 Receipt Notifications,
Replies, and Cross References to reference an RFC822 Message ID,
which is preferable to a gateway generated ID. A reversible and
symmetrical mapping is defined. This provides fully reversible
mappings when messages pass multiple times across the X.400/RFC822
boundary.
An important issue with messages identifiers is mapping to the exact
form, as many systems use these ids as uninterpreted keys. The use
of table driven mappings is not always symmetrical, particularly in
the light of alternative domain names, and alternative management
domains. For this reason, a purely algorithmic mapping is used. A
mapping which is simpler than that for addresses can be used for two
reasons:
- There is no major requirement to make message IDs "natural"
- There is no issue about being able to reply to message IDs.
(For addresses, creating a return path which works is more
important than being symmetrical).
The mapping works by defining a way in which message IDs generated on
one side of the gateway can be represented on the other side in a
systematic manner. The mapping is defined so that the possibility of
clashes is low enough to be treated as impossible.
4.7.3.1. 822.msg-id represented in X.400
IPMS.IPMIdentifier.user is omitted. The IPMS.IPMIdentifier.user-
relative-identifier is set to a printable string encoding of the
822.msg-id with the angle braces ("<" and ">") removed. The upper
bound on this component is 64. The options for handling this are
discussed in Section 5.1.3.
4.7.3.2. IPMS.IPMIdentifier represented in RFC822
The 822.domain of 822.msg-id is set to the value "MHS". The
822.local-part of 822.msg-id is constructed by building a string of
syntax EBNF.id-loc from IPMS.IPMIdentifier.
id-loc ::= [ printablestring ] "*" [ std-or-address ]
EBNF.printablestring is the IPMS.IPMIdentifier.user-relative-
identifier, and EBNF.std-or-address being an encoding of the
IPMS.IPMIdentifier.user derived according to this specification.
822.local-part is derived from EBNF.id-loc, if necessary using the
822.quoted-string encoding. For example:
<"147*/S=Dietrich/O=Siemens/ADMD=DBP/C=DE/"@MHS>
4.7.3.3. 822.msg-id -> IPMS.IPMIdentifier
If the 822.local-part can be parsed as:
[ printablestring ] "*" [ std-or-address ]
and the 822.domain is "MHS", then this ID was X.400 generated. If
EBNF.printablestring is present, the value is assigned to
IPMS.IPMIdentifier.user-relative-identifier. If EBNF.std-or-address
is present, the OR Address components derived from it are used to set
IPMS.IPMIdentifier.user.
Otherwise, this is an RFC822 generated ID. In this case, set
IPMS.IPMIdentifier.user-relative-identifier to a printable string