Hmm. Doesn't this argue that an SMTP extension is the wrong mechanism?
A priority specification can be propogated in a header field end to end
even if intermediate MTAs don't support it. If you use an extension for
this all the intermediaries have to support it.
yeah, it's a tradeoff. priority is definitely an MTA function, and for
the past few years we've been fairly strict about requiring that MTA
protocol be transmitted in SMTP. also, if a message is resent then
it will keep the same headers but should not necessarily keep the same
Not necessarily, but it may make sense as a default. So this could argue
for a header field rather than against.
The counter is that in order for this to be recipient-specific it has to
be an SMTP extension.
and that's another point.
the other point that comes to mind is that if a UA doesn't submit
a message via SMTP (or SUBMISSION) then it doesn't have a good way to
set delivery priority unless it's via a message header.
Yes, and this proved to be a significant obstacle to actual use of NOTARY.
Indeed, several MUAs switched to using SMTP for submission because they got
tired of waiting for other submission mechanisms to be extended.
and if the purpose of priority is to make better use of limited resources
then you want to be able to set it on a per-message basis, not have it
derived from the sender or recipient address and MTA-local rules.
Additionally, given that MTAs try to avoid splitting messages, it isn't at
clear how to handle the case of two recipients with different priorities
are travelling together. At a minimum some guidelines need to be given for
I'm not sure how this is very different than an MTA that tries to relay
a message to two recipients at the same server (or at different servers),
and RCPT gets a 200 reply for one recipient and a 400 reply for another.
The message doesn't get "split" but one recipient in the envelope
is marked as delivered and another one is marked "try again later".
I think you're missing my point. Suppose I have two recipients,
at priority 1 and b(_at_)d(_dot_)com at priority 99. I could handle this in a
(1) Split and process the two recipients independently. But this is wasteful
of resources. Additionally, it may lead to unnecessary violations of the
astonishment principle. Suppose I implement retries for different
priorities differently, 1 gets retried every hour and 99 gets retried
every 10 minutes, and they aren't synchronized. But suppose the d.com is
down and happens to come back up for just an instant just as the hourly
(2) Don't split and process the recipients at the lower of the two priorities.
(3) Don't split and process the recipients at the higher of the two priorities.
(4) Don't split and process the recipients at the average of the two
(5) Don't split initially and retry at the rates implied by both priorities,
but split if the retry was one only intended to get the high priority
I'm sure many other variations are possible as well.
And I don't think there's any requirement that messages with lower priority
be given worse treatment than a message with high priority. So an MTA
that treated every recipient as if it had the priority of the highest-priority
recipient in that envelope would still be conforming (if somewhat pessimal).
Certainly if I could relay the message to other lower priority recipients
in the same transaction as a higher priority recipient, I'd do that.
That's certainly the way I'd implement it. But I suspect others would disagree.
And remember that when mapping to systems that only support per-message
priority you'd be forced to split to retain the right semantics.