Subject: [Ieprep] Discussion of Internet-Draft for SMTP priorities

From: Michael Schmeing <[email-masked]>
Date: Mon, 12 Jun 2006 15:01:35 +0200

Hello all,

sorry it took so long for me to get back to you, but it has been a
very busy time. As there appears to be some interest in at least
discussing the draft, I will start by summarising Dan Wings´s input
(both his submissions to the list and his suggestions he made directly
to me) and give my view on these suggestions.

Dan´s first suggestion in his email directly to me was to use priority
levels 0, 100, 200, 300 and 400 instead of 0, 1, 2, 3 and 4. As the
length of the priority identifier is now limited to three digits, I
think that is a valid suggestion. I plan to include that in the next
version of the draft, unless someone can give good reasons to stick
with the old scheme or use a completely new one.

Another of Dan´s suggestions in that email was to use the IANA to
register the priority levels. He mentions that this would remove the
problem with the Priority: and Precedence: header fields where some
vendors use keywords and others (numerical) values.

I am not sure it is really required to register the priority levels
with IANA basically for two reasons:
1. The draft (and therefore the standard if it ever comes to that)
   defines the allowed value of the PRIORITY keyword to be only a
   numerical value. Thus the problem with the AFAIK not standardised
   header fields can not occur: Anyone conforming to the standard has
   to use numerical values according to the priority policy
   indicated. If anyone decides not to obey the standard, they would
   not care about IANA registration either.
2. The provided policy is only an example. Priority policy enforcement
   across administrative domain boundaries is difficult to say the
   least. For the general Internet, the most that I expect to be
   realistic is some form of Quality-of-Service, where Internet
   Providers would transport emails (or any other content) of some
   customers (which probably have to pay extra for this) more quickly
   than the traffic of other customers (keyword: net
   (non-)neutrality). They would define their own policy with their
   own priority levels for the use of email priorities, if they allow
   their customers to downgrade their service level on a
   per-email/per-connection basis.
If, on the other hand, the group feels that we should go for IANA
registration, that is fine with me. In that case, I would just ask
someone to provide a wording example for this, because I have never
done it yet.

A problem Dan mentions in his email to the mailing list is the problem
of authorisation. He asks the question of what will stop him from
using highest priority on all emails and says that it can be solved
within an administrative domain but probably not across them.

As I have already indicated above, I see this problem as well.

When I created the I-D, it was for a scenario of cooperating
administrative domains and thus, this problem did not present itself:
The domain administrations had agreed on a policy for the use of
priorities.

Of course, one thing preventing excessive use of high priorities is
the size limit on high-priority emails. You can not put much data in
two or four kilobyte, so you have to use lower priorities for larger
emails.

Other than that, I only have one rough idea so far how this issue
could be addressed in a general case that I would like your opinion
on: The policy could impose a frequency with which one sender may
issue emails of the higher priorities. Together with the smaller size
of high-priority emails that should guarantee at least some space for
lower priority emails

Best regards,
Michael Schmeing
-- 
****************************************************
| Michael Schmeing       E-Mail:  [email-masked] |
| FGAN/FKIE              Tel: (+49) 228/9435 593   |
| Neuenahrer Strasse 20  Fax: (+49) 228/9435 685   |
| D-53343 Wachtberg, Germany                       |
****************************************************

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 12 Jun 2006 14:07:22 -0400

I have a bunch of detailed comments, which I am still working on, but I
also have some high level questions/comments, which I will include here.

This ID clearly addresses a set of email requirements (not fully documented
here) tied to the US DoD.

While they haven't been set down yet, it is anticipated that there will be
a set of priority requirements for NS/EP (National Security and Emergency
Preparedness) email, which are likely to be somewhat different from the
military requirements.  And I expect there will be other requirements from
other parts of the world.

It would be nice if we had a more general solution, which could encompass a
variety of related but distinct requirements.

The SIP RPH (RFC4412) (on which the IEPREP WG had significant input) has a
more general structure which allows it to encompass both the (pre-emption
based) MLPP functionality and the (queuing based)GETS/WPS/ETS
functionality, by the use of (IANA registered) namespaces.

Is there a reason why we couldn't do something analogous for email?

Some of the specific areas where there might be  different requirements:

This draft focuses on “rapid delivery”  or “order of delivery” rather than
“high probability of delivery”.  In fact, it stipulates that, for some
priority levels, if the email cannot be delivered “with priority”, it
should be rejected (see section 6.5.7).  I can think of many situations
where it is better to continue with non-priority delivery than to reject an
email.

There might be circumstances in which "preemption" of  current email
transmissions is not desired, but "moving high priority emails to the front
of the queue" IS desirable.  It would be nice if the mechanism could
support both approaches.

I understand the rationale for limiting the size of the high priority
emails, but I can think of situations where other mechanisms might be a
more appropriate way to make sure that  the overall "high priority" volume
remains low.

