[Top] [All Lists]

Re: SMTP Service Extension for Priority

2001-07-09 12:42:46

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

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.


============= 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
: > 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
: 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

<Prev in Thread] Current Thread [Next in Thread>
  • Re: SMTP Service Extension for Priority, Eric Allman <=