Re: Feedback on Hypertext Mail Protocol (a.k.a. Stub Email)

>So then perhaps the only benefit of IM2000 schemes over today's 
>situation is that you get to see the Subject/Sender/To of the email 
>before retrieving the entire email?

Not necessarily.  Some variants/proposals under the name "IM2000"
disallow arbitrary sender-provided information, such as "Subject",
since that *itself* can be spam/advocacy/junk.  Limits on sizes of
such things would be arbitrary (more likely to penalize legit users of
the fields, such as "Subject", than spammers); yet, having no such
limits would defeat the point of IM2000 in the first place (spammers
would just put the entire message in a "Subject" header, so it's part
of the notification -- I've already seen some SMTP spam that does
stuff like that!).

>If adoption is painless

It wouldn't be, so never mind that.

>and user 
>experience remains pretty much the same

It wouldn't be, unless and until we have a nearly 100% uptime,
low-latency, fat-pipe, universal Internet.  Even so, all users would
almost certainly experience at least slight increases in delays
between when they select a message for display and when it actually
gets displayed.

(That's even without imagining all sorts of decodings and validations,
never mind SpamAssassin-type analysis, that would presumably be
desirable to apply to the content prior to displaying it to the user.)

Prefetching/caching can mitigate those problems, but they'd also
eliminate the bandwidth-savings and diskspace-savings advantages of
IM2000; we might as well make more sophisticated use of SMTP, in order
to avoid generating bounces (which is, in fact, the approach I'm
working on -- a "Push"-style, bounceless approach, which SMTP can
accommodate somewhat more readily than "Pull"-style delivery).

>then that's still a 
>worthwhile benefit, isn't it?

A marginal one.  You can try it out by experimenting with an MUA
designed to show you just the Subject/Sender/To information of an
incoming email, for which the entire contents are already placed on
some other server, that your MUA would then fetch when you actually
went to read the email.

(That is, the bandwidth savings issue for the upstream SMTP servers is
orthagonal to how you, or a typical IM2000 user, would handle your
inbox.)

That might be what you're already doing now, except the message
contents aren't already on your local disk -- they are, at *best*, on,
say, an HTTP server elsewhere on your LAN.  (With IM2000, they're not
only "an HTTP server away", they're probably at least one DNS lookup
away, and DNS lookups can have unavoidable delays.)

>I know that's how I delete from my inbox 
>spam that the filter missed--I just look at the To/Subect, check the 
>boxes and hit "Delete". With IM2000 at least I won't have retrieved 
>the entire contents of those emails.

Again, if you can do that now, what would IM2000 actually save *you*?

>Also, my proposal for "HTMP with obfuscation" (outlined in comments 
>below my article) would dramatically increase bandwith costs for the 
>sender, which would really only effect spammers. Is that a worthwhile 
>benefit?
>
>Aren't these two benefits alone enough to justify the effort?

Probably not.

Reviewing materials available via a Google search for "IM2000
problems", it seems the biggest problems go largely unaddressed or at
least unspecified: that of being unable to read an important email in
your in-box because some *other* server, or the network connection to
it, are down; and, along similar lines, that of experiencing
noticeable delays in reading such emails, because of high latencies
between the MUA and the message server and/or a slow or broken DNS
that is called upon to find that server in the first place.

(Correspondingly, as an IM2000 message *sender*, you might "send" 40
messages while "online", then shut down your laptop, or go offline.
If you haven't shoveled the corresponding message *contents* to some
intermediate/upstream message store, then recipients of those message
notifications won't be able to read the contents until you come back
online -- a non-starter.  If you *have* so shoveled your content
upstream, you *and your message recipients* are using IM2000 pretty
much exactly as you're using SMTP *today*, in terms of mitigating
spam, using trusted intermediaries, etc., except the message
recipients would have the problems specified above vis-a-vis the
upstream message store that you're using.)

Those problems do not, generally speaking, happen with SMTP or other
"Push" systems, in which messages generally accompany notifications.
So as long as the connection is up at notification time, the message
is available locally when the *user* is actually ready to read it --
even if, at *that* point in time, the network connection is down
(offline reading, such as via a wireless device on an aircraft, in a
tunnel, etc.).

IMO, IM2000's "Pull"-style, bounceless delivery *must* be a choice
provided by any new, viable email system (whether it's a Not-So-Simple
Mail Transfer Protocol, aka NSSMTP, or something else ;-).  It has too
many advantages *in specific situations* to not provide it as an
option for exchanging messages.  (That is, if the sender of a message
is willing to "host" it somewhere, and a recipient is willing to
retrieve it later from the specified message store, a "new" email
system should allow them to cleanly negotiate that sort of
transaction.)

But, standing on its own, it isn't worth deploying as a *replacement*
for SMTP.  (If it was, we'd have done it by now.  It isn't
particularly hard to implement, and it's 2006, not 2000, after all.)

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