Current implementations of  MLPP, eMLPP, WPS, and RPH use 0 to represent
the high priority group, with 1.2.3.4, etc representing successively lower
priorities.  What is the rationale for turning this upside down and using 0
to represent "non-priority"?

Why would the fact that a message is unclassified imply that it is lower
priority?  I don't see the correlation.

Thanks,

Janet

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Michael Schmeing <[email-masked]>
Date: Tue, 13 Jun 2006 07:52:06 +0200

> here) tied to the US DoD.

That is hardly surprising, since it was created during an ongoing
research project for the German MoD as I have already said.

> variety of related but distinct requirements.

Jan and I devided the I-D into two parts: A generic framwork and a
policy. The framework (which is the main part of the draft) should
allow for as much flexibility as possible. If there are restrictions
defined in that part, that are not necessary or are too specific, they
should be removed or rewritten.

The policy in Sec. 6.5 on the other hand is intended to be a concrete
example of some of the possibilities designers have when creating
their own policy. It is clearly inspired (and targeted) at the
Military Message Handling Systems (MMHS) of NATO as it stems from
there.

While the draft currently says this is the default policy, I have
since come to doubt whether the policy is really fit for general use
in the Internet. It may be a good idea to split the draft up into one
for the framework and one for an example policy.

> Is there a reason why we couldn't do something analogous for email?

I don´t know these standards so I don´t know if it is possible for
emails. But I think it should be.

> where it is better to continue with non-priority delivery than to reject an

As said above, Sec. 6.5 presents a specific policy. Give Jan´s and my
knowledge of military messaging, it seemed plausible that messages
with higher priority are as well of higher sensitivity. Therefore we
decided to split the defined priority levels up into the higher ones
which may not be transferred with non-priority and the lower ones
which may.

For other scenarios the reasoning may be different and the decission
may be another one. In this case, the applicable policy would just
have to define when to continue with non-priority (or just a lower
one?) and when to reject.

Please bear in mind that the given policy is not meant to be an
exhaustive example. You can make the algorithm deciding when to go
non-priority and when to reject or do something else as complex as you
like (or need to).

As the general default (in case the policy does not deal with this
topic), I feel that rejection is the right choice though. If you
deploy priorities you have a reason to and thus silently going
non-priority is probably not what you want.

> of the queue" IS desirable.  It would be nice if the mechanism could

Indeed it would. And it should be this way either (so I would be
thankfull for a suggestion of a better wording), but the final
decision whether to preempt or just move to the top of the queue
should by all means remain with the policy.

> more appropriate way to make sure that  the overall "high priority" volume

Agreed. But the actual size limitation is (again) only in the
policy. The framework just says that a size limitation is imposed, it
is to be respected (or at least that what it should read like).

In the military context, there are other means deployed, but we did
not want to make the policy too complex. One these means is that they
strictly limit the nature of messages that may be sent at highest
priority (AFAIK in Germany only the message that an enemy division or
corps has first been discovered may be sent at highest priority).

> to represent "non-priority"?

One of the conditions of the draft is that normal
(i.e. non-prioritiezed) email from the Internet can still be
handled. To achieve this, we need a unique way to identify such
emails. The only sensible options Jan and I could think of were either
to mandate that such emails MUST NOT have the priority keyword added
to the recipients or to define a fixed identifier. We decided on the
identifier approach because it was easier to implement.

Originally, the length of the identifier was unlimited. That meant
that 0 was the only number that was guaranteed not to punch a hole
into the series of priority levels defined by any policy conforming to
the framework.

As the length of the priority identifier has been limited to three
digits in the current version, it would be no problem to reverse the
semantics of identifier (i.e. make lower numbers denote higher
priorities). The non-priority would then be fixed to the value of 999.

> priority?  I don't see the correlation.

Neither do I. This is just an example of some constraints a policy may
impose that inlude considerations from a content oriented perspective.

> Janet

Thanks for the input,
Michael

---

From: ken carlberg <[email-masked]>
Date: Tue, 13 Jun 2006 11:58:48 -0400

Hello Michael,

I would like to echo Janet's request of putting in place a  
prioritization field that is more extendable so that various sets of  
users could rely on different priority structures/values, but more  
importantly, different associated policies.  The one major headache  
is that if you go down this road, I think your draft will require  
some significant changes.

Janet mentioned RFC4412, whose structure is a string based BNF  
representation.  If you would prefer a strictly numeric  
representation for the NameSpace.Value tuple first mentioned in  
RFC4412, you should look at NSIS QSPEC draft (which I believe is  
under WG last call)
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt.  In  
either case, you can leverage previous work and choose to do so  
either in alphanumeric or strictly numeric form and not have to worry  
about specifying your own IANA registry.

One minor point involves Section 4.1  You mention using the ToS field  
as a means of supporting expedited transfer.  Its probably best to  
update that text with RFC-3168, which deprecates ToS (and precedence  
fields) in favor of the Differentiated Services field.

