It's worth noting that if you are looking to put this in a header,
sendmail has had such a thing for a long time in the form of the
Precedence: header. As I recall, it went in because someone in a
military environment had to have this feature. We can argue about
the implementation, but the goals were almost exactly as have been
described.
I didn't tie this in as an ESMTP extension or AUTH or any such
thing because it pre-dated ESMTP entirely, so none of that existed.
Precedence: is completely unsecured, and when I put it in I was
deeply sceptical about whether it would work (that is, if everyone
put in Precedence: 99 then it would be the same as everyone omitting
the header entirely). However, that hasn't proven to be much of a
problem, perhaps because the main parameter it impacts is queue
sorting, and with high bandwidth links most mail queues move "fast
enough" to keep users happy.
I don't think anyone has played with tying it to AUTH or restricting
queue processing to messages above a certain precedence.
eric
============= In Reply To: ===========================================
: From: ned+ietf-smtp(_at_)mrochek(_dot_)com
: Subject: Re: SMTP Service Extension for Priority
: Date: Wed, 27 Jun 2001 12:09:23 -0700 (PDT)
:
: > > > 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
: > > > priority.
: > >
: > > Not necessarily, but it may make sense as a default. So this could argue
: > > for a header field rather than against.
:
: > well, it forces MTAs to look at the message header, and IMHO we shouldn't
: > encourage this. but most do it anyway...
:
: > the purist in me doesn't like it. the pragmatist in me is almost
: > ambivalent about it.
:
: The purist in me doesn't like it either, but the pragmatist is way way way
: in favor of a new header field.
:
: > but if we accept that priority requires some kind of authenticaiton by
: > the sender, I do think it's in some sense cleaner if we get both the
: > authentication and the priority setting from the same protocol.
: > and I don't see how we can transmit the sender's authentication for
: > priority to servers other than the first hop without an SMTP extension
: > anyway. in other words, for submission SMTP AUTH might be sufficient,
: > but for relaying the sender's credentials to subsequent MTAs we're
: > going to need something new.
:
: I'm not sure it is a good idea, but we could use the AUTH parameter stuff for
: this. (In other words, we already have a mechanism for conveying
: authrization information across multiple hops.)
:
: > > (2) Don't split and process the recipients at the lower of the two priori
ties.
:
: > surely that would violate the notion that higher priority messages should
: > be treated as least as favorably as lower priority ones.
:
: Look at the phrasing you just used. You talked about higher priority
: *messages*, not *recipients*. I could easily argue that the priority of the
: *message* is that of the lowest priority recipient. Or the highest. Or an
: average.
:
: Regardless of how you word this, aren't people going to think of this in term
s
: of message priority, not recipient priority? And what's the interface for
: setting per-recipient priorities going to look like?
:
: > > And remember that when mapping to systems that only support per-message
: > > priority you'd be forced to split to retain the right semantics.
:
: > not clear. I think you could also comply by just giving the message
: > the same priority as that of the higest recipient.
:
: Not when other semantics are conveyed by priority setting, as they sometimes
: are in other environments.
:
: Ned