Re: Hello from a new subscriber was Re: Just Wondering...

>James Craig Burley <[email protected]> writes:
>
>>   "Sure is quiet out there."
>>
>>   "Yeah, too quiet."
>>
>> (Or did I unsubscribe myself from the list and not remember doing it?
>> Can't seem to find an up-to-date archive....)
>
>I just subscribed, haven't been able to find an archive either, and didn't
>really want to request the messages one at a time. If there is an archive, I'd
>like to have the link.

Me too.  Maybe I'll put my own archives of im2000 (mostly saved just
my own) up on my web site someday.

>In short, Only send 80 char max notifications, and make the sender keep the
>email on their own server for the receiver to go get by himself.

JdBP sez "no covert channels", other than that, you're describing a
"pull" system, which is one of the main distinguishing features of
im2000.

>The problem with spam is that once it's in the system, it's totally trusted,
>and the system bears the cost of transport and storage.
>If you shift the cost to the sender, spam won't be economically viable.

That remains to be seen; wish the im2000 discussions on this were
available!  But it is generally agreed that there is no real way to
stop UCE (spam), UBE (which includes political and other advocacy), or
vermin (viruses, trojan horses, worms), so slowing it down by making
sending bulk mail to recipients who are *generally* uninterested in
reading it seems a reasonable way to target the problem.

So you're still on the im2000 track here.

>If spammers have to hold spam on their own servers, the servers will quickly be
>found out and blacklisted.

That's a big "if"; spammers can exploit hijacked machines (zombies),
which is how lots of UCE and vermin get distributed *today*.

>The greatest benefit is that real geeks like us will shutdown or blacklist spam
>server before grandma and joe q. public do their weekly email check.

Perhaps.  It's not clear this can't be done with the present system,
by simply deleting locally stored (push-style-delivery, or SMTP) email
that meets criteria for newly discovered UCE/UBE/vermin sources,
post-delivery.

In particular, how a site gets onto any blacklist seems to depend
mightily on *somebody* retrieving a message stored on that site and
deciding it's UCE, UBE, or vermin, and that somebody somehow
convincing a blacklist manager to take action based on their claim.

Since those are currently among the weakest points of today's
push-style (SMTP) system, I remain unconvinced im2000 will make for a
substantial improvement in this area.

>Q: What about Spammed Notifications?
>A: will still be an improvement over full spam emails, and takes a lot less
>   time to download.

