Re: SPF is harmful. Adopt it.

Ah, a nice meaty example indeed!  I'll contrast it with the potentials
for existing SMTP protocol, extending the "ecosystem" that surrounds
it with mechanisms that largely parallel what IM2000 would require (or
at least imply) for IM2000 to be work as advertised.

>I am <[email protected]>.  I receive a notification that says, in essence,
>"you have message ID X waiting to be picked up from server
>foobar.example.com".

My SMTP server receives a delivery attempt.  It either temporarily
rejects it before, or after, the DATA phase; either way, it notifies
me in almost the exact same fashion, except the notification I receive
says, in essence, "you have message ID X waiting to be delivered again
by server foobar.example.com".

>The first time this happens, I'll likely do the
>following:
>
>1) Connect to the message store.

That'd be the local SMTP message store -- an important difference,
since it means that if the remote message store was temporarily
inaccessible, I'd be stuck (in IM2000-land, but not in SMTP-land).

On the other hand, my *local* message store would have to keep track
of delivery attempts in SMTP-land.  With IM2000, I gather, there'd be
no such need; it's really my local MUA that would keep track of these
(which it'd have to do to some extent anyway with SMTP improved along
these lines).

>2) Tell it to not send me any more notifications about message X.

Part and parcel of talking to the local SMTP message store above, I
would think.

Strictly speaking, this *request* might be *ignored* by an
uncooperative remote message store in IM2000-land, since it might
prefer to not try to track the preferences of each and every potential
email *recipient* for which it stores *outgoing* email, especially in
the cases of bulk outgoing email -- single emails with lots of
recipients.

So, whatever agent *receives* notifications on my behalf about message
X would also have to be told to ignore those.  Maybe that's akin to
the "local message store" in IM2000 land, or maybe it's just a job for
my MUA to ignore notifications that I've requested (presumably through
it) I not be delivered in the first place.

But I'm not sure this is an important distinguishing characteristic of
IM2000 versus SMTP's potential, so I'll just move along.

>3) Retrieve only the "summary" headers of the message (i.e. who it's from, the
>date, the subject, message-id:, and references:).

That can't be done in SMTP-land, as such.

But if my SMTP server waited until *after* the DATA phase to
temporarily reject a message, it would have as much of that message as
it wanted to store locally available for retrieval, whereas the sender
would still have to store and repeatedly try to deliver it.

(And, again, this can't be done at all in IM2000-land if the remote
message store is unavailable.  I know a message is waiting for me; I
just can't see it.  I think that'd be very frustrating.)

Now, temporarily rejecting SMTP messages has its risks of losing mail;
but so does shutting off incoming SMTP mail entirely, which I assume
would be inherent to adopting IM2000 sufficiently to gain all of its
advantages over SMTP.

>If, based on (3), the message looks like spam, the process ends here.
>Otherwise, I might retrieve the entire message.  Of course, it might still
>turn out to be spam.

Pretty much the same in SMTP-land.

>If this happens more than once, I'll likely instruct my notification agent to
>ignore notifications about messages on foobar.example.com, /regardless of
>where the notification comes from/.

Similarly, I'd likely instruct my SMTP server to permanently reject
incoming messages from foobar.example.com, regardless of relays
through which such messages passed.  (Parsing "Received:" headers is a
PITA, but it can be, and is, done.)

>IM2000 gives recipients total control.  That is it's power.

Without the clearer, cleaner divisions between message envelopes,
message contents, message deliveries, message-handling agents, and
message stores, SMTP-land doesn't offer recipients as much control.
No question about that.

Further, the mechanisms an SMTP-based system needs to imitiate the
above are more burdensome, from a resource-utilization point of view,
in most cases.  (An exception: senders need not serve up message
content in SMTP-land; they *must* do so in IM2000-land.  I'm nervous
about requiring more widespread server deployment -- given how poor
server deployment already is for SMTP, DNS, HTTP, and the like -- just
to *send* messages.  Seems like it introduces another major "point of
failure", in that, with IM2000, both the sender *and* the recipient of
an email must have working message-exchange servers.)

What SMTP-land *does* offer is a fairly straightforward means to
implement much of this power *now*, on pretty much an ad-hoc basis (by
which I mean *recipients* and their local SMTP servers can choose to
implement these mechanisms without having to convince *senders* of
legitimate email -- email they want to receieve -- to change much of
anything that they're already doing).

And note that this scenario, designed to favor IM2000, assumes that
readers of email will be willing and/or able to take some extra steps
when it comes to reading email, such as clicking an "obtain just the
headers" button, waiting for remote retrieval, reading what comes
back, then clicking "obtain the whole message" button, waiting for
remote retrieval, reading what comes back, then clicking "this is
spam, I really didn't want to see it".

Whereas, today, most people aren't clicking *any* of those buttons,
except insofar as one might view the "delete" button as implicit to
the final "this is spam, I really didn't want to see it" button in the
IM2000 case.

I've learned to be very cautious about assuming widespread willingness
of end users to a) learn new interfaces, b) use them to be more
precise in feeding back, to their computer (MUA here), what they think
about what they're seeing, and c) do so in a manner that's
sufficiently accurate and precise that the result is constructive, not
destructive (it filters out undesired email without collateral damage
such as filtering out desired email).

