At 03:54 AM 6/29/2001, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
>Would you favor/suggest that this be re-cast as an option for message
>posting?
The current proposal is for SMTP.
And SMTP is the basis for the one submission (posting) protocol we have (RFC
276). "Recast" is therefore a bit of a stretch -- it is simply a matter of
profiling where the extension is (or is not) to be used.
The way that a posting user gets to
specify an SMTP option is a human factors issue that outside the scope of
the IETF (unless we also decide that the information should be encoded in
RFC 2822 headers.)
On the contrary, posting is a standardized function based on SMTP. And this is
true both in theory and in practice -- various posting APIs failed to pick up
NOTARY support in a timely fashion so many if not most MUAs elected to
transition to SMTP as means of submitting messages.
Now, none of this implies that priority cannot be carried in a header. It can
be, although I will argue below that it should not be. But not because only
headers are available as part of a posting mechanism. That's simply not the
case.
> > 1. As stated, the option leaves senders with an incentive to always
> > set high priority. It costs them nothing to do this.
> Even if you assume this is true (past experience with priority facilities
> indicates it is not),
The past experience you have been citing pertains to LOWER priority. That
is quite different from one which includes HIGHER priority.
Only one instance of past experience pertains to LOWER priority. Other
instances pertain to higher priority, and there has been no indication of
substantial abuse.
One more time: For a service that imposes no costs on the requester, the
incentive is to always ask for higher priority. As I noted, we have well
seen that the Internet is now under the strong influence of selfish
actors. They do not participate as good neighbors. That is the reason we
needed a major generational upgrade to router queuing and it is the reason
that the proposed mechanism, here, suffers scaling limitations for the open
Internet.
One more time: Past experience directly contradicts this (IMO overly
simplistic) assessment.
I've tried to avoid making behavioral predictions since we're collectively
pretty bad at it, but I cannot resist the temptation any longer. So here's an
alternative analysis of spammer behavior that predicts an entirely different
outcome.
The goal of spammers is to get as many of their messages through to end users
as possible. Period. We're all well aware that other concerns like use of
resources that belong to other people are ignored by these people.
But consider what this means for a moment. It means that quality of service
facilities like priority aren't all that interesting to a spammer. Indeed, the
goal of spammers these days is to have their mail look as normal as possible --
anything that stands out, like a flood of mail from a single source all marked
priority urgent, is a sign of spam and is likely to be used as a means of
filtering mail.
It used to be that spam mail stood out like a sore thumb. Bogus return
addresses, missing required header fields, and other telltales were the norm.
But as filter sophistication has increased so have the techniques spammers use.
Yes, there's still a residual amount of spam that's sent by clueless spammers
using older tools and which carries such telltales, but ask anyone who build
spam filters and you'll find out that filtering is getting harder and harder
over time.
In fact there's nothing I would like better than for all the spammers to start
using the highest possible priority to label their messages. Priority
labelling used as a honeypot, in other words. But unlike you, I doubt they are
that stupid. (Actually, the individual actors probably are that stupid. But the
people who write the tools they use are not. They'll see priority for what it
is -- a potential telltale -- and avoid it.)
However, this discussion does lead me to conclude that priority is best done as
an SMTP extension. Why? Because there are still a lot of open relays out there,
and an open relay will pass through any header priority field we add unchanged.
In contrast, an open relay is usually some system running an old mail system
without relay blocking and that old system isn't going to support any new
priority extension. And if it gets upgraded to support it support for relay
blocking will inevitably come along for the ride. So if we deploy a priority
extension we can be reasonably sure that use of it is unlikely to come from an
open relay -- it will either be a legitimate system sending legitimate mail or
a spammer sending spam directly. And this makes all sorts of approaches
possible: Statistical analysis, quotas on high priority messages, and so on.
> > 2. References to usage of SMTP Auth with this option are confusing,
> > since it is used for posting, not relaying. I'd appreciate
> > clarification to this point.
> Read the spec. SMTP AUTH not only provides facility for posting, it also
> provides facilities for relaying authentication credentials.
As with most security topics, the difference between specification and
practise are significant. Do you really expect that relaying across the
open Internet will require use of SMTP Auth? In which century?
Nobody said anything about requiring it for relaying across the open Internet.
Using it as means of facilitating the use of extensions like priority
is another matter.
What will be the incentives that will cause people to adopt such a
considerable mechanism?
(There is an argument that opt-in volume mailers, and ISPs receiving their
bulk postings, might like to use a certified channel. This would permit
distinguish the Good Bulk mail from the Bad Bulk Mail. That argument has
so far proved unpersuasive to ISPs.)
I'm going to turn one of your own arguments back on you here. You like making
analogies to lower layers. Well, one of the things that happens all the time is
private bilateral agreements between service providers to provide improved QoS
or enhanced types of service between their respective customer bases. (Don't
bother to ask for details of such things because I don't know any. I only know
there are lots of such agreements in place, and I also know that they are
routinely coupled to extremely draconian nondisclosure agreements. Attempts to
make realistic assessments of the number and effect of such agreements have
been made, and they were met with "what have you been smoking" responses from
the people who know about them.) At present there's no reason to do anything
similar based on SMTP AUTH because there aren't any facilities tied to its use.
But if there were, who's to say it would not happen?
> I have no clear idea what "increase predictability" means, but I'm pretty
> sure that nobody views priority as a means to achieve that end.
If my request for special handling (priority) carries no expectation of
what actual handling will take place, then the option is entirely
useless. If it does correlate with actual handling, then I had better have
better knowledge about the delivery behavior of my message than I had
without the option. That constitutes increased predictability. That is
what quality of service work is about.
In other words, Dan Chaney's interpretation is accurate.
And actual experience disproves this line of reasoning completely. People will
use such facilities even without even a scintilla of evidence of their
efficacy. This is why I find the arguments made in the FAX WG relating to the
unreliable nature of MDNs to be unpersuasive -- I know otherwise from direct
experience.
> > 4. The IETF does not do intranet standards.
> Actually, the IETF does intranet standards all the time. This is especially
> true if you equate administrative domains with intranets. By this rule POP3,
> IMAP4 and SMTP submit are all intranet protocols that don't scale to the
> entire Internet.
All of those protocols work quite well over the open Internet just
fine. There is nothing about them that requires constraints on the
operational network.
(I suppose one might claim that a login identification technique is the
contradiction but then we would have to claim that all web mechanisms that
require identification are intranet-limited.)
No, what we conclude is that the notion of the IETF not doing intranet
standards is complete hooey now and always has been. The most that can be said
is that we try to build protocols that are capable of being used on the big-I
Internet and are not restricted to intranets. And we don't always succeed even
at that. (The best example of this is the service location protocol, which
required a broadcast service to operate. And if you want some real fun you
should sample what's happening now in the storage-over-IP camp.)
And priority is definitely an example of a protocol that can be used on the
big-I Internet.
My point about being limited to an intranet is not about constraints on an
end-point. It is about being limited to an operational infrastructure that
has significant dependence on a single, coherent administrative
control. POP, IMAP and Submit have not such dependence.
Dave, you have seriously taken leave of your senses if you believe this to be
the case. Excluding the insignificant case of anonymous logins, all of these
protocls require authentication, and authentication requires administative
coordination. And I don't think a gloal authentication infrastructure deployed
when I wasn't looking.
The proposed
priority mechanism does, unless and until the rest of the system
specification is provided, and controls are provided to distinguish
authorized high priority users from unauthorized.
Even if I grant this point, the degree of authorization is no different than
that needed for using the protocols you listed. And not only are MTA authors
used to tying the ability to do various things to authentication state, we're
getting good at it.
Ned