[Top] [All Lists]

Re: SMTP Service Extension for Priority

2001-06-27 12:08:51

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.

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.

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.

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.

this might be construed as a feature, particularly if they use PIPELINING.

Additionally, given that MTAs try to avoid splitting messages, it 
isn't at all clear how to handle the case of two recipients with 
different priorities that are travelling together. At a minimum 
some guidelines need to be given for this case.

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 
of ways:

(1) Split and process the two recipients independently. But this is wasteful
    of resources. 


(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.
(3) Don't split and process the recipients at the higher of the two 

that works.  nothing requires the MTA to give the lower priority recipient
pessimal treatment.

(4) Don't split and process the recipients at the average of the two

that also violates the notion that higher priority messages should
be treated as least as favorably as lower priority ones.

(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
    recipient delivered.

that could also work.
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 

so if you're still arguing that the document needs to give advice to 
implementors, I strongly agree.

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.