ietf-smtp
[Top] [All Lists]

Re: SMTP Service Extension for Priority

2001-06-25 11:36:17

Keith,

I agree about the authentication issues.

That said, I have believed for years that senders ought to be
able to assert their opinion of the importance of a message they
are sending, and that receipients should be able filter and
assign actions based on that information, with the understanding
that the filters could apply the recipient's prior opinion of
the priority-settings of the sender.  I.e., if you set a
priority of "5" (whatever that means), I ought to be able to
have filters structured so that I can assert (unbeknown to you)
that I think you always understimate so that any priority you
specify should be boosted by 10% (or according to some more
complex function).  Similarly, I ought to be able to downgrade
the priority assignments of selected others (in the limiting
case, setting all of someone's priorities to zero might be
equivalent to routing their mail to the bitbucket... or it might
now) and to specify handling of messages with unassigned
priorities or unauthenticated senders.  The draft seems to
anticipate some of this, since "may silently downgrade..." is
present as an option.

Note that in this scenario, the authorization issue --
"verification of the sender's privilege to set that priority" in
your words --would not apply: senders could make any assertions
they wished, at the risk of undermining their credibility with
the recipient and having their priorities generally downgraded.

However, it is not clear that the proposal is the optimal way to
provide the information I'm looking for, especially since my
scenario doesn't assume that the priority settings would
influence the behavior of any MTA other than the last one, if
that.  But the implied layering issue is subtle.  E.g., the
draft specifies that the mechanism could be used for early
refusal of some messages.   I would consider it entirely
appropriate for an receiving (final delivery) MTA, acting on my
behalf, to reject a message a RCPT time whose posterior priority
was such that there was no chance I wanted to look at it, ever.
Of course, this would have no impact on any intermediate MTAs
unless, through some capability negotiation, I could propagate
my prior preferences backward toward the sender.

FWIW, I'm not comfortable about the notion of an SMTP extension
that seems to imply utility only for a restricted community
inventing new primary reply codes.   Use of a code in the RFC
1893 style would seem far more attractive, especially since both
client and server would need to understand the priority
extension for the proposed error statuses to arise.

   john

--On Monday, 25 June, 2001 13:37 -0400 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:


Appreciate any comments,

Basically I think a mechanism such as this is useless w/o
requiring  authentication of the sender (which could be done
by SMTP AUTH) and  verification of the sender's privilege to
set that priority.   And that only works for the first hop.  I
think we would also need some  sort of model for determining
priority of messages on subsequent hops -  based on either the
...