So I'd be interested in seeing any discussion of how IM2000 rollout
would play, given *today's* user base, which should be presumed to
behave almost exactly as users have long behaved: scroll down the
one-line notices of incoming email, look at each email's content as it
comes up (which they're used to it doing, *fast*), then either
skipping each email, clicking on "delete", or clicking on "save to
some folder".

Since clicking on "delete" wouldn't mean the same thing as "this is
spam", how would IM2000 help these users, aside from indirectly?


So, after posting my long response to JdBP's response to my earlier
email on this list, I thought through what I was saying, and think
I've boiled down my concerns about IM2000 as a *protocol* to the
following point:

  With IM2000, the network is the in-box.

Sounds like a good slogan, and it's really just another take on what
JdBP had said.

But it's intentionally reworked to sound like the following
widely-published slogan:

  The network is the computer.

Remember that?  The idea being, if we just ran (say, Java-enabled)
network computers that had little or no local storage, no running of
arbitrary external code in native mode (to dispense with vermin), and
instead used upstream facilities to do all our computing, all sorts of
existing problems would be *solved*, "overnight".

But without super-reliable, high-bandwidth connections to address
technology issues, and various sociopolitical arrangements to address
accountability and related issues, "the network is the computer"
failed to deliver on its promise.  (Or maybe I'm just unaware of the
extent to which it *has*?)

I'm not sure I can see how IM2000 will avoid becoming just another
technology that is rejected by the masses for just this reason.

And, to the extent it *is* deployed and people work around this issue
by having their incoming-message notification agents automatically
retrieve messages from the remote message stores, a fundamental
advantage of IM2000 over SMTP is defeated by its own end users,
correct?


Now, my concerns about IM2000 as an anti-UBM measure revolve primarily
around my having been "educated" (clue-by-foured, some might say ;-)
on the qmail list and elsewhere about the willingness and ability of
UBM senders to work around almost anything that stands in their way.
(I've been criticized for "advocating", even "inventing", Greylisting,
on this basis -- "spammers will just deliver twice, or as often as
needed" -- though I certainly did not invent or propose Greylisting.)

In particular, if requiring senders to store and serve outgoing
messages is supposed to be a another big advantage of IM2000, and my
previously-posted "guess" about the direction of the costs associated
with that activity is essentially correct, then perhaps JdBP's and
other's statements about IM2000 will have to be augmented thusly:

  IM2000 is an idea whose time has come...and gone.

It might simply be too late to take sufficient advantage of IM2000's
distinguishing features to justify its rollout as an effective
deterrent to UBM and/or its associated expenses for recipients of
email.


I am *guessing* that IM2000 rollout is a better utilization of
resources than rolling out C/R or SPF; however, given my opinions
regarding those technologies, that isn't saying a whole lot, even if
my guess is correct!

I'd prefer we think in terms of a more-flexible messaging architecture
that might *include* IM2000, or an approximation thereof, as well as
SMTP-style delivery, as options that senders, recipients, and
intermediaries can choose among and agree to on a per-message-delivery
basis or on coarser-grained levels, at their convenience.

In essence, I think an important component of any transaction, one
that should be made more *explicit*, at least as an option, is the
"resources to be used" component.  So each SMTP delivery includes an
implicit "this message will use the recipient's SMTP server for its
message store", while each IM2000 notification includes an implicit
"this message will stay in the sender's message store for now".

Why not create a protocol that allows for *each* message notification
to include an optional resource identifier?  "I'm willing to store and
later serve this message", or "I want you to store this message", or
"I'll pay you $.05 to store this message", or "You'll pay me $.10 to
store and later server this message, plus $.01 for each time you
request it without accepting responsibility for it", etc.

Why not also create a protocol that allows email recipients to publish
their criteria for accepting messages, including resource requirements
with which they are or are not comfortable, as well as protocols
(SMTP, IM2000, direct delivery via this sort of uber-protocol) they
support for message notification and/or delivery?

Why not also take certain other steps that could cut spammers,
especially spamware authors, off at the knees, and/or cut off their
air supply?  Again, IM2000 could be one *component* of this, but it
would be seen as just one of several notification and delivery
options.


So I don't really mind if IM2000 *is* deployed.  (I'm grateful it
looks less and less like C/R will be, as was being "threatened" as of
a few months ago; unlike with IM2000, I came to actively *worry* about
widespread deployment of C/R, and am beginning to do so about SPF.)

I just don't think people should get too excited about IM2000's
distinguishing features without really thinking through how they'll
work in practice.

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>