address
Click on the red underlined text to get to the source
... 1. Identification of a list of recipients.
2. Identification of an error return address.
3. Transfer of an RFC 822std11(-> 2822prop) ...
... Resent-*
Supported by use of a heading extension. Note that addresses in
these fields are mapped onto text, and so are not accessible to
the X.400 ...
... these fields are mapped onto text, and so are not accessible to
the X.400 user as addresses. In principle, fuller support would
be possible by mapping onto a forwarded IP Message, but this is
...
...
Originator Requested Alternate Recipient
Not supported, but is placed as comment next to address (X400-
Recipients:).
...
...
Reply Request Indication
Supported as comment next to address.
Replying IP Message ...
... N/A (reception).
Request for Forwarding Address
N/A (PDAU).
...
... brackets, are not included in PrintableString, but are common in RFC
822std11(-> 2822prop) addresses. The abbreviations will ease specification of RFC 822std11(-> 2822prop)
addresses ...
... addresses. The abbreviations will ease specification of RFC 822std11(-> 2822prop)
addresses from an X.400 system. These special encodings shall be
...
... discusses message identifiers, as they are closely linked to
addresses. This chapter, as a side effect, also defines a textual
representation of an X.400 OR ...
... representation of an X.400 OR Address. This specification has much
similarity to the X.400(92) representation of addresses ...
... Address. This specification has much
similarity to the X.400(92) representation of addresses. This was
because early versions of this specification were a major input to
...
... versions. The X.400 specification of address representation can be
parsed but is not generated.
...
...
Initially we consider an address in the (human) mail user sense of
"what is typed at the mailsystem to reference a mail user". A basic
RFC 822std11(-> 2822prop) ...
... "what is typed at the mailsystem to reference a mail user". A basic
RFC 822std11(-> 2822prop) address is defined by the EBNF EBNF.822-address:
...
... 822std11(-> 2822prop) header, the EBNF.822-
address is encapsulated in the 822-address syntax rule, and there may
...
... address is encapsulated in the 822-address syntax rule, and there may
also be associated comments. None of this extra information has any
semantics ...
...
The RFC 822std11(-> 2822prop) 822.address is mapped with IPMS.ORDescriptor, and that
RFC 822std11(-> 2822prop) ...
... IPMS.ORDescriptor, and that
RFC 822std11(-> 2822prop) EBNF.822-address is mapped with MTS.ORAddress.
...
...
Section 4.1 defines a textual representation of an OR Address, which
is used throughout the rest of this specification. This text
representation is designed to represent an X.400 ...
... is used throughout the rest of this specification. This text
representation is designed to represent an X.400 address in the LHS
(left hand side) or local part of an RFC 822std11(-> 2822prop) address ...
... address in the LHS
(left hand side) or local part of an RFC 822std11(-> 2822prop) address, and so this
representation gives a mechanism to represent X.400 addresses ...
... address, and so this
representation gives a mechanism to represent X.400 addresses within
RFC 822std11(-> 2822prop) addresses ...
... 822std11(-> 2822prop) name spaces, and defines the concept of a MIXER
Conformant Global Address Mapping (MCGAM). Gateways conforming to
this specification shall support MCGAMs.
...
...
An OR Address has a number of structured and unstructured attributes.
For each unstructured attribute, a key and an encoding is specified.
...
... MTS.PhysicalDeliveryOfficeNumber PD-OFFICE-NUM P/T 18.3.15 11
MTS.ExtensionORAddressComponents PD-EXT-ADDRESS P/T 18.3.4 12
MTS.PhysicalDeliveryPersonName PD-PN P/T 18.3.17 13
MTS ...
... AddressComponents PD-EXT-DELIVERY P/T 18.3.5 15
MTS.UnformattedPostalAddress PD-ADDRESS UPA 18.3.25 16
MTS.StreetAddress PD-STREET P/T 18.3.22 17
MTS ...
... .LocalPostalAttributes PD-LOCAL P/T 18.3.6 21
MTS.ExtendedNetworkAddress
.e163-4-address.number NET-NUM N 18.3.7 22
MTS.ExtendedNetworkAddress
.e163-4- ...
... .number NET-NUM N 18.3.7 22
MTS.ExtendedNetworkAddress
.e163-4-address.sub-address NET-SUB N 18.3.7 22
MTS.ExtendedNetworkAddress
...
... MTS.ExtendedNetworkAddress
.e163-4-address.sub-address NET-SUB N 18.3.7 22
MTS.ExtendedNetworkAddress
.psap- ...
... NET-SUB N 18.3.7 22
MTS.ExtendedNetworkAddress
.psap-address NET-PSAP X 18.3.7 22
MTS.TerminalType T-TY I 18.3.24 23
...
...
The EBNF for presentation-address is taken from the specification RFC
1278 "A String Encoding ...
...
The Unformatted Postal Address has a slightly more complex mapping
onto a variant of (teletex-and-or-ps), defined as:
...
...
/PD-ADDRESS=The Dome|The Square|Richmond|England/
...
... X.400 (1992) has introduced a string representation of OR Addresses
(see F.401, Annex B). This has specified a number of string keywords
for attributes. As earlier versions ...
... PD-OFFICE-NUM PD-OFFICE NUMBER
PD-OFFICE-NUM PD-OFN
PD-EXT-ADDRESS PD-EA
PD-EXT-DELIVERY PD-ED
...
... treated as ordered lines. If present, these will be assembled
with separating line feeds to form a single physical address. In
this case PD-ADDRESS (or PD-A) shall not be present. Similarly,
...
... physical address. In
this case PD-ADDRESS (or PD-A) shall not be present. Similarly,
there are ordered keywords for domain defined attributes: DD1,
...
... If ISDN is present, it may be interpreted as an E.163/164
address, using local heuristics to parse the string. X.400
...
... This is used to map from any string containing only printable string
characters to an OR address personal name. To map from a string to
OR Address ...
... address personal name. To map from a string to
OR Address components, parse the string according to the EBNF. The
given name and surname are assigned directly. All EBNF.initial
tokens ...
...
For an OR address which follows the above restrictions, a string is
derived in the natural manner. In this case, the mapping will be
reversible.
...
... Given this structure, we can specify an EBNF representation of an OR
Address. The output format of addresses is defined by EBNF.std-or-
address ...
... OR
Address. The output format of addresses is defined by EBNF.std-or-
address. The more flexible input format is defined by EBNF.std-or-
...
... Address. The output format of addresses is defined by EBNF.std-or-
address. The more flexible input format is defined by EBNF.std-or-
address-input. The input EBNF has been added subsequent to RFC 1327(-> 2156prop) ...
... address. The more flexible input format is defined by EBNF.std-or-
address-input. The input EBNF has been added subsequent to RFC 1327(-> 2156prop),
to reflect the formal incorporation of a number of heuristics ...
... to reflect the formal incorporation of a number of heuristics. The
address element separator on input may be "/", ";", or a mixture of
these. The output format is used in all examples.
...
...
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "RFC-822"
...
... / dd-key "." std-printablestring
std-or-address-input = [ sep pair ] sep pair *( sep pair )
sep [ pair sep ]
...
...
For address generation, the standard-type is any key defined in the
key table in Section 4.1, except PN, and DD. For address ...
... address generation, the standard-type is any key defined in the
key table in Section 4.1, except PN, and DD. For address parsing,
other key values from Section 4.1 are also valid ...
...
EBNF.std-or-address uses the characters "/" and "=" as delimiters.
Domain Defined Attributes and any value may contain these characters.
...
...
If an address of this syntax is parsed, and a country value is
present, but no ADMD, the string shall be interpreted as if an ADMD
value of single space had been specified.
...
... Global Address Mapping ...
...
From a user perspective, the ideal mapping would be entirely
symmetrical and global, to enable addresses to be referred to
transparently in the remote system, with the choice of gateway ...
... In order to achieve a symmetrical mapping there is a need to define
an administrative equivalence between parts of the OR Address and
Domain namespaces ...
... MIXER defines the concept
of a MIXER Conformant Global Address Mapping (MCGAM). This acronym
is defined so that it is very clear what is being referenced.
...
...
The X.400 and Internet Mail address spaces are hierarchical. It is
possible to define an equivalence between two points in the
hierarchies, such that addresses ...
... Internet Mail address spaces are hierarchical. It is
possible to define an equivalence between two points in the
hierarchies, such that addresses below that point can be derived in
an algorithmic manner. An MCGAM is a mapping from a point in one
hierarchy to a point in the other hierarchy. An "MGGAM pair" is a
...
... 2. The authority defining the MCGAM is responsible to ensure
that addresses allocated below the two equivalence points
conform to the rules set out below.
...
... 3. The authority defining the MCGAM is responsible to ensure
that addresses which are generated according to the MCGAM
are routed correctly.
...
...
The following OR Address attributes are considered as a hierarchy,
and may be specified by the domain. They are (in order of the
...
... other ways. In particular, it covers the Mnemonic OR Address using a
1984 compatible encoding. This is seen as the dominant form of OR ...
... encoding. This is seen as the dominant form of OR
Address. MCGAMs may only be used when this hierarchy applies.
...
...
Where the mapping relates to an envelope address, the gateway shall
non-deliver messages according to the associated MTA ...
... non-deliver messages according to the associated MTA's normal timeout
policy. Where the mapping relates to addresses in the message
header, there shall be a timeout in the range of 1-4 hours or shorter
...
... quality of service constraints. If
a mapping cannot be done in this time, address encapsulation shall be
used.
...
...
This section defines the basic address mapping.
...
...
This section defines how X.400 addresses are represented in RFC 822std11(-> 2822prop)
addresses ...
... The std-or-address syntax is used to encode OR Address information
in the 822.local-part of EBNF.822-address. Where there is an
...
... OR Address information
in the 822.local-part of EBNF.822-address. Where there is an
applicable equivalence mapping, further OR Address information ...
... address. Where there is an
applicable equivalence mapping, further OR Address information is
associated with the 822.domain component. This cannot be used in the
...
... X.400 OR Addresses which use different attribute types. The only way
to encode the full PrintableString character set in a domain ...
...
A generic 822.address consists of a 822.local-part and a sequence of
822.domains (e.g., <@domain1,@domain2:user@domain3>). All except the
...
... domain may be
used to determine some number of OR Address attributes, where this
does not conflict with the first role. RFC 822std11(-> 2822prop) ...
... In the case that there is no applicable equivalence mapping, all of
the X.400 address is encoded in the 822.local-part and the 822.domain
identifies the gateway ...
... technique may be used by the RFC 822std11(-> 2822prop) user for any X.400 address where
the equivalence mapping is not known.
...
... attributes are encoded in the 822.domain. The remaining attributes
are encoded on the LHS, using the EBNF.std-or-address syntax. For
example:
...
...
Given the OR address, the domain Widget.COM is determined from the
equivalence mapping and the next component is determined
...
... EBNF.encoded-pn. In the previous example, if the GenerationQualifier
was not present in the OR Address, it would map with the RFC 822std11(-> 2822prop)
address ...
... Address, it would map with the RFC 822std11(-> 2822prop)
address: J.Linnimouth@Marketing.Widget.COM.
...
... appropriate gateways for the corresponding OR Address space. It is
the responsibility of the management that defines the equivalence
...
... domain
defined attribute, and an OR Address can have a maxmimum of four
domain defined attributes. Where the printable string generated from
...
... domain defined attributes. Where the printable string generated from
the RFC 822std11(-> 2822prop) 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 RFC 822std11(-> 2822prop) addresses in printable
string domain defined attributes. Teletex domain ...
...
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 ...
...
1. The text encoding (std-or-address) of MTS.ORAddress as used
in the local-part of an RFC 822std11(-> 2822prop) ...
... MTS.ORAddress as used
in the local-part of an RFC 822std11(-> 2822prop) address. An order is needed
for those components which may have multiple values
(Organizational Unit, and Domain ...
... (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 ...
... - Alignment to the hierarchy of other components in RFC
822std11(-> 2822prop) addresses (thus, Organizational Units will appear
in the same order, whether encoded on the RHS or LHS).
...
...
- To ensure that gateways generate consistent addresses.
This is both to help end users, and to generate
identical message ids ...
...
1. X.400 addresses encoded in RFC 822std11(-> 2822prop). This will also include
RFC 822std11(-> 2822prop) ...
... 822std11(-> 2822prop). This will also include
RFC 822std11(-> 2822prop) addresses which are given reversible encodings.
...
...
2. "Genuine" RFC 822std11(-> 2822prop) addresses.
The mapping shall proceed as follows, by first assuming case 1).
...
... 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 RFC 822std11(-> 2822prop), 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 ...
...
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
...
... set of attributes forms a valid X.400 address,
according to X.402, then go to step 9. All forms of X.400
...
... 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 ...
... address are allowed at this stage. Steps 7-8 default
attributes for certain types of OR Address.
7. If the set of attributes ...
... 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
...
...
This will only be reached if the RFC 822std11(-> 2822prop) EBNF.822-address is not a
valid X.400 ...
... valid X.400 encoding. This implies that the address refers to a
recipient on an RFC 822std11(-> 2822prop) system or that the encoding ...
... recipient on an RFC 822std11(-> 2822prop) system or that the encoding of the address is
invalid. Such addresses shall be encoded in an X.400 ...
... domain defined attribute.
1. Convert the EBNF.822-address to PrintableString, as
specified in Chapter 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 ...
... If Stage I, step 8 does not generate a set of attributes or
the address generated is unroutable, the remained of the OR
address ...
... address generated is unroutable, the remained of the OR
address is generated as follows. The remainder of the OR address
...
... address is generated as follows. The remainder of the OR address
effectively identifies a source route to a gateway ...
...
SMTP Return Address
This shall be set up so that errors are returned through the
same gateway ...
...
IPMS Addresses
These are optimised for replying. In general, the message
may end up anywhere within the X.400 ...
... gateway appropriate for the RFC
822std11(-> 2822prop) address being converted. The 822.domain to which the
address ...
... address being converted. The 822.domain to which the
address would be routed is used to select an appropriate
gateway.
...
... non-local gateway,
which will optimise the reply address. This information
may be looked up in gateway tables in a manner equivalent to
...
... X.400 routing. The OR address shall then be generated in
the same manner as for an IPMS address ...
... 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 ...
... important, as the use of this mapping will lead to a remote
X.400 address, which can be routed by X.400 routing
...
... Three examples are given, neither of which has applicable MCGAMs.
Example 1: (Address not in "localpart" "@" "domainpart")
@relay.co.uk:userb@host2
...
... 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
...
... 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
...
... 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)
...
...
The following heuristic, which relates to ordering of address
components, may be used when mapping from RFC 822std11(-> 2822prop) to X.400 ...
... gateway shall first
map according to the order defined in 4.3.3. If this mapping
generates an address which X.400 address verification ...
... invalid, this heuristic may be applied as an alternative to
immediate rejection of the address.
...
...
2. "Genuine" X.400 addresses. This may include symmetrically
encoded RFC 822std11(-> 2822prop) addresses ...
... addresses. This may include symmetrically
encoded RFC 822std11(-> 2822prop) addresses.
When an MTS ...
... When an MTS Recipient OR Address is interpreted, gatewaying will be
selected if there is a single "RFC-822" domain defined attribute
...
...
This is used for X.400 addresses which do not use the explicit RFC
822std11(-> 2822prop) encoding ...
... 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.
...
... 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 ...
... 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
...
... domain, and an OR
address prefix. Follow the hierarchy: C, ADMD, PRMD, O, OU.
For each successive component below the OR address prefix ...
... 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
...
... 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 ...
... 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.
...
... on the LHS.
5. If the address contains any attribute not used in mnemonic
form, then all of the attributes in the address ...
... 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.
...
... 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 ...
... 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
...
... /S=Support/o=sales/@Master400.it
Example 2: (Address with illegal characters in RFC 822std11(-> 2822prop) generated
domain ...
... "/S=renseignements/o=Region Parisienne/"@autoroutes.fr
Example 3: (Address containing elements not mappable into RFC 822std11(-> 2822prop)
...
... DD.city=Milano/S=Rossi/"@ptpostel.it
Example 4: (Address with an entry for A=ATT; C=us; into the domain
of Preferred Gateway ...
...
This is mapped first to an RFC 822std11(-> 2822prop) address, and then back to the
X.400 address ...
... X.400 OR
Addresses in correct format (rather than doubly encoded). In cases
(X.400 or RFC 822std11(-> 2822prop) ...
... OR Name, along with OR
Address. The RFC 822std11(-> 2822prop) addresses are mapped onto the OR ...
... 822std11(-> 2822prop) addresses are mapped onto the OR Address
component. As there is no functional mapping for the Directory Name
on the RFC 822std11(-> 2822prop) ...
... Use the basic ORAddress mapping, to generate the SMTP originator
(return address) from MTS.OtherMessageDeliveryFields.originator-name
(MTS ...
... only one RFC 822std11(-> 2822prop) recipient, as the "X400-Recipients" field is only
given one address.
...
... may be delivered to different RFC 822std11(-> 2822prop) recipients, and so several
addresses in the "X400-Recipients:" field may have such comments.
The non-commented recipient is the RFC 822std11(-> 2822prop) recipient. The EBNF of the
...
...
All RFC 822std11(-> 2822prop) addresses are assumed to use the 822.mailbox syntax.
This includes all 822.comments associated with the lexical tokens ...
... 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.
...
... Mapping from IPMS.ORDescriptor to RFC 822std11(-> 2822prop) address. In the basic
case, where IPMS.ORDescriptor.formal-name is present, proceed as
...
... 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 ...
... encoding of 822.mailbox. If EBNF.822-address is parsed as
822.route 822.addr-spec, then an 822.phrase taken from
...
... 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
...
... 6. If IPMS.RecipientSpecifier.reply-request is True, an
822.comment "(Reply requested)" is appended to the address.
If IPMS ...
... 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 issue about being able to reply to message IDs.
(For addresses, creating a return path which works is more
important than being symmetrical).
...
... IPMS.IPMIdentifier.
id-loc ::= [ printablestring ] "*" [ std-or-address ]
EBNF.printablestring is the IPMS ...
... IPMS.IPMIdentifier.user-relative-
identifier, and EBNF.std-or-address being an encoding of the
IPMS ...
... If the 822.local-part can be parsed as:
[ printablestring ] "*" [ std-or-address ]
and the 822.domain ...
... IPMS.IPMIdentifier.user-relative-identifier. If EBNF.std-or-address
is present, the OR Address ...
... address
is present, the OR Address components derived from it are used to set
IPMS.IPMIdentifier.user.
...
... X.400 generated. Use the
IPMS.IPMIdentifier.user to generate an EBNF.std-or-address form
string. Build the 822.local-part of the 822.msg-id with the syntax:
...
... string. Build the 822.local-part of the 822.msg-id with the syntax:
[ printablestring ] "*" [ std-or-address ]
The printablestring is taken from IPMS ...
... the 822.local-part can be parsed as
[ printablestring ] "*" [ std-or-address ]
then it is RFC 987(-> 2156prop | 1327(-> 2156prop)) ...
... more problems for some fields than others (e.g., truncating an OR
Address component that would be used to route a reply would be a more
severe problem than truncating a Free Form Name). If the Free Form
...
... IPMS.Heading.originator. For this, and other components
containing addresses, the mappings of Chapter 4 are used for
each address.
...
... allowed because some X.400 systems cannot handle a zero lenght
sequence of addresses.
In-Reply-To ...
... Address Status 1/None
X.1.1 Bad mailbox address 1/0 Unrecognized
X.1.2 Bad system address 1/0 Unrecognized
...
... mailbox address 1/0 Unrecognized
X.1.2 Bad system address 1/0 Unrecognized
X.1.3 Bad mailbox address syntax ...
... address 1/0 Unrecognized
X.1.3 Bad mailbox address syntax 1/0 Unrecognized
X.1.4 Mailbox address ...
... address syntax 1/0 Unrecognized
X.1.4 Mailbox address ambiguous 1/1
X.1.5 Only used for positive reports, not applicable
X.1.6 Destination ...
... X.1.7 Bad sender's mailbox address syntax 1/11 Invalid arguments
X.1.8 Bad sender's system address ...
... address syntax 1/11 Invalid arguments
X.1.8 Bad sender's system address 1/11 Invalid arguments
X.2.0 Other or undefined mailbox ...
...
global-id = std-or-address
...
...
This is encoded using the std-or-address syntax, for the attributes
within the Global Domain Identifier.
...
... 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
...
... 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 ...
... To: Set to the recipient from MTS.MessageSubmissionEnvelope.
If there have been redirects, the original address shall be used.
Subject ...
... Priority" ":" priority
/ "Originator-Return-Address" ":" 1#mailbox
/ "DL-Expansion-History" ":" mailbox ...
... Mapped to a comment, as described in Section 4.6.2.2.
originator-return-address
Mapped to the extended RFC 822std11(-> 2822prop) field "Originator-Return-Address ...
... address
Mapped to the extended RFC 822std11(-> 2822prop) field "Originator-Return-Address:".
physical ...
... 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 indicate the addresses in the reports. If the report is
for a single address, EBNF.mailbox is used to give the RFC 822std11(-> 2822prop)
...
... mailbox is used to give the RFC 822std11(-> 2822prop)
representation of the address. If all of the reported recpients
reference the same MTA this is included in EBNF.word. The MTA ...
... / "X400-Redirection-History" ":" redirect-history-item
/ "X400-Physical-Forwarding-Address" ":" mailbox
/ "X400-Originally-Specified-Recipient-Number" ":"
...
... 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 822std11(-> 2822prop) ...
... DSN.original-recipient-field fields, with DSN.address-type of
"rfc822", and with an RFC 822std11(-> 2822prop) mailbox ...
... "rfc822", and with an RFC 822std11(->