Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14

Ned Freed <> Mon, 04 June 2012 22:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E09521F86DB; Mon, 4 Jun 2012 15:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dUO3ufZx6qNI; Mon, 4 Jun 2012 15:13:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A04F721F8589; Mon, 4 Jun 2012 15:13:10 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <>; Mon, 4 Jun 2012 15:13:08 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <>; Mon, 4 Jun 2012 15:13:06 -0700 (PDT)
Message-id: <>
Date: Mon, 04 Jun 2012 14:47:39 -0700
From: Ned Freed <>
In-reply-to: "Your message dated Mon, 04 Jun 2012 22:15:25 +0200" <>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format="flowed"
References: <> <> <> <> <> <> <>
To: Dave Crocker <>
Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jun 2012 22:13:12 -0000

> Once again:  it is not reasonable to have different clients apply
> different semantics (policies) for choosing values.  The values need to
> have consistent meaning across the entire the trust environment that is
> supporting this mechanism.

> Otherwise, it won't work properly.

More precisely, it may "work" in some sense, but it may not deliver the results
you expect, which given what I understand the intended uses to be may be

OTOH, it may actually work very well, if for no other reason than most modern
mail systems are able to deliver messages in a matter of seconds most of the
time, which will make it difficult for a human user to observe any tangible
difference for different priorities.

And in practice since prioritization is very complex - to the point where, as
I've pointed out previously, the most obvious strategies may actually result in
increased latency, especially under high load conditions - so aligning behavior
across multiple implementations may prove to be a practical impossibility.

All that said, I am completly at a loss as to what, if anything, to do about
all of this. To nail down what prioritization means in an operational sense
requires a far more detailed model of how MSA/MTA/MDAs work than we currently
have. And I given what I know about the internals of various MTAs, I despair
of finding any sort of model that is simultaneously sufficiently general
and sufficiently accurate that we could even talk about this stuff sensibly.

There's a reason why every specification I've seen that mentions email
prioritization, going back as far as FIPS PUB 98 (RFC 841) and including X.400,
GOSIP, various LAN email systems, either omits entirely any description of what
priorization actually means or contains nothing but a bunch of handwaving.

> The environment will be left with individual clients taking more than
> their fair share. Or trying to.

> Absent very specific rules to be applied consistently across the trust
> environment, what is most likely is that every client will always claim
> top priority and no one will actually get it.  (This is a well-known
> phenomenon for this sort of game-theoretic condition.)

I have no good explanation for it, but the evidence I've seen says otherwise:
Quite a few existing systems support message prioritization, but I've yet to
encounter a case where everybody claims the top priority. (Users mostly seem to
ignore it, even when the controls for setting it are in plain view.) I rather
suspect it's a combination of factors: (1) As noted above, it has no observable
effect a lot of the time, (2) Interfaces rarely let average users bump the
default priority, meaning you have to do it every time, and (3) It can have
unwanted side effects, e.g., shortening timeouts, using up quotas, or enabling
generation of delivery receipts.