Re: Inexpensive anti-spamware/anti-verminware tactic

>JR> Yeah, users'll be *real* happy about being told "you can't send
>JR> any more mail to anyone until some of the people you mailed in 
>JR> the past delete it, maybe you could ring them all up and ask 
>JR> them nicely".
>
>That's a mischaracterisation and a straw man.  Read the proposals.

Well, it's true a sender can just cancel outgoing email, but, as I
pointed out in an email I just sent, IM2000 could also allow him to
*schedule* (at delivery or subsequently) cancelation of a message from
the store, with due notification to recipients, whose MUAs would
presumably urge them to make decisions about their in-box in some sort
of priority fashion.

And it might even make sense to provide a protocol for recipients to
request restoration of outgoing messages, since senders might have
local copies they could "restore" to outgoing message stores for which
they pay, so there might as well be some nifty, easy-to-use protocol
to express that.  (It'd be quite a compliment, as a sender, for me to
get a notification via my MUA that "so-and-so really wants to see
<this message> restored so he can save it, because he [loved it when
he first read it but forgot to save it|heard it was an instant classic
when sent to a list but was on vacation|whatever]".)

But there's no getting around the fact that, with IM2000, as long as
it offers only pull-style delivery, lack of access to an outgoing
message store (whether due to lack of $$, short-term network
unavailability, or lack of extra disk space) means no ability to
*send* email.

That represents a new, and extra, point of failure in the IM2000
(pull) paradigm over the SMTP (push) paradigm, architecturally
speaking -- though site-specific anti-UBM measures impinge
substantially on this difference at the moment, the question being
will similar measures restricting the range of useful outgoing message
stores impinge substantially on *their* overall reliability.

Similarly, a disappearing in-box message represents a new phenomenon
with which people will have little or no experience, for which it is
hard to predict their range of responses.  It's a new point of failure
for *incoming* email, in other words.

But the *real* question is, will the improvements IM2000 (pull
paradigm) offers to the message-recipient side of the equation (the
equivalent to SMTP servers and whatever's downstream of that) more
than make up for whatever downsides exist by requiring access to
outgoing message stores (as well as everything else common to IM2000
and SMTP) to send email?

And this really highlights a potential problem with my suggestion that
IM2000 include a per-message negotiation of push vs. pull for
delivery, namely...

...does the flexibility of offering push vs. pull include too much of
a sacrifice of reliability to make *that* sort of system worth
offering?  That is, if IM2000 incorporated push-style delivery as an
option, would it become sufficiently complex that it wouldn't succeed
as well as would IM2000 as a pull-only system?

I'm viewing this whole thing in terms of complexity management, and
many of these proposals, discussions, questions, answers, arguments,
and counter-arguments are almost akin to playing whack-a-mole with
various aspects of the true complexity of exchanging messages.

The hurdle IM2000 has to jump isn't just to show that an IM2000
environment has lower *additional* complexity over the complexity
inherent in exchanging messages, compared to SMTP; it's got to show
that it has *sufficiently* lower additional complexity to be worth the
expense of deployment (which itself will be a highly-complex
undertaking, regardless of whether SMTP compatibility is offered or
withheld).

(Please understand my definition of "complexity" here goes well beyond
the complexity of the IM2000 architecture, design, and/or
implementation: it includes admins, users, legal issues, the realities
of being deployed on a hostile network, and so on.  Those areas are
what contribute substantially to the complexity of the SMTP ecosystem,
after all; push-style delivery, even via the baggage-laden SMTP
protocol, is fairly simple, and qmail-1.03 illustrates just how simple
an implementation of it can be and still work in the wild.)

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