Internet DRAFT - draft-schmeing-smtp-priorities
draft-schmeing-smtp-priorities
Network Working Group M. Schmeing
Internet-Draft FGAN
Expires: February 24, 2007 J. Brendecke
K. Carlberg
G11
August 23, 2006
SMTP Service Extension for Priority Message Handling
draft-schmeing-smtp-priorities-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 24, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo defines an extension to the SMTP (Simple Mail Transfer
Protocol) service whereby messages are sent with a priority to
achieve a certain order in which the messages are transferred by an
MTA (Message Transfer Agent). This priority or precedence order is
used instead of the first-come-first-serve rule. This extension is
Schmeing, et al. Expires February 24, 2007 [Page 1]
Internet-Draft Priority Extension for SMTP August 2006
not to be confused with "Importance of a Message" which is widely
deployed using an email header such as Importance or even Priority or
Precedence with common values of HIGH, NORMAL and LOW. Importance of
a Message does not affect the priority of the transport itself in any
way. Nevertheless, there may be policy defined relations between
priorities and importance indicators.
This extension uses the term priority in the meaning of expedited
treatment of a message by the server according to its priority.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology & background . . . . . . . . . . . . . . . . . . . 5
4. Framework for the Priority Extension . . . . . . . . . . . . . 6
5. The Priority Service Extension . . . . . . . . . . . . . . . . 8
5.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Probability . . . . . . . . . . . . . . . . . . . . . 9
5.1.2. Preemption of sessions or transactions . . . . . . . . 9
5.1.3. Handling of emails with multiple recipients . . . . . 10
5.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 10
5.3. Resolving conflicts for the sending order of messages
with the same priority . . . . . . . . . . . . . . . . . . 10
5.4. Size Limitation . . . . . . . . . . . . . . . . . . . . . 11
5.5. Further Constraints . . . . . . . . . . . . . . . . . . . 12
6. Recipient Dependent Priority . . . . . . . . . . . . . . . . . 13
6.1. Maillists, Aliases and Forwarding . . . . . . . . . . . . 13
7. NameSpaces . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Conflicts with external constraints . . . . . . . . . . . 15
7.2. Handling Non-priority Servers and Mismatching Policies . . 16
7.3. Recipients without priorities . . . . . . . . . . . . . . 17
7.4. Invalid priority levels . . . . . . . . . . . . . . . . . 17
7.5. Mappings to other NameSpaces . . . . . . . . . . . . . . . 17
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. List of abbreviations . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Informative Reference . . . . . . . . . . . . . . . . . . 23
12.2. Normative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Schmeing, et al. Expires February 24, 2007 [Page 2]
Internet-Draft Priority Extension for SMTP August 2006
1. Introduction
Prioritization is an issue that gains attention when resources are
scarce and sets of users (and their data) are considered more
important than others. Military Message Handling Systems (MMHS) such
as AUTODIN and the Defense Messaging System (DMS), have requirements
to prioritize their traffic to help ensure that important data is
given preferential treatment over what would normally be viewed as
best effort.
Deployments of MMHS typically include the ability to preempt or
displace less important data traffic. This displacement can be in
the form of dropped packets, removal of reservations or termination
of end-to-end sessions. Outside MMHS systems such as GETS rely on
increasing the probability of obtaining resources or successfully
forwarding downstream packets instead of preempting resources. In
either case, the critical feature incumbent in both systems is an
ability to prioritize data in anticipation of resource contention.
The Simple Mail Transfer Protocol [7] (SMTP) is one of the most
popular applications used over the Internet by today's general
public. The examinations documented in [1] show that SMTP, including
some SMTP extensions, also provides most of the features requested by
the military (a user community whose requirements are more stringent
than the general public). But one of the most important requirements
of MMHS not provided by SMTP is priority or precedence in handling
between Message Transfer Agents (MTA).
This document defines an SMTP Service Extension offering such a
service allowing Mail Transfers Agents to determine which emails
require expedited handling.
Schmeing, et al. Expires February 24, 2007 [Page 3]
Internet-Draft Priority Extension for SMTP August 2006
2. Terminology
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
and "MAY" in this document are to be interpreted as described in "Key
words for use in RFCs to Indicate Requirement Levels" [4].
The terms SMTP client and SMTP server are used with the same
definition as given in section 2.3.2 of RFC 2821 [7]:
o The SMTP client is the (computer) process initiating an SMTP
session and controlling it issuing commands to the server.
o The SMTP server is the process waiting for clients to connect and
executing the commands from the client.
As this document is concerned with SMTP only, the terms client and
server may as well be used without the SMTP prefix.
An email is waiting to be sent, if it resides in the queue of an MTA
and can be send to the next hop or delivered to its final
recipient(s) once available resources at the sending MTA allow this.
Emails having their processing delayed for some reason are NOT
waiting to be sent during this delay. The most important reason for
emails to be delayed is a transient error response from the next MTA
to which the email must be transferred.
An email is ready to be sent, if it is waiting to be sent and either
no emails with higher priority are waiting to be sent or available
resources allow to send more emails in parallel than the number of
emails with higher priorities that are waiting to be sent. Note that
an email may be ready to be sent but the transfer or delivery process
can not yet be initiated, because the number of emails ready to be
sent exceeds the number of emails that can be processed in parallel.
The policy defining the use of priorities within a given NameSpace is
called "NameSpace Policy". A NameSpace is a name (or label) for a
finite and ordered set of priorities. In some instances, this memo
or a NameSpace Policy may allow additions to the definitions of the
NameSpace Policy. These additions are called "local policy".
Schmeing, et al. Expires February 24, 2007 [Page 4]
Internet-Draft Priority Extension for SMTP August 2006
3. Terminology & background
RFC 3487 [15] articulates a set of requirements for prioritizing
access to services and resources using the Session Initiation
Protocol (SIP). As in the case of SMTP, SIP has a priority field
used to convey the importance of a session (or message, in the case
of SMTP) to the end-user. However, the value within the field was
not meant for intermediate nodes. From these requirements, the SIP
working group defined a new optional Resource Priority field in RFC
4412 [16] for the SIP protocol. The new field was divided into two
distinct parts. The first is Value subfield, which contains the
priority associated with the SIP message. The second subfield is the
NameSpace, which identifies a set or family of 1 or more priorities.
The strength in this approach is that support for the prioritization
feature is not bound to a one-size-fits-all design. As an example,
the DoD/NATO community has an existing set of 5 priorities used for
its messaging system. Other communities of interest may have sets
that are smaller or larger than that currently used by DoD/NATO.
Underneath the SIP layer, and its Resource Priority extension, on-
going work is being done by the NSIS working group to define a QSPEC
that includes fields correlating to SIP's NameSpace/Value tuple. In
addition, the TSV Working Group is in the process of defining an
extension to RSVP that defines a priority policy element correlating
to the NameSpace/Value tuple. Both of these efforts are aimed at
facilitating underlying signaling of network elements to obtain
resources based on the priority set at the application layer.
Schmeing, et al. Expires February 24, 2007 [Page 5]
Internet-Draft Priority Extension for SMTP August 2006
4. Framework for the Priority Extension
o The textual name of this extension is "Priority Message Handling".
o The EHLO-Keyword is PRIORITY.
o One mandatory parameter is used with this keyword. This parameter
is a list of NameSpaces supported by the server. The syntax for
this value is described below. The "token-nodot" production is
copied from RFC 3265 [10].
namespace-list = namespace * (COMMA namespace)
namespace = token-nodot
token-nodot = 1*(alphanum / "-" / "!" / "%" / "*" /
" " / "+" / "`" / "'" / "~")
A NameSpace is a name of an ordered set of priorities with
attached policy.
o No new SMTP verbs are defined.
o One optional parameter using the keyword "PRIORITY" is added to
the RCPT TO command. The value associated with this parameter is
in alpha-numeric form. The syntax of the value is :
priority-arg = "PRIORITY" EQUAL value
value = namespace "." priority
priority = token-nodot
o Two examples of PRIORITY parameters are shown below:
PRIORITY=Example.1
PRIORITY=AnotherExample.Flash
o The 'value' parameter in the 'PRIORITY' extension indicates the
concatenated tuple of the 'namespace', the 'priority' within that
NameSpace and the "." character separating the two. An entry in a
'namespace' must be unique from all other NameSpaces. Entries in
a 'priority' must be unique within a NameSpace, but they may be
the same as those in other NameSpaces.
o The maximum length of a RCPT TO command line is increased by 9
characters plus the length of the 'value-list' by the possible
Schmeing, et al. Expires February 24, 2007 [Page 6]
Internet-Draft Priority Extension for SMTP August 2006
addition of the PRIORITY keyword and value.
o As one of the most likely instances to assign transport priorities
is the submitting party of an email (i.e. the originator or
sender), this extension is valid for message submission according
to RFC 2476 [6].
Schmeing, et al. Expires February 24, 2007 [Page 7]
Internet-Draft Priority Extension for SMTP August 2006
5. The Priority Service Extension
The priority of a message expresses itself in the order they are
transfered from the client to the server. This is largely
independent from the order in which they where received by the
server. The Priority Service Extension increases the possibilities
of SMTP service extensions such as Deliver-By [8] and Delivery Status
Notification [11][14][13][12] or (non-standard) header fields such as
Importance.
In military scenarios, priorities usually come with additional
associated constraints. Examples are limitations of the message size
or the allowed delivery time.
5.1. Expedited Transfer
The main service provided by the Priority Message Handling SMTP
Service Extension is expedited transfer of emails with a higher
priority. Therefore a client that has more than one email to send at
a given time MUST send those with a higher priority before those with
a lower one.
Priorities are assigned on a per-recipient basis. The priority of an
email is the highest priority assigned to any of the yet unprocessed
recipients. Thus the priority of the email may vary while it is
processed by an MTA or UA and may be different at different MTAs.
The priority of any given recipient is nevertheless constant.
As a default policy, emails with higher priority waiting to be sent
by a client MUST NOT initiate transactions for emails with lower
priorites. It MAY however send an email with highest priority even
to recipients with lower priorities if this can be done within the
same transaction as the higher priorities. Policy associated with a
specific NameSpace may override this default policy; an example being
the use of a weighted round robin initiation of transactions in order
to prevent a starving of resources from lower priorities.
The handling of messages with the same priority level is described in
Section 5.3.
Especially in networks with limited available data rate the actual
transfer over the network may create a significant portion of the
overall delivery time. Besides the actions taken at the application
level it can thus be important to deploy priority or precedence
mechanisms offered by the network itself to ensure timely delivery of
the emails. One example would be the use of RSVP and the work-in-
progress effort extension to RSVP that prioritizes reservations. If
such services are available, it is a matter of NameSpace Policy to
Schmeing, et al. Expires February 24, 2007 [Page 8]
Internet-Draft Priority Extension for SMTP August 2006
decide whether to use them. The mapping from the priorities defined
at the SMTP level to those offered by the underlying network is as
well to be defined in the NameSpace Policy. If the NameSpace Policy
does not regulate the use of network priorities, their use can be
defined by local policy
Most current SMTP MTAs are capable of handling several inbound and
outbound connections at once. With this feature it should be
possible to start additional outbound connections for emails with
higher priorities even if there are already several connections
running for other emails. The manner in which expedited transfer can
be accomplished is divided into two approaches. One is probability,
the other involves preemption, both of which are described in more
detail below.
5.1.1. Probability
As the name suggests, probabiblity involves increasing the chances of
obtaining resources without adversely affecting previously
established connections. One example would involve requesting
resources set aside for specific priority levels. If these
additional resources are exhausted, then the desired connection is
denied. Queues, new timers, or combinations thereof can be used to
facilitate the higher priority requests, but the key is that
mechanisms focus on increasing the probability of message transfer.
5.1.2. Preemption of sessions or transactions
Preemption is binary type of action and focusses only on a
comparision of priorities to determine if previously established
transactions must be displaced in favor of higher priority requests.
If no additional connection is possible, a client MUST abort a
running session for emails with lower priority no later than directly
after the current transaction. The client even MAY interrupt an
active transaction and SHOULD do this, if otherwise constraints such
as delivery time would be violated for the email with higher
priority. This preliminary termination of sessions or transactions
is called preemption.
If preemption of running transactions occurs, the client MUST preempt
the lowest number of transactions sufficient to process the higher
priority emails. It must chose the transactions for the emails with
the lowest priorities currently processed. NameSpace Policies and
local policies MAY add additional criteria to choose the transaction
to be preempted in the case that more transactions than required
would qualify for preemption due to the priority of the emails.
Regulations from local policy MUST NOT be applied before NameSpace
Policy and MUST NOT conflict with NameSpace policy settings. If
Schmeing, et al. Expires February 24, 2007 [Page 9]
Internet-Draft Priority Extension for SMTP August 2006
after applying the priority test and all criteria defined by
applicable NameSpace Policy and the local policy still the number of
transactions to preempt is greater than needed, the decision is left
to the implementation.
If the client has an option to interrupt transactions in a way that
it can be restarted at the interruption point later, it SHOULD deploy
it. An example for a mechanism providing such a service is the "SMTP
Service Extension for Checkpoint/Restart" defined in RFC 1845 [2]
If a client opts for the preemption of sessions instead of
transactions, it MUST preempt the next session that reaches the end
of a transaction independent of the priority of the emails being
processed.
5.1.3. Handling of emails with multiple recipients
If a client has to send an email with multiple recipients bearing
different priorities to the same server, it SHOULD do so in one
transaction treating the email according to the highest priority set
for any of the recipients.
The reorganization of the transfer order MUST NOT alter or even
corrupt the emails, therefore allowing safe transmission of all
emails in dependency of their priority.
5.2. Timely Delivery
An important constraint usually associated especially with higher
priority levels is, that messages with that priority have to reach
its destination within a defined period of time. In some cases,
higher priorities mean shorter maximum allowed time of delivery.
As SMTP does not natively offer a service for timely delivery, the
decision whether to use delivery time constraints for any or all
priority levels is left to the NameSpace Policy.
The "Deliver By SMTP Service Extension" (Deliver-By Extension)
defined in [8] is an example of an SMTP extension providing a service
that can be used to implement such constraints.
If applicable NameSpace Policy does not specify time constraints for
a given priority, no such constraints are applied.
5.3. Resolving conflicts for the sending order of messages with the
same priority
If two or more emails with the same priority are ready to be sent at
Schmeing, et al. Expires February 24, 2007 [Page 10]
Internet-Draft Priority Extension for SMTP August 2006
the same time, clients SHOULD send them in parallel if possible.
NameSpace Policy and local policy MAY define rules to determine the
order in which emails of the same priority are sent if the number of
emails ready to be sent exceeds the number of emails that can be
processed in parallel. Definitions from NameSpace Policy always take
precedence over definitions from local policy. NameSpace Policy MAY
disallow local policy to define addtitional criteria to determin
sending order.
If all applicable rules to determine the sending order from this
memo, applicable NameSpace Policy and (if permitted) local policy
still leave more emails ready to be sent than can be processed in
parallel, the final decision is left to the implementation.
5.4. Size Limitation
The larger a message, the longer the time required to send it over a
given connection. In constrained networks this can impair the
possibility of the MTS to deliver large messages with high priorities
in time. Therefore, NameSpace Policy MAY define size constraints for
any or all of its priority levels.
These constraints can always be enforced independent of the SMTP
Service Extensions supported by the server receiving the email. It
is always possible for the server to count the number of received
octets after the client indicated the end of the email and base the
decision to accept or reject the email on this number.
Therefor, after completely receiving the content of the email the
server MUST check that the actual received size does not exceed the
lowest size limitation allowed by the priorities set for all
recipients. If the actual size is too big for at least one
recipient, the server MUST NOT send a successful reply but MUST
reject the email with an error code of "556 Priority defined size
limit exceeded". If the client uses an SMTP Service Extension which
allows to transmit the content in several chunks, such as [9], the
server SHOULD check the current size after every chunk and SHOULD
abort the email with the above error code as soon as the size
constraint applicable for the email is violated.
In addition to just counting the received octets while the email is
being transmitted, a client and server may also deploy mechanisms,
that allow for an earlier detection of size violations. An example
for such a service is the "SMTP Service Extension for Message Size
Declaration" (SIZE Extension) from RFC 1870 [3].
The SIZE Extension allows a client to declare the size of the email
with an optional parameter to the MAIL FROM: SMTP command. This
Schmeing, et al. Expires February 24, 2007 [Page 11]
Internet-Draft Priority Extension for SMTP August 2006
parameter can be used for example to decide for each individual
recipient whether the email fulfils the size constraints. Unless
NameSpace Poicy defines another course of action, if the size
provided with the SIZE argument of the MAIL FROM: command is too
large for the priority set for any of the recipients, the recipient
MUST be rejected with an error code of "556 Priority defined size
limit exceeded". Processing for the remaining recipients is to
continue normally.
If the NameSpace Policy does not address size constraints, the
default is that emails may be of arbitrary size. Constraints imposed
by other circumstances such as available storage space or general
limitations are, of course, unaffected by this.
5.5. Further Constraints
Depending on the actual scenario in which this priority extension is
deployed, it may be necessary to add further constraints to certain
priority levels. Although it is strongly believed that limiting the
delivery time and email size should be sufficient for most if not all
purposes, NameSpace Policy may add further constraints such as
limitations on content types or security classifications.
For example, in military applications of priorities, messages without
classification or with low classification may only be sent at the
lower priority levels.
Schmeing, et al. Expires February 24, 2007 [Page 12]
Internet-Draft Priority Extension for SMTP August 2006
6. Recipient Dependent Priority
Often, not all recipients need to receive the message with the same
(high) priority. For example copy (CC, carbon copy) and blind copy
(BCC, blind carbon copy) recipients usually can accept a lower
priority than the primary recipient(s) because they do not have to
act on the message but receive it only for informational purposes.
Limiting the high priority messages only to the primary recipient
complies with the basic principle of using high priorities only if
really necessary. So the number of high priority messages is reduced
to a minimum. Assigning every recipient an individual priority could
be realized by sending the same message several times. This is
unnecessary, non-practical and a waste of resources. Binding the
priority to the recipient allows to deploy the multiple recipient per
transaction feature of SMTP even when having different priorities for
different recipients of the message.
To lower the burden on the network, an MTA SHOULD send any message to
as many recipients as possible with one transaction, even if the
recipients have different priorities bound to them. In this case,
the MTA MUST treat the email according to the highest priority bound
to any of the recipients and MUST retain the original priority values
for each recipient.
A recipient address, that has a priority other than the non-priority
set, is called a prioritized recipient (address).
6.1. Maillists, Aliases and Forwarding
Several options exist to translate the address of an email recipient
into one or more other addresses. Examples for this are aliases,
maillist or email redirections e.g. via a .forward file.
Priorities are assigned for a reason. Therefore, if a prioritized
recipient address is to be translated or expanded as explained above,
the translating or expanding entity (maillist manager, MTA etc.)
SHOULD retain the original priority if possible and SHOULD set it for
all expanded or translated addresses. NameSpace Policy however MAY
deviate from this behavior for good reason.
Schmeing, et al. Expires February 24, 2007 [Page 13]
Internet-Draft Priority Extension for SMTP August 2006
7. NameSpaces
A NameSpace identifies a set of one or more alpha-numeric priorities.
These NameSpaces are registered with IANA and are unique for the
registry associated with the SMTP priority extension. Ideally a
given NameSpace satisfies the needs for groups of organizations and
user sets. As an example, a NameSpace that correlates to the Q.735.3
protocol in support of Multi-Level Precedence and Preemption (MLPP)
would be applicable to all messaging systems that support Q.735.3.
New NameSpaces MUST be defined as an Informational RFC after Expert
Review in accordance with the policy set forth in RFC 2434 [5]. The
Expert Reviewer will consult with the Application Area Directors and
the IEPREP mailing list. The following elements MUST be addressed
when registering a new NameSpace:
o Priority level(s) must be enumerated as a finite ordered list
o A priority algorithm must be defined and described. This
algorithm defines the schema of how messages are handled based on
their labeled priority. For example, one algorithm may describe
the use of preemption of resources of a lower priority message
(i.e., dropped message) to satisfy a higher priority message.
Another algorithm may involve queuing of messages based on
availability of extra resources set aside for specific priorities.
A third algorithm may be a hybrid of preemption and queuing.
o Any new new response codes (warning or Error) unique to the
NameSpace must be listed and explained.
o The document needs to specify a new row for the following table
that summarizes the features of the NameSpace. For the tabel
below, there is ONE NameSpace label and ONE Algorithm. There
N-number of levels, each having a corresponding Warning-Code OR
Error-Code. It is expected that the warning/error codes are the
same for each NameSpace.Priority tuple. Finally, an RFC is used
as the reference for the table of information.
NameSpace Algo Priority(s) Warn-Code Error-Code Reference
--------- -------- ----------- --------- ---------- ---------
<label> <preempt, <label(s)> <new code, <new code, <RFC>
queue, none> none>
hybrid>
NameSpace labels are case-insensitive, priority labels are case-
Schmeing, et al. Expires February 24, 2007 [Page 14]
Internet-Draft Priority Extension for SMTP August 2006
insensitive unless defined case-sensitive by the NameSpace policy.
In addition to the requirements described above, the following
constraints apply to all NameSpaces:
o If a priority mechanism of the underlying network should be used,
mappings from the SMTP priority level to the priority levels of
the network MUST be defined. If no mapping is defined, servers
SHOULD use the default level for the network connection but MAY
use higher ones. This does not change the SMTP priority level.
o If additional constraints such as size limitations or maximum
delivery times are associated with any or all priorities of a
NameSpace, the RFC must define which constraints apply to which
priority.
o In some cases it is possible to determine that an individual
recipient can not be accepted because of a violation of the
NameSpace Policy directly when the respective RCPT TO SMTP command
is issued. A NameSpace Policy SHOULD define how to handle the
emails in this case. Possible options are to completely reject
the email or to send it to the remaining recipients. The default
is to send the emails to the remaining recipients, if no other
conditions require the email to be rejected completely.
o In other cases the decision to reject an individual recipient can
only be made after the respective RCPT TO: SMTP command has been
confirmed with a 2xx SMTP reply code but the final 250 SMTP reply
code accepting the email has not yet been sent. In these cases
the whole email MUST be rejected with an appropriate error code.
7.1. Conflicts with external constraints
If there is a conflict between a priority induced constraint and a
constraint from some other sources (external constraint), the more
restrictive constraint always has precedence over the less
constrictive one. If an email is rejected because of constraints not
induced by the NameSpace Policy, the error message MUST NOT indicate
a NameSpace Policy violation.
To illustrate this, consider the following example:
o An email with a size of 2 M-Byte is to be sent.
o The NameSpace is recognized and accepted
o The highest priority of the NameSpace set for any of the
recipients is n.
Schmeing, et al. Expires February 24, 2007 [Page 15]
Internet-Draft Priority Extension for SMTP August 2006
o The maximum size for emails with priority n is 3 M-Byte.
o At the server to which the email should be transferred, the
parameter to the SIZE EHLO keyword limits emails to 1 M-Byte in
size due to limited spool storage.
From the perspective of the NameSpace Policy this email would be
acceptable because it is smaller than the 3 M-Bytes allowed for
messages with priority n. Nevertheless, the constraints defined by
the SIZE Extension set a limit of 1 M-Byte, which is more restrictive
than the constraint set by the NameSpace Policy. Thus the constraint
set by the SIZE Extension takes precedence and the email can not be
accepted by the server. The server would respond as defined in RFC
1870 [3] and send the appropriate error code for overly large
messages.
If on the other hand the NameSpace Policy would set the 1 M-Byte
limit and the storage space of the server would allow 3 M-Byte
emails, the email would still be unacceptable. But this time it
would be a NameSpace Policy violation that would be indicated with
the error code defined in section Section 5.4 of this memo.
If both, external and policy induced constraints would make an email
unacceptable, the error message must be created according to the more
restrictive constraint. If, in the above example, the email would
have a size of 4 M-Byte, it would not be acceptable due to both the
limitation defined with the EHLO keyword and the limitation of the
priority policy. As the limitation of the EHLO keyword is more
restrictive the email would still not be a policy violation.
The determination of what error code to create does not discriminate
between transient (i.e. error codes in the 4xx range) and permanent
errors (i.e. error codes in the 5xx range). If the 1M-Byte
restriction of the EHLO keyword would be due to a temporary shortage
of storage space, the 4 M-Byte email from the previous paragraph for
example could be rejected with a transient error from the EHLO
keyword while the shortage lasts. If there would be enough storage
space afterwards, it would still be rejected, but this time with a
permanent error from the NameSpace Policy.
Local policy MAY allow for permanent errors to take precedence over
transient ones to lessen the burden on the network. In this case the
4 M-Byte email would be rejected with a permanent error due to a
policy violation on the first attempt to transfer it to the MTA.
7.2. Handling Non-priority Servers and Mismatching Policies
Not all servers will support the Priority Message Handling Extension
Schmeing, et al. Expires February 24, 2007 [Page 16]
Internet-Draft Priority Extension for SMTP August 2006
nor will all that do have the same policy. Servers that support a
different policy than the client are called mismatching servers;
servers not indicating support for priorities (independent of whether
they actually do or do not support them) are called non-priority
servers.
By default, only emails for recipients without a priority are
delivered to non-priority or mismatching servers. If recipients with
priorities other than the non-priority require sending the email to
mismatching on non-priority servers, this is treated as an error.
The email MUST NOT be relayed but the MTA MUST send a error code of
"557 Receiving server not supporting compliant NameSpace".
NameSpace Policy MAY however define certain priorities to be routable
to non-priority servers. It MAY define arbitrary actions to be taken
in this case or define it as normal operation. This can be defined
for each priority independently. An example for an action to take is
the sending of warning emails to the originator and/or recipient of
the email informing them of the loss of priorities. Another example
is to write log information to the system protocol.
7.3. Recipients without priorities
A server MUST always accept recipients, where no priority is set,
independend of whether other recipients of the email have priorities
assigned or not. Such recipients MUST be treated as best-effort
delivery. Other reasons such as invalid addresses or syntactical
errors in the RCPT TO: command nevertheless may still prevent
acceptance of the recipient.
A client MAY use RCPT TO: commands with and without the PRIORITY
parameter for the same email transaction.
7.4. Invalid priority levels
As a default course of action, if a client provides an invalid value
to the PRIORITY argument to the RCPT TO: command, the server MUST
reject that recipient with an error code of "558 Invalid priority
value" and MAY reject the complete email with the same error code.
NameSpace Policy MAY override the default action upon detection of an
invalid PRIORITY argument. For example, the server may replace the
value with a "NULL" argument, indicating that there is no priority
associated with recipient.
7.5. Mappings to other NameSpaces
A NameSpace A MAY define a mapping to another NameSpace B. NameSpace
Schmeing, et al. Expires February 24, 2007 [Page 17]
Internet-Draft Priority Extension for SMTP August 2006
A in this case MUST define to which priority level of NameSpace B
each of its priority levels is mapped.
While more than one priority level of NameSpace A may be mapped to a
given priority level of NameSpace B, a priority level of A MUST NOT
be mapped to zero or more than one priority levels of B.
For all priority levels a1 and a2 of NameSpace A where a1 is greater
than a2 and all priority levels b1 and b2 of NameSpace B, the
following condition MUST be fulfilled: If a1 is mapped to b1 and a2
is mapped to b2, then b1 MUST be greater than or equal to b2.
An MTA MUST NOT change the priority assigned to a recipient, unless
o the next server to which the email must be sent for the recipient
does not support the original NameSpace; and
o the NameSpace originally used for the recipient defines a mapping
to at least one of the NameSpaces announced by the server to which
the email is to be sent.
Schmeing, et al. Expires February 24, 2007 [Page 18]
Internet-Draft Priority Extension for SMTP August 2006
8. Example
This example shows an SMTP session with one transaction using the
priority extension. Lines starting with C are sent by the client,
lines starting with S by the server.
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-SIZE
S: 250-DSN
S: 250-PRIORITY Example,AnotherExample
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com> PRIORITY=Example.2
S: 250 OK
C: RCPT TO:<Brown@foo.com> PRIORITY=AnotherExample.Flash
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
Schmeing, et al. Expires February 24, 2007 [Page 19]
Internet-Draft Priority Extension for SMTP August 2006
9. Security Considerations
This memo does not discuss security issues and is not believed to
raise any security issues not already endemic in electronic mail and
present in fully conforming implementation of RFC 2821 [7].
Possible Denial-of-Service (DoS) attacks through extensive use of
high priorities are outside the scope of this memo. It is believed
that they are best dealt with by access control and careful design of
local policies.
Schmeing, et al. Expires February 24, 2007 [Page 20]
Internet-Draft Priority Extension for SMTP August 2006
10. IANA Considerations
The IANA Mail Parameters registry documents SMTP service extensions.
The "PRIORITY" service extension has to be added to this registry in
accordance with the specifications of section Section 4.
Schmeing, et al. Expires February 24, 2007 [Page 21]
Internet-Draft Priority Extension for SMTP August 2006
11. List of abbreviations
BCC Blind Carbon Copy
CC Carbon Copy
DSN Delivery Status Notification
IETF Internet Engineering Task Force
IP Internet Protocol
MMHS Military Message Handling System
MTA Message Transfer Agent
MTS Message Transfer System
NATO North Atlantic Treaty Organization
RFC Request For Comment
SMTP Simple Mail Transfer Protocol
TTY Teletypewriter
UA User Agent
URL Uniform Resource Locator
Schmeing, et al. Expires February 24, 2007 [Page 22]
Internet-Draft Priority Extension for SMTP August 2006
12. References
12.1. Informative Reference
[1] Schmeing, M. and N. Haak, "Applicability of Internet-email for
military High-grade Messaging", FKIE-Bericht 93, February 2005.
12.2. Normative References
[2] Crocker, D. and N. Freed, "SMTP Service Extension for
Checkpoint/Restart", RFC 1845, September 1995.
[3] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension
for Message Size Declaration", STD 10, RFC 1870, November 1995.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[6] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
[7] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[8] Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
June 2000.
[9] Vaudreuil, G., "SMTP Service Extensions for Transmission of
Large and Binary MIME Messages", RFC 3030, December 2000.
[10] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[11] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC 3461,
January 2003.
[12] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 3462,
January 2003.
[13] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
January 2003.
Schmeing, et al. Expires February 24, 2007 [Page 23]
Internet-Draft Priority Extension for SMTP August 2006
[14] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 3464, January 2003.
[15] Schulzrinne, H., "Requirements for Resource Priority Mechanisms
for the Session Initiation Protocol (SIP)", RFC 3487,
February 2003.
[16] Schulzrinne, H. and J. Polk, "Communications Resource Priority
for the Session Initiation Protocol (SIP)", RFC 4412,
February 2006.
Schmeing, et al. Expires February 24, 2007 [Page 24]
Internet-Draft Priority Extension for SMTP August 2006
Authors' Addresses
Michael Schmeing
Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V.
Neuenahrer Strasse 20
Wachtberg 53343
DE
Phone: +49 228 9435 593
Email: schmeing@fgan.de
URI: http://www.fgan.de
Jan-Wilhelm Brendecke
Flerzheimer Strasse 36
Rheinbach 53359
DE
Phone: +49 2226 913760
Email: brendecke@gmx.de
Ken Carlberg
G11
123a Versailles Circle
Towson, MD
USA
Email: carlberg@g11.org.uk
Schmeing, et al. Expires February 24, 2007 [Page 25]
Internet-Draft Priority Extension for SMTP August 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schmeing, et al. Expires February 24, 2007 [Page 26]
