mta-field = "X400-Received" ":" x400-trace
/ "Deferred-Delivery" ":" date-time
/ "Latest-Delivery-Time" ":" date-time
x400-trace = "by" md-and-mta ";"
[ "deferred until" date-time ";" ]
[ "converted" "(" encoded-info ")" ";" ]
[ "attempted" md-or-mta ";" ]
action-list
";" arrival-time
md-and-mta = [ "mta" mta "in" ] global-id
mta = word
arrival-time = date-time
md-or-mta = "MD" global-id
/ "MTA" mta
Action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
dr-user-info = dr-summary <CRLF>
dr-recipients <CRLF>
dr-content-return
dr-content-return = "The Original Message is not available"
/ "The Original Message follows:"
dr-summary = "This report relates to your message:" <CRLF>
content-correlator <CRLF> <CRLF>
"of" date-time <CRLF> <CRLF>
dr-recipients = *(dr-recipient <CRLF> <CRLF>)
dr-recipient = dr-recip-success / dr-recip-failure
dr-recip-success =
"Your message was successfully delivered to:"
mailbox "at" date-time
dr-recip-failure = "Your message was not delivered to:"
mailbox <CRLF>
"for the following reason:" *word
report-point = [ "mta" mta-name "in" ] global-id
content-correlator = *word
mta-name = word
dr-per-message-fields =
/ "X400-Conversion-Date" ":" date-time
/ "X400-Subject-Submision-Identifier" ":"
mts-msg-id
/ "X400-Content-Identifier" ":" printablestring
/ "X400-Content-Type" ":" mts-content-type
/ "X400-Original-Encoded-Information-Types" ":"
encoded-info
/ "X400-Originator-and-DL-Expansion-History" ":"
mailbox ";" date-time ";"
/ "X400-Reporting-DL-Name" ":" mailbox
/ "X400-Content-Correlator" ":" content-correlator
/ "X400-Recipient-Info" ":" recipient-info
/ "X400-Subject-Intermediate-Trace-Information" ":"
x400-trace
/ dr-extensions
dr-per-recipient-fields =
/ "X400-Redirect-Recipient" ":" "x400" ";" std-or
/ "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";"
mailbox
/ "X400-Converted-EITs" ":" encoded-info ";"
/ "X400-Delivery-Time" ":" date-time
/ "X400-Type-of-MTS-User" ":" labelled-integer
/ "X400-Last-Trace" ":" [ encoded-info ] date-time
/ "X400-Supplementary-Info" ":"
<"> printablestring <"> ";"
/ "X400-Redirection-History" ":" redirect-history-item
/ "X400-Physical-Forwarding-Address" ":" mailbox
/ "X400-Originally-Specified-Recipient-Number" ":"
integer
/ dr-extensions
dr-extensions = "X400-Discarded-DR-Extensions" ":"
1# (object-identifier / labelled-integer)
dr-diagnostic = "Reason" labelled-integer-2
[ ";" "Diagnostic" labelled-integer-2 ]
mts-field = "X400-MTS-Identifier" ":" mts-msg-id
/ "X400-Originator" ":" mailbox
/ "X400-Recipients" ":" 1#mailbox
/ "Original-Encoded-Information-Types" ":"
encoded-info
/ "X400-Content-Type" ":" mts-content-type
/ "X400-Content-Identifier" ":" printablestring
/ "Priority" ":" priority
/ "Originator-Return-Address" ":" 1#mailbox
/ "DL-Expansion-History" ":" mailbox ";" date-time ";"
/ "Conversion" ":" prohibition
/ "Conversion-With-Loss" ":" prohibition
/ "Delivery-Date" ":" date-time
/ "Discarded-X400-MTS-Extensions" ":"
1#( object-identifier / labelled-integer )
prohibition = "Prohibited" / "Allowed"
mts-msg-id = "[" global-id ";" *text "]"
mts-content-type = "P2" / labelled-integer
/ object-identifier
priority = "normal" / "non-urgent" / "urgent"
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
[ ipn-content-return ]
ipn-description = ipn-receipt / ipn-non-receipt
ipn-receipt = "Your message to:" preferred-recipient <CRLF>
"was received at" receipt-time <CRLF> <CRLF>
"This notification was generated"
acknowledgement-mode <CRLF>
"The following extra information was given:" <CRLF>
ipn-suppl <CRLF>
ipn-non-receipt = "Your message to:"
preferred-recipient <CRLF>
ipn-reason
ipn-reason = ipn-discarded / ipn-auto-forwarded
ipn-discarded = "was discarded for the following reason:"
discard-reason <CRLF>
ipn-auto-forwarded = "was automatically forwarded." <CRLF>
[ "The following comment was made:"
auto-comment ]
ipn-extra-information =
"The following information types were converted:"
encoded-info
ipn-content-return = "The Original Message is not available"
/ "The Original Message follows:"
preferred-recipient = mailbox
receipt-time = date-time
auto-comment = printablestring
ipn-suppl = printablestring
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated" / "IPM Deleted"
acknowledgement-mode = "Manually" / "Automatically"
ipms-field = "Supersedes" ":" 1*msg-id
/ "Expires" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Content-Language" ":" 1#language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":"
1#object-identifier
/ "Autosubmitted" ":" autosubmitted
importance = "low" / "normal" / "high"
sensitivity = "Personal" / "Private" /
"Company-Confidential"
language = 2*ALPHA [ "(" language-description ")" ]
language-description = printable-string
message-type = "Delivery Report"
/ "InterPersonal Notification"
/ "Multiple Part"
autosubmitted = "not-auto-submitted"
/ "auto-generated"
/ "auto-replied"
/ "auto-forwarded"
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"
subject-line = "Delivery-Report" "(" status ")"
[ "for" destination ]
status = "success" / "failure" / "success and failures"
destination = mailbox / "MTA" word
extended-heading =
"Prevent-NonDelivery-Report" ":"
/ "Generate-Delivery-Report" ":"
/ "Alternate-Recipient" ":" prohibition
/ "Disclose-Recipients" ":" prohibition
/ "X400-Content-Return" ":" prohibition
Appendix F - Text format for MCGAM distribution
1. Text Formats
This appendix defines text formats for exchange of four types of
mapping.
1. Domain Name Space -> OR Address Space MCGAM
2. OR Address Space -> Domain Name Space MCGAM
3. Domain Name Space -> OR Address of preferred gateway
4. OR Address Space -> Domain Name of preferred gateway
2. Mechanisms to register and to distribute MCGAMs
There is a well known set of MCGAM tables.
The global coordination of the mapping rules is a part of the DANTE
MailFLOW Project. New mapping rules may be defined by the authority
responsible for the relevant name space. The rules need to be
registered with a national mapping registration authority, which in
turn passes them on to the central mapping registration authority.
All the collected mapping rules are merged together into the globally
coordinated mapping tables by the MailFLOW Project Team. The tables
are available from the national mapping registration authorities.
To get a contact address of the mapping registration authority for
the respective country or more information about the MailFLOW Project
contact:
SWITCH
MailFLOW Project Team
Limmatquai 138
8001 Zuerich
Switzerland
email: mailflow@mailflow.dante.net
S=MailFLOW;O=MailFLOW;P=DANTE;A=mailnet;C=fi;
fax: +41 1 268 15 68
tel: +41 1 268 15 20
3. Syntax Definitions
An address syntax is defined, which is compatible with the syntax
used for 822.domains. By representing the OR addresses as domains,
all lookups can be mechanically implemented as domain -> domain
mappings. This syntax defined is initially for use in table format,
but the syntax is defined in a manner which makes it suitable to be
adapted for use with the Domain Name Service. This syntax allows
for a general representation of OR addresses, so that it can be used
in other applications. Not all attributes are used in the table
formats defined.
To allow the mapping where a level of the hierarchy is omitted, the
pseudo-value "@" (not a printable string character) is used to
indicate omission of a level in the hierarchy. This is distinct from
the form including the element with no value, although a correct
X.400 implementation will interpret both in the same manner.
This syntax is not intended to be handled by users.
dmn-or-address = dmn-part *( "." dmn-part )
mn-part = dmn-attribute "$" value
dmn-attribute = standard-type
/ "~" dmn-printablestring
value = dmn-printablestring
/ "@"
dmn-printablestring =
= *( dmn-char / dmn-pair )
dmn-char = <"{", "}", "*", and any ps-char
except ".">
dmn-pair = "\."
An example usage:
~ROLE$Big\.Chief.ADMD$ATT.C$US
PRMD$DEC.ADMD$@.C$US
The first example illustrates quoting of a "." and a domain define
attribute (ROLE). The second example illustrates omission of the
ADMD level. There shall be a strict ordering of all components in
this table, with the most significant components on the RHS. This
allows the encoding to be treated as a domain.
Various further restrictions are placed on the usage of dmn-or-
address in the address space mapping tables.
a. Only C, ADMD, PRMD, O, and up to four OUs may be used.
b. No components shall be omitted from this hierarchy, although
the hierarchy may terminate at any level. If the mapping is
to an omitted component, the "@" syntax is used.
4. Table Lookups
When determining a match, there are aspects which apply to all
lookups. Matches are always case independent. The key for all three
tables is a domain. The longest possible match shall be obtained.
Suppose the table has two entries with the following keys:
K.L
J.K.L
Domain "A.B.C" will not return any matches. Domain "I.J.K.L"
will match the entry "J.K.L:.
5. Domain -> OR Address MCGAM format
The BNF is:
domain-syntax "#" dmn-or-address "#"
EBNF.domain-syntax is defined in Section 4.2. Note that the trailing
"#" is used for clarity, as the dmn-or-address syntax might lead to
values with trailing blanks. Lines starting with "#" are comments.
For example:
AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB#
XEROX.COM#O$Xerox.ADMD$ATT.C$US#
GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE#
A domain is looked up to determine the top levels of an OR Address.
Components of the domain which are not matched are used to build the
remainder of the OR address, as described in Section 4.3.4.
6. OR Address -> Domain MCGAM format
The syntax of this table is:
dmn-or-address "#" domain-syntax "#"
For example:
#
# Mapping table
#
PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK#
The OR Address is used to generate a domain key. It is important to
order the components correctly, and to fill in missing components in
the hierarchy. Use of this mapping is described in Section 4.3.2.
7. Domain -> OR Address of Preferred Gateway table
This uses the same format as the domain -> OR address MCGAM table.
In this case, the restriction to only use C/ADMD/PRMD/O/OU does not
apply. Use of this mapping is described in Section 4.3.4. A domain
cannot appear in this table and in the domain to OR Address table.
8. OR Addresss -> domain of Preferred Gateway table
This uses the same format as the OR Address -> domain MCGAM table.
Use of this mapping is described in Section 4.3.5. An OR Address
cannot appear in this table and in the OR Address to domain table.
Appendix G - Conformance
This appendix defines a number of options, which a conforming gateway
shall specify. Conformance to this specification shall not be
claimed if any of the mandatory features are not implemented. A
specification of conformance may list the service elements of Chapter
2, in order to be clear that full conformance is provied. In
particular:
- Formats for all fields shall be followed.
- The gateway shall enable MCGAMs to be used.
- Formats for subject lines, delivery reports and IPNs shall
be followed. A system which followed the syntax, but
translated text into a language other than english would be
conformant.
- RFC1137 shall not be followed when mapping to SMTP.
- All mappings of trace shall be implemented.
- There shall be a mechanism to access all three global
mappings.
- RFC2157 shall be followed for mapping body parts.
- When it is specified that a MIME format message is
generated, RFC2045 shall be followed.
A gateway shall specify:
- Which Interent Message Transport (822-MTS) protocols are
supported. If SMTP is supported, Appendex A of MIXER shall
be used.
- Which X.400 versions are supported (84, 88, 92).
- Which mechanisms (table, X.500, DNS) are supported to access
MCGAMs.
- The mechanism or mechanisms by which the global mapping
information is accessed.
The following are optional parts of this specification. A conforming
implementation shall specify which of these it supports.
- Support for the extension mappings of Appendix C.
- Support for returning illegal format content in a delivery
report
- Which address interpretation heuristics are supported
(4.3.4.1)
- If RFC987 generated message ids are handled in a backwards
compatible manner (4.7.3.6)
Appendix H - Change History: RFC987, 1026, 1138, 1148
RFC987 was the original document, and contained the key elements of
this specification. It was specific to X.400(1984). RFC1026
specified a small number of necessary changes to RFC987.
RFC1138 was based on the RFC987 work. It contained an editorial
error, and was reissued a few months later as RFC1148. RFC1148
will be referred to here, as it is the document which is widely
referred to elsewhere. The major goal of RFC1148 was to upgrade RFC
987 to X.400(1988). It did this, but did not obsolete RFC987, which
was recommended for use with X.400(1984). This appendix summarises
the changes made in going from RFC987 to RFC1148.
RFC1148 noted the following about its upgrade from RFC987:
Unnecessary change is usually a bad idea. Changes on the RFC822
side are avoided as far as possible, so that RFC822 users do not
see arbitrary differences between systems conforming to this
specification, and those following RFC987. Changes on the X.400
side are minimised, but are more acceptable, due to the mapping onto
a new set of services and protocols.
1. Introduction
The model has shifted from a protocol based mapping to a service
based mapping. This has increased the generality of the
specification, and improved the model. This change affects the
entire document.
A restriction on scope has been added.
2. Service Elements
- The new service elements of X.400 are dealt with.
- A clear distinction is made between origination and
reception
3. Basic Mappings
- Add teletex support
- Add object identifier support
- Add labelled integer support
- Make PrintableString <-> ASCII mapping reversible
- The printable string mapping is aligned to the NBS mapping
derived from RFC987.
4. Addressing
- Support for new addressing attributes
- The message ID mapping is changed to not be table driven
5. Detailed Mappings
- Define extended IPM Header, and use instead of second body
part for RFC822 extensions
- Realignment of element names
- New syntax for reports, simplifying the header and
introducing a mandatory body format (the RFC987 header
format was unusable)
- Drop complex autoforwarded mapping
- Add full mapping for IP Notifications, defining a body
format
- Adopt an MTS Identifier syntax in line with the OR Address
syntax
- A new format for X400 Trace representation on the RFC822
side
6. Appendices
- Move Appendix on restricted 822 mappings to a separate RFC
- Delete Phonenet and SMTP Appendixes
Appendix I - Change History: RFC1148 to RFC1327
1. General
- The scope of the document was changed to cover X.400(1984),
and so obsolete RFC987.
- Changes were made to allow usage to connect RFC822 networks
using X.400
- Text was tightened to be clear about optional and mandatory
aspects
- A good deal of clarification
- A number of minor EBNF errors
- Better examples are given
- Further X.400 upper bounds are handled correctly
2. Basic Mappings
- The encoding of object identifier is changed slightly
3. Addressing
- A global mapping of domain to preferred gateway is
introduced.
- An overflow mechanism is defined for RFC822 addresses of
greater than 128 bytes
- Changes were made to improve compatibility with the PDAM on
writing OR Addresses.
+ The PD and Terminal Type keywords were aligned to the
PDAM. It is believed that minimal use has been made of
the RFC1148 keywords.
+ P and A are allowed as alternate keys for PRMD and ADMD
+ Where keywords are different, the PDAM keywords are
alternatives on input. This is mandatory.
4. Detailed Mappings
- The format of the Subject: lines is defined.
- Illegal use (repetition) of the heading EXTENSION is
corrected, and a new object identifier assigned.
- The Delivery Report format is extensively revised in light
of operational experience.
- The handling of redirects is significantly changed, as the
previous mechanism did not work.
5. Appendices
- An SMTP appendix is added, allowing optional use of the VRFY
command to improve probe information.
- Handling of JNT Mail Acknowledge-To is changed slightly.
- A DDA JNT-MAIL is allowed on input.
- The format definitions of Appendix F are explained further,
and a third table definition added.
- An appendix on use with X.400(1984) is added.
- Optional extensions are defined to give RFC822 access to
further X.400 facilities.
- An appendix on conformance is added.
Appendix J - Change History: RFC1327 to this Document
1. General
This update is primarily for stability, and to fold in compatibility
for MIME and to add support for the new NOTARY delivery status
notifications. Other general changes:
- Various editorial updates
- Minor EBNF errors
- Reference to mapping table support by DNS and X.500.
- Alignment to X.400(92)
- Assignment of a new object identifier
- Removal of specification relating to body mapping, which is
now defined in RFC2157.
2. Service Elements
- Support of Auto-Submitted service
3. Basic Mappings
- Comments shall not be used in new headers, to remove parsing
ambiguity
- RFC1522 encoding may be used as an alternative to X.408
downgrade, where appropriate.
- Correct handling of RFC822 four year dates.
4. Addressing
- Replaced the mandatory global address mapping with MCGAMs.
- Add codes and add a heuristic to align to the standard X.400
form of writing OR Addresses.
- Improved text on ordering heuristic
- Leading "/" interpretation added
- All bar one of the address mapping heuristics made
mandatory.
- Interpretation of domain defined attribute "RFC-822" made
mandatory in all cases
- Make report request comments optional
5. Detailed Mappings
- Comments no longer maps to separate body part
- Allow Languages to be multi-valued
- Change Content-Identifier to X400-Content-Identifier, in
order to avoid confusion with MIME.
- Reverse mapping of MIXER defined fields made mandatory
- "Expiry-Date:" changed to "Expires:".
- "Obsoletes:" changed to "Supersedes:".
- Define correct handling when "Resent-Date:" is present.
6. Appendices
- Change "Content-Return" to "X400-Content-Return" in Appendix
C.
- Relaxation of restrictions on mapping 3 in Appendix F.
- Add linkage to HARPOON in Appendix B.
- RFC2157 added to the conformance statement of Appendix
G.
- Added Appendix L, with ASN. Summary.
Appendix L - ASN.1 Summary
MIXER Definitions { iso org(3) dod(6) internet(1) mail(7)
mixer(1) mixer-core(3) definitions(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- exports everything
IMPORTS
EXTENSION FROM
MTSAbstractService {join-iso-ccit mhs-motis(6) mts(3)
modules(0) mts-abstract-service(1) }
HEADING-EXTENSION FROM
IPMSAbstractService {join-iso-ccit mhs-motis(6) ipms(1)
modules(0) abstract-service(3) }
rfc-822-field HEADING-EXTENSION
VALUE RFC822FieldList
::= id-rfc-822-field-list
RFC822FieldList ::= SEQUENCE OF RFC822Field
RFC822Field ::= IA5String
dsn-header-list EXTENSION
RFC822FieldList
::= id-dsn-header-list
dsn-field-list EXTENSION
RFC822FieldList
::= id-dsn-field-list
internet ::= OBJECT IDENTIFIER { iso org(3) dod(6) 1 } -- from RFC
1155
mail OBJECT IDENTIFIER ::= { internet 7 } -- IANA assigned
mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC
1495
mixer-core OBJECT IDENTIFIER ::= { mixer core(3) }
id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2}
id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3}
id-dsn-field-list OBJECT IDENTIFIER ::= {mixer-core 4}
eit-mixer OBJECT IDENTIFIER ::= {mixer-core 5}
-- the MIXER pseudo-EIT
END -- MIXER ASN.1
SECURITY CONSIDERATIONS
Security issues are not discussed in this memo.
AUTHOR'S ADDRESS
Steve Kille
Isode Ltd
The Dome
The Square
Richmond
TW9 1DT
England
Phone: +44-181-332-9091
Internet EMail: S.Kille@ISODE.COM
X.400 Email: I=S; S=Kille; P=Isode; A=Mailnet; C=FI;
UFN: S.Kille, Isode, GB
References
1. CCITT , "Recommendations X.400", Message Handling Systems:
System Model - Service Elements, October 1984.
2. Allocchio, C., "MaXIM11 - Mapping between X.400 / Internet
Mail and Mail-11 mail", RFC2162, January 1998.
3. Allocchio, C., "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)", RFC2163,
January 1998.
4. Alvestrand, H., Kille, S., Miles, R., Rose, M., and S.
Thompson, "Mapping between X.400 and RFC-822 Message
Bodies", RFC1495, August 1993.
5. Alvestrand, H., Romaguera, J., and K. Jordan, "Rules for
Downgrading Messages for X.400(88) to X.400(84) When MIME
Content-Types are Present in the Messages (Harpoon)", RFC
1496, August 1993.
6. Alvestrand, H., and S. Thompson, "Equivalences between X.400
and RFC-822 Message Bodies", RFC1494, August 1993.
7. Alvestrand, H., "Tags for the Identification of Languages",
RFC1766, March 1995.
8. Alvestrand, H., "Mapping between X.400 and RFC-822/MIME
Message Bodies", RFC2157, January 1998.
9. Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC2045, November 1996.
10. Braden, R., "Requirements for Internet Hosts -- Application
and Support", STD 3, RFC1123, October 1989.
11. CCITT/ISO, "CCITT Recommendations X.420/ ISO/IEC 10021-7,"
Message Handling Systems: Interpersonal Messaging System,
Dec 1988.
12. CCITT/ISO, "CCITT Recommendations X.411/ ISO/IEC 10021-4,"
Message Handling Systems: Message Transfer System: Abstract
Service Definition and Procedures, Dec 1988.
13. CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,"
Message Handling: System and Service Overview , Dec 1988.
14. CCITT/ISO, "Specification of Abstract Syntax Notation One
(ASN.1)," CCITT Recommendation X.208 / ISO/IEC 8824, Dec
1988.
15. CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,"
Message Handling: System and Service Overview , Dec 1992.
16. Crocker, D., "Standard of the Format of ARPA Internet Text
Messages", STD 11, RFC822, August 1982.
17. Kille, S., "Mapping Between X.400 and RFC822", UK Academic
Community Report (MG.19) / RFC987, June 1986.
18. Kille, S., "Addendum to RFC987", UK Academic Community
Report (MG.23) / RFC1026, August 1987.
19. Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822", RFC1138, October 1989.
20. Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822", RFC1148, March 1990.
21. Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822", RFC1327, May 1992.
22. Kille, S., "X.400 1988 to 1984 downgrading", RFC1328, May
1992.
23. Kille, S., "A String Encoding of Presentation Address", RFC
1278, November 1992.
24. Kille, S., "A String Representation of Distinguished Name",
RFC1485, January 1992.
25. Kille, S., "Using the OSI Directory to achieve User
Friendly Naming", RFC1484, January 1992.
26. Kille, S., "Use of an X.500/LDAP directory to support MIXER
address mapping", RFC2164, January 1998.
27. Koorland, N., "Message Attachmment Work Group (MAWG): MAWG
Feasibility Project Guide," EMA Report, Version 1.5, Nov
1995.
28. Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC1894, January 1996.
29. Moore, K., "SMTP Service Extensions for Delivery Status
Notifications", RFC1891, Januaty 1996.
30. Postel, J., "SIMPLE MAIL TRANSFER PROTOCOL", STD 10, RFC821,
August 1982.
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.