[Ieprep] Discussion of Internet-Draft for SMTP priorities

Michael Schmeing <schmeing@fgan.de> Mon, 12 June 2006 13:11 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpmCm-0003qQ-2q; Mon, 12 Jun 2006 09:11:44 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpmCk-0003lC-Do for ieprep@ietf.org; Mon, 12 Jun 2006 09:11:42 -0400
Received: from mailguard.fgan.de ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpm30-0007RL-Lk for ieprep@ietf.org; Mon, 12 Jun 2006 09:01:41 -0400
Received: from rufsun5.fkie.fgan.de ([] helo=mailhost.fgan.de) by mailguard.fgan.de with smtp (Exim 4.50) id 1Fpm2z-0007nQ-BD for ieprep@ietf.org; Mon, 12 Jun 2006 15:01:37 +0200
Received: from nordhorn.fkie.fgan.de ([]) by mailhost.fgan.de with smtp (Exim 3.36 #5 (Solaris)) id 1Fpm2y-0004n6-00 for <ieprep@ietf.org>; Mon, 12 Jun 2006 15:01:36 +0200
Received: by nordhorn.fkie.fgan.de (sSMTP sendmail emulation); Mon, 12 Jun 2006 15:01:35 +0200
Date: Mon, 12 Jun 2006 15:01:35 +0200
From: Michael Schmeing <schmeing@fgan.de>
To: ieprep@ietf.org
Message-ID: <20060612130135.GD9821@nordhorn.fkie.fgan.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Organization: Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V. (FGAN)
User-Agent: Mutt/1.5.11+cvs20060403
X-Virus-Scanned: yes (FGAN VirusScan III)
X-Scan-Signature: d2cf15bdfe212a5b41ac9f74731b6b74
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Subject: [Ieprep] Discussion of Internet-Draft for SMTP priorities
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org

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

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

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:  schmeing@fgan.de |
| FGAN/FKIE              Tel: (+49) 228/9435 593   |
| Neuenahrer Strasse 20  Fax: (+49) 228/9435 685   |
| D-53343 Wachtberg, Germany                       |

Ieprep mailing list