Yup.  However, spammers and vermin authors will soon learn how to make
up 80-character subject lines (assuming your model) that are very
convincing.  People (and their MUAs) will ultimately have to base
their decisions on the sender and recipient addresses, plus attributes
of delivery such as injecting system (today's SMTP client), message
store (today's SMTP relay), and very little else.

Based on all that, if they don't reliably detect spam "often enough"
before fetching the message, im2000 has not only failed them in its
most distinguishing pull-style characteristic, it has made the entire
transaction more expensive (than a new push-style system, if not than
SMTP itself) for pretty much everybody.

>Q: Will mailing list servers require lots of extra space?
>A: not if you consider them mailing list archives as well.

A big plus IMO.  JdBP covers mailing lists on his web site.

>Q: How does this work for the average user that has an account with an ISP?
>A: You send your email to your ISP via SMTP, just as always. Your email remains
>   there on the server, and the server sends a notification to the final
>   destination. The final destination then chooses when it wants to pick up the
>   mail from the ISP's server.

That's im2000 all right.

>As for receiving email, your client will need to pick up from many different
>POP3 servers, rather than just picking up from one as now.

Not necessarily POP3 servers, perhaps not even possible with them, not
sure offhand.  Surely shims could work, but whether these would have
to be im2000->shim->SMTP->POP3, I don't know offhand.

>A Spammer registers an account with an ISP, and sends lots of Spam.
>Result: That spam remains on the server until the spammer uses up their storage
>quota and flags the sysadmin (who should immediately kill the account and any
>non-picked up spam)
>Or the public blacklists list the user@host once the first few spams have been
>picked up, and that user@host is not accepted by clients that check blacklists.
>
>A spammer sets up their own server, and sends lots of Spam.
>Result: the server is listed in the public blacklists, and is not accepted by
>clients that check blacklists.

These two aren't necessarily all that different from what can be (and
often is, on an ad-hoc basis) done today.

>A spammer tries to forge an email sender.
>Result: your client can't pick up an email from a server that doesn't exist. 

That's a big advantage of im2000.  Although, I think you mean "tries
to forge an outgoing message store"; im2000 per se doesn't really
"care" about the identity of an email *sender*, or does it?

The potentially-big disadvantages of im2000 include:

  -  So many people accustomed to "instant" message-content
     availability that there will be widespread configuring of local
     message agents to automatically transfer incoming messages to
     local stores anyway.  Spammers won't have to pay after all.

     (If the transfers are cache, or prefetch-style, then the messages
     stay in two places at once.  That punishes spammers more, but
     punishes end users just as much as SMTP.)

  -  Adoption requires SMTP compatibility (JdBP's "shims", I think he
     calls them), but breaks a crucial SMTP feature, namely, bounces.

     IMO if "we" are allowed to "break" SMTP's bounce feature, why
     don't we just do that *now* and see how it goes?  We'd save $$$$$
     on all the joe jobs out there as the breakage is implemented, in
     favor of sender-side polling or success-only notification or
     whatever.

  -  For true pull-style delivery to work, system must basically
     assume no DNS caching is available or will work consistently,
     since there will be insufficient locality of reference to make
     caching useful.  So, expect long delays reading email as DNS
     lookups of arbitrary incoming domain names are needed to retrieve
     message contents.  (Today's DNS already likely taking a big hit
     due to anti-UBE measures in email, and it'll likely get worse as
     SPF and similar facilities get deployed.)

  -  Given the above, is the huge cost of a rollout of a new email
     system that makes *two* major changes to everyone's assumptions
     about email works justifiable?  (Pull-style delivery is one
     assumption; eliminating receipient-side notification of delivery
     status, aka DSNs or bounces, in favor of sender-side polling, is
     another.)

My prediction: as multiple im2000 prototypes are rolled out,
enthusiasts will switch over to it, well, enthusiastically.  Some will
drop or effectively "tarpit" their incoming SMTP email, increasing the
balkanization of the Internet.  (Last I checked, I couldn't email
anyone at dsl.net, even via my upstream ISP, so SMTP email is already
suffering from this phenomenon.)

For awhile, there will be rejoicing in the im2000 camp until the early
adopters are joined by the big corporations, who will run roughshod
over the "rules" to ensure their own users will have a satisfying
"experience", e.g. by always retrieving or at least caching incoming
email for them.

At some point in that timeframe, spammers and verminware authors will
target (like never before, if they have played around with it before)
im2000, exploiting its weaknesses *as deployed*, which will include
weaknesses im2000's designers are currently assuming won't exist (just
as SMTP's authors didn't envision today's balkanized SMTP
implementation worldwide).  For example, "pink contracts" between
owners of outgoing message stores and spammers will mean that users
will have to choose, just as they do today, how aggressively they'll
block potentially legitimate email in the hopes of blocking
well-disguised spam and vermin.

The result will be that we'll have at least two major incompatible
means of sending email (SMTP, for people who refuse to or cannot
upgrade, plus im2000), both of which are under attack by spammers,
both of which are inherently incapable of withstanding such attacks,
and we'll wonder why we spent so much $$ to get to that point.

That's assuming early protoypes prove workable.  With proper up-front
research, such as simulations using tiny DNS caches on a
mini-Internet, it might be quickly learned that the DNS cache problem
and typical network latencies *will* lead to an unacceptable end-user
experience, such that "real people" will refuse to use im2000 because
it's "too slow reading mail".

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