One document matched: draft-ietf-mailext-mail-attributes-03.txt
Differences from draft-ietf-mailext-mail-attributes-02.txt
Common Internet Message Attributes
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This'
memo does not specify an Internet standard of any kind, since
this document is mainly a compilation of information taken from
other RFC-s.. Distribution of this memo is unlimited.
Abstract
This memo contains a table of commonly occurring attributes in
headings and on envelopes of e-mail messages. The document compiles
information from other RFC-s such as RFC 821, RFC 822, RFC 1036,
RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766 and RFC 1806. A few
commonly occurring attributes which are not defined in RFC-s are
also included. For each attribute, the memo gives a short
description and a reference to the RFC, in which the attribute
is defined. The postscript version of this memo shows the changes
as compared to version 02.
Palme [Page 1]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Table of contents
1. Introduction
2. Use of gatewaying attributes
3. Table of attributes
3.1 Phrases used in the tables
3.2 Addressing information
3.3 Envelope and format information
3.4 Sender and recipient indication
3.5 Response control
3.6 Message identification and referral attributes
3.7 Other textual attributes
3.8 Attributes containing dates and times
3.9 Quality information
3.10 Language information
3.11 Size information
3.13 Encoding information
3.14 Resent-attributes
3.15 Miscellaneous
4. Acknowledgments
5. References
6. Author's address
Appendix A: Attributes sorted by Internet RFC document in which
they appear
Appendix B: Alphabetical index
Palme [Page 2]
draft-ietf-mailext-mail-attributes-03.txt November 1995
1. Introduction
Many different Internet standards and RFC-s define attributes which
may occur on Internet Mail Messages and Network News Articles. The
intention of this document is to list all such attributes in one
document as an aid to people developing message systems or interested
in Internet Mail standards.
The document contains all heading attributes which the author has
found in the following Internet standards: RFC 821 [1], RFC 822 [2],
RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11],
RFC 1766 [12] and RFC 1806 [14]. Note in particular that heading
attributes defined in RFC 1421-1424, "Privacy Enhancement for Internet
Electronic Mail", are not included. A few additional attributes which
often can be found in e-mail headings but are not part of any Internet
standard are also included.
For each heading attribute, the document gives a short description and
a reference to the Internet standard or RFC, in which they are defined.
2. Use of gatewaying attributes
RFC 1327 defines a number of new attributes in Internet mail, which
are defined to map attributes which X.400 has but which were
previously not standardized in Internet mail. The fact that an
attribute occurs in RFC 1327 indicates that it is recommended for
use in gatewaying messages between X.400 and Internet mail, but
does not mean that the attribute is recommended for messages wholly
within Internet mail. Some of these attributes may eventually get
accepted also for usage within Internet mail, but they are, when
this is written (July 1995) not recommended for such usage.
Fields defined in RFC 1036 for use in Usenet News sometimes appear
in mail messages, either because the messages have been gatewayed
from Usenet News to e-mail, or because the messages were written in
combined clients supporting both e-mail and Usenet News in the same
client. These fields are however not standardized for use in
Internet e-mail and should be handled with caution.
Fields are given here in the spelling used in e-mail headers. This
may sometimes be English, sometimes American spelling. One attribute,
"Organisation/Organization" occurs in e-mail headers sometimes with
English, sometimes with American spelling.
Palme [Page 3]
draft-ietf-mailext-mail-attributes-03.txt November 1995
3. Table of attributes
3.1 Phrases used in the tables
"not for general Used to mark attributes which are defined in
usage" RFC 1327 for use in messages from or to
Internet mail/X.400 gateways. These attributes
have not been standardized for general usage
in the exchange of messages between Internet
mail-based systems.
"not standardized Used to mark attributes defined only in RFC
for use in e-mail" 1036 for use in Usenet News. These attributes
have no standard meaning when appearing in e-
mail, some of them may even be used in
different ways by different software. When
appearing in e-mail, they should be handled
with caution. Note that RFC 1036, although
generally used as a standard for Usenet News,
is not an accepted IETF standard or on the
IETF standards track.
"non-standard" This attribute is not specified in any of
those referenced RFC-s which are Internet
standards, draft standards or proposed
standards. The attribute appears here because
it is common in e-mail or Usenet News headers.
Usage of these attributes is not in general
recommended.
"discouraged" This attribute, which is non-standard, is
known to create problems and should not be
generated. Handling of such attributes in
incoming mail should be done with great
caution.
"controversial" The meaning and usage of this attribute is
controversial, i.e. different implementors
have chosen to implement the attribute in
different ways. Because of this, such
attributes should be handled with caution and
understanding of the different possible
interpretations.
"for limited use" Attributes defined in a so-called
"experimental" Internet standard. These should
be used only if both parties agree.
"experimental" This attribute is used for newly defined
attributes, which are to be tried out before
entering the IETF standards track.
Palme [Page 4]
draft-ietf-mailext-mail-attributes-03.txt November 1995
3.2 Addressing information
Original sender. Should in MAIL FROM RFC 821,
Internet be empty ("MAIL FROM: RFC 1123: 5.2.9.
<>") when sending notifications,
and be the list administrator
when forwarding from a
distribution list. This value may
for gatewayed messages contain a
chain of hosts to be passed in
sequence to reach the original
sender (i.e. a relative address).
Used to convey the information Return-Path: RFC 821,
from the MAIL FROM envelope RFC 1123: 5.2.13.
attribute when the message leaves
the SMTP environment in which
"MAIL FROM" is used.
Recipient to which message is to RCPT TO RFC 821,
be delivered. Relative address RFC 1123: 5.2.6.
was allowed in RFC 821, but later
prohibited in RFC 1123.
3.3 Envelope and format
information
All that is inside the envelope. DATA RFC 821,
RFC 1123: 5.2.8.
Trace of MTA-s which a message Received: RFC 822: 4.3.2,
has passed. RFC 1123: 5.2.8.
An indicator that this message is MIME-Version: RFC 1521: 3.
formatted according to the MIME
standard, and an indication of
which version of MIME is
utilized.
List of MTA-s passed. Path: RFC 1036: 2.2.6,
not standardized
for use in e-mail.
Special Usenet News actions. Control: RFC 1036: 2.1.6,
not standardized
for use in
e-mail.
Trace of distribution lists DL-Expansion- RFC 1327, not for
passed. History- general usage.
Indication
Palme [Page 5]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Which body part types occur in Original- RFC 1327, not for
this message. Encoded- general usage.
Information-
Types:
Special informational message. Message-Type: RFC 1327, not for
Delivery general usage.
Report
Controls whether this message may Alternate- RFC 1327, not for
be forwarded to alternate Recipient: general usage.
recipients such as a postmaster
if delivery is not possible to
the intended recipient. Default:
Allowed.
Whether recipients are to be told Disclose- RFC 1327, not for
the names of other recipients of Recipients: general usage.
the same message. This is
primarily an X.400 facility, such
disclosure is in Internet mail
done via the To:, Cc: and Bcc:
heading fields.
Whether a MIME body part is to be Content- RFC 1806,
shown inline or is an attachment, Disposition: experimental
can also indicate a suggested
filename for use when saving an
attachment to a file.
3.4 Sender and recipient
indication
Author, approver From: RFC 822: 4.4.1,
RFC 1123: 5.2.15-
16, 5.3.7.
Moderator Approved: RFC 1036: 2.2.11,
not standardized
for use in e-mail.
Sender information inside the Sender: RFC 822: 4.4.2,
envelope. RFC 1123: 5.2.15-
16, 5.3.7.
Main recipients. To: RFC 822: 4.5.1,
RFC 1123: 5.2.15-
16, 5.3.7.
Additional recipients. Cc: RFC 822: 4.5.2,
RFC 1123. 5.2.15-
16, 5.3.7.
Palme [Page 6]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Recipients not shown to other Bcc: RFC 822: 4.5.3,
recipients. RFC 1123: 5.2.15-
16, 5.3.7.
In Usenet News: group to which Newsgroups: RFC 1036: 2.1.3,
this article was posted. not standardized
Some systems provide this field and controversial
also in e-mail although it is not for use in e-mail.
standardized there.
Unfortunately, the field can
appear in e-mail with two
different and contradictory
meanings:
(a) Indicates the newsgroup
recipient of a message sent to
both e-mail and Usenet News
recipients.
(b) In a personally addressed
reply to a message in a news-
group, indicate the newsgroup in
which this discussion originated.
Inserted by Sendmail when there Apparently- Non-standard,
is no "To:" recipient in the To: discouraged,
original message, listing mentioned in
recipients derived from the RFC 1211.
envelope into the message
heading. This behavior is not
quite proper, MTA-s should not
modify headings (except inserting
Received lines), and it can in
some cases cause Bcc recipients
to be wrongly divulged to non-Bcc
recipients.
Limitation on where this message Distribution: RFC 1036: 2.2.7,
can be distributed. not standardized
for use in e-mail.
Fax number of the originator. Fax:, Non-standard.
Telefax:
Phone number of the originator. Phone: Non-standard.
Information about the client Mail-System- Non-standard.
software of the originator. Version:,
Mailer:,
Originating-
Client:
Palme [Page 7]
draft-ietf-mailext-mail-attributes-03.txt November 1995
3.5 Response control
This heading field is meant to Reply-To: RFC 822: 4.4.3,
indicate where the sender wants controversial.
replies to go. Unfortunately,
this is ambiguous, since there
are different kinds of replies,
which the sender may wish to go
to different addresses. In
particular, there are personal
replies intended for only one
person, and group replies,
intended for the whole group of
people who read the replied-to
message (often a mailing list).
There has been various
suggestions to differentiate
between these two uses of "Reply-
To", with new header fields names
"Personal-Reply-To", "Group-Reply-
To" or "Wide-Reply-To". None of
these proposals have been
accepted.
In practice, "Reply-To" is often
used to indicate a neater format
for the e-mail address of the
sender than that given in the
"From" field. In this case, it
would be better to put the neater
format directly in the "From"
field.
A well-known mailing list
software will optionally insert
"Reply-To" with the name of the
list into messages distributed by
the list.
The opinion of the author of this
RFC is that you should avoid
using "Reply-To" until IETF has
defined less ambiguous
constructs. This opinion is
however also controversial and
not shared by everyone.
Palme [Page 8]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3,
that future discussions (=follow- not standardized
up) on an article should go to a for use in e-mail.
different set of newsgroups than
the replied-to article. The most
common usage is when an article
is posted to several newsgroups,
and further discussions is to
take place in only one of them.
In e-mail, this heading field is
used in a message which is sent
to both e-mail and Usenet News,
to show where follow-up in Usenet
news is wanted. The field does
not say anything about where
follow-up in e-mail is to be
sent.
Address to which notifications Errors-To:, Non-standard,
are to be sent and a request to Return- discouraged.
get delivery notifications. Receipt-To:
Internet standards recommend,
however, the use of RCPT TO and
Return-Path, not Errors-To, for
where delivery notifications are
to be sent, and a new standard
for delivery notifications
specifies how requests for
notifications are specified by a
new parameter "NOTIFY" to the
"RCPT TO" SMTP command.
An IETF group is working on a Disposition- Do not use until
standard for receipt notifica- Notification- the proposal from
tions (note that this is not the To: this IETF group is
same as delivery notifications). ready and accepted
This group is discussing this new by IETF.
heading field, but no agreement
has been reached yet.
Whether non-delivery report is Prevent- RFC 1327, not for
wanted at delivery error. Default NonDelivery- general usage.
is to want such a report. Report:
Whether a delivery report is Generate- RFC 1327, not for
wanted at successful delivery. Delivery- general usage.
Default is not to generate such a Report:
report.
Indicates whether the content of Content- RFC 1327, not for
a message is to be returned with Return general usage.
non-delivery notifications.
Palme [Page 9]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Indicates whether the content of RET in DRPT In forthcoming new
a message is to be returned with SMTP exten- Internet standard.
non-delivery notifications. sion
3.6 Message identification and
referral attributes
Unique ID of this message. Message-ID: RFC 822: 4.6.1.
Unique ID of one body part of the Content-ID: RFC 1521: 6.1.
content of a message.
Reference to message which this In-Reply-To: RFC 822: 4.6.2.
message is a reply to.
Reference to other related References: RFC 822: 4.6.3.
messages.
Reference to previous message Obsoletes: RFC 1327, not for
being corrected and replaced. general usage.
Used in Usenet News in similar Supersedes: Non-standard.
ways to the "Obsoletes" attribute
described above.
3.7 Other textual attributes
Search keys for data base Keywords: RFC 822: 4.7.1.
retrieval.
Title, heading, subject. Subject: RFC 822: 4.7.1.
Comments on a message. Comments: RFC 822: 4.7.2.
Description of a particular body Content- RFC 1521: 6.2.
part of a message. description:
Organization to which the sender Organization: RFC 1036: 2.2.8,
of this message belongs. not standardized
for use in e-mail.
See Organization above. Organisation: Non-standard.
Short text describing a longer Summary: RFC 1036: 2.2.10,
message. Warning: Some mail not standardized
systems will not display this for use in e-mail,
text to the recipient. Because of discouraged.
this, do not use this field for
text which you want to ensure
that the recipient gets.
A text string which identifies Content- RFC 1327, not for
the content of a message. identifier: general usage.
Palme [Page 10]
draft-ietf-mailext-mail-attributes-03.txt November 1995
3.8 Attributes containing dates
and times
The time when a message was Delivery- RFC 1327, not for
delivered to its recipient. Date: general usage.
In Internet, the date when a Date: RFC 822: 5.1,
message was written, in X.400, RFC 1123: 5.2.14.
the time a message was submitted.
A suggested expiration date. Can Expires: RFC 1036: 2.2.4,
be used both to limit the time of not standardized
an article which is not for use in e-mail.
meaningful after a certain date,
and to extend the storage of
important articles.
Time at which a message loses its Expiry-Date: RFC 1327, not for
validity. general usage.
Latest time at which a reply is Reply-By: RFC 1327, not for
requested (not demanded). general usage.
3.9 Quality information
Can be "normal", "urgent" or "non- Priority: RFC 1327, not for
urgent" and can influence general usage.
transmission speed and delivery.
Sometimes used as a priority Precedence: Non-standard,
value which can influence controversial,
transmission speed and delivery. discouraged.
Common values are "bulk" and
"first-class". Other uses is to
control automatic replies and to
control return-of-content
facilities, and to stop mailing
list loops.
Can be high, normal or low and is Importance: RFC 1327, not for
only used in the recipient client general usage.
(UA).
Can be personal, private, company Sensitivity: RFC 1327, not for
confidential or absent. general usage.
Body parts are missing. Incomplete- RFC 1327, not for
Copy: general usage.
Palme [Page 11]
draft-ietf-mailext-mail-attributes-03.txt November 1995
3.10 Language information
Can include a code for the Language: RFC 1327, not for
natural language used in a general usage.
message, e.g. "en" for English.
Can include a code for the Content- RFC 1766, proposed
natural language used in a Language: standard.
message, e.g. "en" for English.
3.11 Size information
Inserted by certain mailers to Content- Non-standard,
indicate the size in bytes of the length: discouraged.
message text. Can cause several
robustness and interoperability
problems and is not recommended.
Size of the message. Lines: RFC 1036: 2.2.12,
not standardized
for use in e-mail.
3.12 Conversion control
The body of this message may not Conversion: RFC 1327, not for
be converted from one character general usage.
set to another.
The body of this message may not Conversion- RFC 1327, not for
be converted from one character With-Loss: general usage.
set to another if information
will be lost.
3.13 Encoding information
Format of content (character set Content-Type: RFC 1049,
etc.) Note that the values for RFC 1123: 5.2.13,
this field are defined in RFC 1521: 4.
different ways in RFC 1049 and in
MIME (RFC 1521), look for the
"MIME-version" heading field to
understand if Content-Type is to
be interpreted according to RFC
1049 or according to MIME. The
MIME definition should be used in
generating mail.
Coding method used in content. Content- RFC 1521: 5.
Transfer-
Encoding
Palme [Page 12]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Coding method used in content. Encoding: RFC 1154,
RFC 1505,
for limited use.
3.14 Resent-attributes
When manually forwarding a Resent-Reply- RFC 822: C.3.3.
message, attributes referring to To:,
the forwarding, not to the Resent-From:,
original message. Note: MIME Resent-
specifies another way of Sender:,
resending messages, using the Resent-From:,
"Message" Content-Type. Resent-Date:,
Resent-To:,
Resent-cc:,
Resent-bcc:,
Resent-
Message-ID:
3.15 Miscellaneous
Name of file in which a copy of Fcc: Non-standard.
this message is stored.
Has been automatically forwarded. Auto- RFC 1327, not for
Forwarded: general usage.
Can be used in Internet mail to Discarded- RFC 1327, not for
indicate X.400 extensions which X400-IPMS- general usage.
could not be mapped to Internet Extensions:
mail format.
Can be used in Internet mail to Discarded- RFC 1327, not for
indicate X.400 extensions which X400-MTS- general usage.
could not be mapped to Internet Extensions:
mail format.
4. Acknowledgments
Harald Tveit Alvestrand, Keith Moore, Nick Smith and several other
people have helped me with compiling this list. I alone take
responsibility for any errors which may still be in the list.
An earlier version of this list has been published as part of [13].
Palme [Page 13]
draft-ietf-mailext-mail-attributes-03.txt November 1995
5. References
Ref. Author, title IETF status
(July 1995)
----- --------------------------------------------- -----------
- -
[1] J. Postel: "Simple Mail Transfer Protocol", Standard,
STD 10, RFC 821, August 1982. Recommended.
[2] D. Crocker: "Standard for the format of ARPA Standard,
Internet text messages." STD 11, RFC 822, Recommended.
August 1982.
[3] M.R. Horton, R. Adams: "Standard for Not an offi-
interchange of USENET messages", RFC 1036, cial IETF
December 1987. standard,
but in
reality a de-
facto
standard for
Usenet News.
[4] M. Sirbu: "A Content-Type header field for Standard,
internet messages", RFC 1049, March 1988. Recommended.
[5] R. Braden (editor): "Requirements for Standard,
Internet Hosts -- Application and Support", Required.
STD-3, RFC 1123, October 1989.
[6] D. Robinson, R. Ullman: "Encoding Header Non-
Field for Internet Messages", RFC 1154, April standard.
1990.
[7] S. Hardcastle-Kille: "Mapping between Proposed
X.400(1988) / ISO 10021 and RFC 822", RFC standard,
1327 May 1992. elective.
[8] H. Alvestrand & J. Romaguera: "Rules for Proposed
Downgrading Messages from X.400/88 to standard,
X.400/84 When MIME Content-Types are Present elective.
in the Messages", RFC 1496, August 1993.
[9] A. Costanzo: "Encoding Header Field for Non-
Internet Messages", RFC 1154, April 1990. standard.
[10] A. Costanzo, D. Robinson: "Encoding Header Experimental
Field for Internet Messages", RFC 1505, .
August 1993.
Palme [Page 14]
draft-ietf-mailext-mail-attributes-03.txt November 1995
[11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft
Internet Mail Extensions) Part One: Standard,
Mechanisms for Specifying and Describing the elective.
Format of Internet Message Bodies", RFC 1521,
Sept 1993.
[12] H. Alvestrand: "Tags for the Identification Proposed
of Languages", RFC 1766, February 1995. standard,
elective.
[13] J. Palme: "Electronic Mail", Artech House Non-
publishers, London-Boston January 1995. standard.
[14] R. Troost, S. Dorner: "Communicating Experimental
Presentation Information in Internet .
Messages: The Content-Disposition Header",
RFC 1806, June 1995.
6. Author's address
Jacob Palme Phone: +46-8-16 16 67
Stockholm University/KTH Fax: +46-8-783 08 29
Electrum 230 E-mail: jpalme@dsv.su.se
S-164 40 Kista, Sweden
Palme [Page 15]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Appendix A:
Attributes sorted by Internet RFC document in which they appear.
RFC 821
-------
DATA
MAIL FROM
RCPT TO
RFC 822
-------
Bcc
Cc
Comments
Date
From
In-Reply-To
Keywords
Message-ID
Received
References
Reply-To
Resent-
Resent-bcc
Resent-Date
Resent-From
Resent-From
Resent-Message-ID
Resent-Reply-To
Resent-ToResent-cc
Return-Path
Sender
Sender
Subject
To
RFC 1036
--------
Approved
Control
Distribution
Expires
Followup-To
Lines
Newsgroups
Organization
Path
Summary
Palme [Page 16]
draft-ietf-mailext-mail-attributes-03.txt November 1995
RFC 1049
--------
Content-Type
RFC 1327
--------
Alternate-recipient
Auto-Forwarded
Autoforwarded
Content-identifier
Content-Return
Conversion
Conversion-With-Loss
Delivery-Date
Discarded-X400-IPMS-Extensions
Discarded-X400-MTS-Extensions
Disclose-Recipients
DL-Expansion-History
Expiry-Date
Generate-Delivery-Report
Importance
Incomplete-Copy
Language
Message-Type Delivery
Obsoletes
Original-Encoded-Information-Types
Prevent-NonDelivery-Report
Priority
Reply-By
Report
Sensitivity
RFC 1505
--------
Encoding
RFC 1521
--------
Content-Description
Content-ID
Content-Transfer-Encoding
Content-Type
MIME-Version
RFC 1806
--------
Content-Disposition
Palme [Page 17]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Not Internet standard
---------------------
Apparently-to
Content-length
Encoding
Errors-To
Return-Receipt-To
Fax
Telefax
Fcc
Mail-System-Version
Mailer
Organisation
Originating-Client
Phone
Supersedes
Palme [Page 18]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Appendix B:
Alphabetical index
Section Heading-field
------- -------------
3.3 Alternate-Recipient
3.4 Apparently-To
3.4 Approved
3.16 Auto-Forwarded
3.4 Bcc
3.4 Cc
3.7 Comments
3.7 Content-Description
3.3 Content-Disposition
3.6 Content-ID
3.7 Content-identifier
3.10 Content-Language
3.11 Content-Length
3.5 Content-Return
3.13 Content-Transfer-Encoding
3.13 Content-Type
3.3 Control
3.12 Conversion
3.12 Conversion-With-Loss
3.3 DATA
3.8 Date
3.8 Delivery-Date
3.16 Discarded-X400-IPMS-Extensions
3.16 Discarded-X400-MTS-Extensions
3.3 Disclose-Recipients
3.5 Disposition-Notification-To
3.4 Distribution
3.3 DL-Expansion-History-Indication
3.13 Encoding
3.5 Errors-To
3.8 Expires
3.4 Fax
3.15 Fcc
3.5 Followup-To
3.4 From
3.5 Generate-Delivery-Report
3.9 Importance
3.6 In-Reply-To
3.9 Incomplete-Copy
3.7 Keywords
3.10 Language
3.11 Lines
3.2 MAIL FROM
3.4 Mail-System-Version
3.4 Mailer
3.6 Message-ID
3.3 Message-Type
Palme [Page 19]
draft-ietf-mailext-mail-attributes-03.txt November 1995
3.3 MIME-Version
3.4 Newsgroups
3.6 Obsoletes
3.7 Organisation
3.7 Organization
3.3 Original-encoded-Information-Types
3.4 Originating-Client
3.3 Path
3.4 Phone
3.9 Precedence
3.5 Prevent-NonDelivery-Report
3.9 Priority
3.2 RCPT TO
3.3 Received
3.6 References
3.8 Reply-By
3.5 Reply-To
3.14 Resent-
3.5 RET in DRPT SMTP extension
3.2 Return-Path
3.5 Return-Receipt-To
3.4 Sender
3.9 Sensitivity
3.7 Subject
3.7 Summary
3.6 Supersedes
3.4 Telefax
3.4 To
Palme [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 10:39:50 |