ietf-smtp
[Top] [All Lists]

Re: SMTP Service Extension for Priority

2001-06-27 12:15:19

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 
priorities.

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 terms
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