ietf-smtp
[Top] [All Lists]

Re: SMTP Service Extension for Priority

2001-06-26 05:52:50

--On Tuesday, 26 June, 2001 08:44 -0400 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:

It seems to me that there are two important cases here:

* The MTAs of concern are under the control of either the
sender or the receiver.  In this case, the "guessing game" is
no worse than the one that is played with every message: you
need to guess what "from:" and "subject" lines, and envelope
address to use to maximize the chance that I will read your
mail or, put differently, which ones to avoid to minimize the
chance that I will delete it without reading (or have agents
or filters do that for me).

I guess I disagree - first of all, we don't usually expect to
guess "From".

But people who discover that they are being filtered on
particular From: patterns do just that.

 We do have to choose a subject, but that choice
is informed by our vast experience in communicating between 
human beings  with words.  Priority is less obvious, and it
adds another dimension.  And if we're just making a facility
for filtering by the sender or receiver, an Importance header
works just as well (are we really going to set this separately
on a per-recipient basis?)

Whether a header is appropriate depends on whether you expect
the filtering/ classification to be done by the delivery MTA (or
a trusted/designated intermediate one) or the MUA and about how
you feel about layering violations.   One probably would not set
it on a per-recipient basis (although I can see setting
different priorities for each of the To, CC, and Bcc
recipients).  But, as a recipient, I'd certainly like to be able
to adjust incoming priorities differentially from different (and
frequent) senders.

* The MTAs making the decision are "in the middle", and not
under the control of either sender or recipient, or anyone
both accept as an appropriate intervening authority.   That
scenario is basically equivalent to all of the other
interception objects on the network (what you think about
those is well-established; let's not have the discussion here
again), but with one major difference -- there will be no
intermediate MTAs doing stupid things out of ignorance of the
protocol, since a priority parameter cannot be sent to any
MTA that does not advertise it. That is a small advantage for
this case, although perhaps a trivially small one.

I guess I don't consider things to be interception objects
unless they actually intercept traffic, and an MTA doesn't
qualify.

My question is - why is it useful for Internet mail users to 
allow/encourage intermediate MTAs to do arbitrary filtering 
based on an unauthenticated priority?

Strawman.  I've already agreed that the facility is dubious
without authentication and at least suggested that I'd want any
filtering intermediates to do so with explicit authorization
from the recipient, which ought to be sufficient to eliminate
"arbitrary" as a case.

In other words - I do think a priority facility could be
useful, but I think we're missing some significant pieces from
the current design that would be required to make it useful.

Absolutely.  I think I said that in my initial note.  And, while
I think I've got some ideas about what is needed, it is clear to
me that this draft, in its current form, isn't it.

And I'm not quite sure what pieces are missing, or whether
it's feasible to supply them.

     john