Also, I would disagree with your statement that your proposed field  
does not "raise any security issues not already endemic in electronic  
mail".  Currently, with FIFO based system we have a system where  
everyone experiences a form of best effort in obtaining MTA  
resources.  But with your proposed extension, one introduces a case  
where email labeled as low priority can be indefinitely starved of  
resources.  In some systems/domains, this may be desired.  In others,  
one may want a more weighted round robin servicing so that priorities  
correlate to the weights, but eventually, all message queues would be  
serviced.  Outside of that, it would seem desirable for your draft to  
at least advocate some measures of security like S/MIME for header  
protection (rfc-3851), and possibly the use of AUTH.

Finally, in section 6.5.3, you state some specific delivery time  
constraints.  I'm curious as to where you came up with those numbers  
-- it would probably be helpful to add some context.  Some deployed  
underlying HF and ULF systems would have a hard time meeting your  
constraints depending on message size.  My personal feeling is that  
it may be best to move text like that and 4.1 into an appendix

outside of that, its a nice document for discussion

-ken

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 13 Jun 2006 12:08:41 -0700

coupling of possibly disparate efforts.

Michael,

Suggest you check out Common Alerting Protocol to avoid gratuitous
incompatabilities.  CAP is designed as a content framework (essentially
an XML-based data dictionary) for alerting.  E-mail is one, among many,
means of delivery of such information.  Here's the .sig from the
discussion list that should have plenty of pointers:

-------------

This list is for public discussion of the Common Alerting Protocol.
This list is NOT part of the formal record of the OASIS Emergency
Management TC.  Comments for the OASIS record should be posted using the
form at
http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
CAP-list mailing list
[email-masked]
http://eastpac.incident.com/mailman/listinfo/cap-list

This list is not for announcements, advertising or advocacy of any
particular program or product other than the CAP itself.

-------------

---

From: Michael Schmeing <[email-masked]>
Date: Wed, 14 Jun 2006 06:53:09 +0200

> Hello Michael,

Hello Ken,

this is just a quick answer to a couple of points I can respond to off
hand. I am going to give a more complete answer next week (I am out of
office starting tommorow until Monday including).

> [...]

There seems to be a lot of interest in a more flexible priority
field. While I am not at all opposed to this idea, I do not see that I
have the time available to me to do it.

> fields) in favor of the Differentiated Services field.

OK, that should be easy to fix.

> [...]
> Outside of that, it would seem desirable for your draft to at least
> advocate some measures of security like S/MIME for header protection
> (rfc-3851), and possibly the use of AUTH.

S/MIME is strictly for the content of the email. This area has been
left out of the draft because of reasons stemming from the research
project I work on. In the general case it is probably a good idea to
at least consider this area. As for AUTH, you are completedly right.

> -- it would probably be helpful to add some context.
>
> [...] 

Yes, it would. The times were inspired by the NATO time constraints
but shortened because NATO includes the time required for some
administrative actions before and after the actual
transmission. (E.g. waking the commander of a unit if the message
comes in the dead of the night ;-).

> outside of that, its a nice document for discussion

Then I have achieved a major goal of my research project already ;-) 

Michael

---

From: ken carlberg <[email-masked]>
Date: Wed, 14 Jun 2006 07:12:08 -0400

> office starting tommorow until Monday including).

hmmmm, planning to take some time off to see the next German football  
match? :-)
(just kidding)

> at least consider this area. As for AUTH, you are completedly right.

Section 3.1 of rfc-3851 has the following text...

    In order to protect outer, non-content related message headers (for
    instance, the "Subject", "To", "From" and "CC" fields), the sending
    client MAY wrap a full MIME message in a message/rfc822 wrapper in
    order to apply S/MIME security services to these headers.  It is up
    to the receiving client to decide how to present these "inner"
    headers along with the unprotected "outer" headers.

    When an S/MIME message is received, if the top-level protected MIME
    entity has a Content-Type of message/rfc822, it can be assumed that
    the intent was to provide header protection.  This entity SHOULD be
    presented as the top-level message, taking into account header
    merging issues as previously discussed.

I was under the impression that the above left the door open for S/ 
MIME to protect static parts of the SMTP header.  But admittedly, I'm  
not deeply familiar with the draft, so my apologies if I've  
misinterpreted things.

-ken

---

From: Michael Schmeing <[email-masked]>
Date: Wed, 14 Jun 2006 14:12:54 +0200

> not deeply familiar with the draft, so my apologies if I've  

To me, this appears rather to be a problem of different definitions of
the term content than a misinterpretation. I meant content as in
"message content" that is defined in Sec. 2.3.9 of RFC 2821 (SMTP) as
  "the material transmitted after the DATA command is accepted and
   before the end of data indication is transmitted.  Message content
   includes message headers and the ... message body."
In this definition the email header is part of the content. As such it
may be secured using S/MIME but still is outside the (current) scope
of the draft.

S/MIME obviously has a different definition of the term "content" that
only includes (parts of?) what is called "message body" but excludes
at least some header fields (probably those defined in RFCs
2821/2822).

Greetings,
Michael