IM2000 Won't Be Worth It

Thanks to the flurry of responses to my emails of the previous two
days, I must tentatively conclude that IM2000 isn't worth rolling out
as an alternative to SMTP, even though, in most respects, it's a
better protocol.

The reasons boil down to this:

1.  "The network is the in-box".

    Though JdBP and Charles Cazabon hand-wave this in different ways
    (JdBP says "if the network is down, you didn't get your email via
    SMTP anyway"; CC says "if the network is down, you can't reach
    your POP box anyway"), the *claim* made by IM2000 proponents is
    that IM2000 recipients *DO NOT PAY* for the sizes of their
    in-boxes, but SMTP recipients *DO*.

    The *only* way that difference amounts to anything is to the
    extent that incoming message content is (SMTP), or is not
    (IM2000), sitting in a "storage receptacle" (Maildir, POP3/IMAP
    box, IM2000 recipient cache, whatever) under the control of the
    *recipient*.

    With SMTP, it is (normally, though not necessarily) under the
    recipient's control; with IM2000, it is not (normally).

    If it is sitting somewhere that is under the control of the
    recipient, then the recipient *is* paying for it, but the
    recipient's access to the *entire* payload of incoming email
    depends solely on a comparative handful of network connections to
    be up and running.

    If it is *not* sitting there, so that the recipient is *not*
    paying for it, then the *senders* are paying for it, and they are,
    naturally, utilizing outgoing message stores that are *dispersed*
    over the Internet.

    That means an IM2000 user reading his email will potentially be
    told about messages being available that he cannot, in fact, read.

    How bad is this problem?  Depends on how reliable you consider
    access to the WWW to be, since that's roughly a similar comparison
    and can be (and is) used similarly (though I could argue setting
    up IM2000 outgoing message stores and policing them will be
    harder, at least at first, than setting up a web server).

    Does every web page you have reason to believe exists come up
    quickly and easily, and as reliably as you'd expect your incoming
    message *contents* to come up along with their envelopes in your
    in-box?

    In any case, the essential case I clearly described -- of my
    system receiving, overnight or over days, thousands of
    notifications of incoming email, but the network being down when
    *I* went to finally read them, hence my being unable to actually
    read anything useful -- went unaddressed.

    To the extent that scenario is addressed via IM2000 (by enabling
    caching, for example), the idea that the recipient does *not*
    "pay" for the size of his in-box becomes less and less viable as a
    distinguishing characteristic.

2.  Server deployment required for *sending* email.

    Again, this issue is hand-waved somewhat, on the theory that ISPs
    will be managing message stores on behalf of users, etc.

    And of course that would have to be the case for most users,
    because otherwise IM2000 simply *cannot* be used to originate
    email that is not interspersed with UBM.  (CC, I think, objected
    that SMTP requires a recipient server to handle bounces; that *is*
    a failure point, but not one *critical* to *sending* email, since
    a) not all outgoing email is sufficiently critical to the sender
    for him to care to receive bounces, and b) the sender can point
    bounces to an existing, standard SMTP server that he's already
    using to receive email, and whose operation is already fairly
    well-understood by its admin.)

    The essential fact is that IM2000 has an additional critical
    resource requirement, a substantial point of failure, for simple
    message exchange to work.

    Instead of just *one* server (required to receive the notification
    and message), it requires *two* (one to receive the notification,
    the other to serve the message when requested).

    Further, it's this *second* server (outgoing-message server) that
    concerns me most, because it's much more vulnerable to attack.

    Specifically, spammers, unable to inject messages to an outgoing
    message server, have a great deal of incentive to dDOS it (by, for
    example, forging message notifications that point to it).

    Such a dDOS cannot (directly) hurt spammers, since it isn't
    holding their messages anyway.  But it can slow down the
    responsiveness of the store (server) sufficiently that more and
    more IM2000 users configure their message notification such that
    it automatically pulls down incoming messages stored there, again,
    defeating a key advantage of IM2000.  And if they don't
    *precisely* target *that* server -- they might just cause *all*
    incoming email to be automatically pulled down -- then they'll be
    pulling down spam and vermin hosted on zombie boxen with evil
    message stores.

    (Spammers don't generally dDOS *incoming* message stores, aka SMTP
    servers, because they want them to be available to accept their
    UBM.  Exceptions occur: a site employing heavy-duty C/R or SPF
    might be attacked in a fashion designed to force it to abandon
    those anti-UBM tactics, and such attacks, at least on C/R sites,
    have in fact occurred.  dDOS'ing an *outgoing* message store, on
    the other hand, hurts only those people with legitimate messages
    waiting there, along with the intended recipients of those
    messages, but not the spammers who are trying to inject their UBM
    elsewhere, or into those stores once they stop doing whatever
    filtering they're doing in response to the dDOS.)

    I also worry about the sad-but-probably-true fact that some
    "legit" ISPs willingly tolerate a certain level of spam and vermin
    in their in-boxes, coming from their customers, because it's
    cost-effective to do so.  My own upstream ISP, comcast.net, seems
    to do that, as does adelphia.net (?), based on the huge number of
    attempted vermin injections coming from those hosts.  It's
    probably more costly (in the short run) to disable all Windows
    boxen (or even just all actual zombies) and forego those
    customers' monthly payments than to just let the entire customer
    base bear the *current* costs of delivering their SMTP email via
    these ISPs.  (Certainly if *I* can identify zombie comcast.net
    boxen just be watching my HTTP, SMTP, and firewall logs, their
    well-paid techs can do so, right?)

    What will IM2000 offer to recipients with messages stored at these
    ISP's outgoing message stores, that cannot be provided in an SMTP
    ecosystem?  Whitelisting, blacklisting, spam filtering, all that
    stuff, is already available, today.

    But with IM2000, *I* will have to run an *extra* server, just to
    provide outgoing messages (I'm treating my incoming IM2000
    notification server as equivalent to my SMTP server, so not as an
    extra server I'll need), and it appears some IM2000 are already
    recommending that I not be allowed (by comcast) to do this, in
    case I'm a zombie machine, just as they presumably don't believe I
    should be able to use outgoing port 25 (which would require me to
    use a *less* trustworthy SMTP relay, namely, comcast's)!

3.  "Add-ons" needed to combat UBM roughly parallel what is needed
    and/or would work for SMTP anyway.

    Though he dismisses the complicated scenarios I describe for users
    of MUAs to interact with them so as to engage the various features
    of IM2000, CC seems to assume equivalently complicated ones exist
    to, among other things, effectively "whitelist" senders and/or
    message stores to encourage recipient's notification agents to
    proactively pull down (cache or take responsibility for) incoming
    email.

    Of course, network traffic would be largely reduced by IM2000, if
    deployed, because it doesn't send bounces, tracking deliveries
    would presumably occur only for legitimate email, there aren't as
    many advantages for spammers in repeated delivery attempts, and so
    on.

    But these are not advantages that inherent in IM2000's "pull"
    model so much as IM2000's newness and being done correctly from
    the outset, versus SMTP's historical baggage.

4.  Storage costs for sender not expensive enough.

    JdBP keeps yelling at me for talking about increased sender costs
    for IM2000, and has claimed that this isn't a crucial point in
    IM2000's favor, though his own web pages seem to suggest otherwise
    (see below).

    Yet CC says "[With IM2000, senders] bear the brunt of the costs of
    their messages instead of the recipients.  That is the critical
    point."

    Here, JdBP and CC seem to be describing different systems: one in
    which increased costs for sending messages is not a distinguishing
    characteristic, and one in which it is a "critical point".  Yet
    they each call the system they're describing "IM2000".

    I don't think it's worth viewing the increased cost for senders to
    originate *millions* of messages as worth the deployment costs of
    IM2000, because such senders have a *great* deal of incentive to
    buy large disks, or hijack another message store, whatever.

    But clearly it's going to be *more* expensive to send email under
    IM2000, because of point #2, above: everyone will have to either
    run, or pay $$ for access to, an outgoing-mail server.

    So senders of *occasional* email will see IM2000 as more
    expensive, for their email activity, than will senders of UBM,
    since the latter will be able to easily exploit economies of
    scale.


Some specific responses to that flurry of emails follow, for exchanges
not already covered above:


--------
Charles Cazabon <[email protected]> wrote:
>James Craig Burley <[email protected]> wrote:
>> My SMTP server receives a delivery attempt.  It either temporarily rejects
>> it before, or after, the DATA phase;
>
>In either case, it has used a lot more of your resources than an IM2000
>notification would have (which involves a lot less data transfer).  If you do
>it after DATA it's far worse.

No question about that -- as I've said, IM2000 is a substantially
better protocol in almost every way.  I'm focusing on whether upgrade
costs are worth the effort.

>> 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).
>
>It is an important difference -- but don't worry about "if the remote message
>store was temporarily inaccessible".  You don't worry about it for other
>protocols; IM2000 is no different.

Yes it is; with SMTP, if I know I have a message from you, I *also*
have the message itself, except in certain cases that people might
choose to implement (temporarily reject before or after DATA phase,
and maybe the cache of the contents were deleted after awhile).

And, yes, I *do* worry about this for HTTP and FTP; that's why, when I
see something I know I'll want later on, I download it *then* to a
*local* disk (or computer on my LAN), rather than assuming it'll still
be there when I need it.

>> 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).
>
>Your IM2000 does not track this directly.  It merely asks your outgoing
>message store which recipients of the message have not yet retrieved the
>message.  The outgoing message store takes care of the details.

Sorry, my paragraph was poorly worded; it was intended to refer to
local *incoming* messages.

In any case, I agree with your response, as it pertains to my
*outgoing* messages; despite the concerns I have over having to run an
outgoing message store, I *much* prefer IM2000 (well, the explicit
tracking of deliveries by the sender) to SMTP (which relies on relays
and recipients sending DSNs).

>> Strictly speaking, this *request* might be *ignored* by an
>> uncooperative remote message store in IM2000-land,
>
>Yes, it might.  That means you've got a message store which is trying to abuse
>you.  You then (as I said before) tell your notification agent to silently
>drop all notifications regarding that message store -- and you'll never be
>bothered by them again, and you don't even have to tell anyone.

Agreed, that's a level of control that is hard or impossible to
achieve with SMTP.  But it also assumes "fat-free" message stores will
be a) widely available, b) inexpensive enough, and c) not prone to
dDOS attacks by spammers and their enablers.

I don't know offhand how such message stores will be economically
created and maintained.

>> (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.)
>
>Not really.  As I said, don't worry about it.  Occasionally a POP server is
>unavailable; I just get messages ten minutes later.

That's different.  With the SMTP ecosystem (which includes POP3 and
IMAP), my *entire* mailbox is either available or unavailable.

With IM2000, I might have 1000 messages waiting, 293 that do not have
accompanying message contents, contents that become available again on
arbitrary bases that I cannot predict.

People *will* learn to configure their IM2000 setups so incoming
messages are automatically fetched, of course; which, in turn, will
defeat one of the advantages of IM2000.

>> > 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.)
>
>Totally different beast.  In SMTP, all a sender has to do is forge a different
>sender address and relay through a different zombie spam relay, and you'll get
>his messages again.  With IM2000, he has to set up a new outgoing mail store
>(for which he pays), quite probably on a different server (because everyone
>knows "message store on spammer.example.net are just spam, ignore
>notifications about them).  It's not cost effective for the spammer.

Cross your fingers and hope to die?  ;-)

Well, it might turn out to not be cost-effective for the *legitimate*
sender of email, who might find it difficult/annoying/impossible to
constantly seek out new, "fat-free" outgoing message stores, convince
them he isn't himself going to inject spam and/or vermin into them,
and pay them to allow him to inject his legitimate email into them.

>I think you misunderstand; there's nothing about IM2000 that says you need to
>run any kind of a server to use it.  You don't.  Joe User just buys/rents an
>outgoing mail store and an incoming notification agent, possibly from
>different companies, possibly the same one.  If it's Grandma Parker, it'll
>just be included in her ISP's monthly fees and will be operated by her ISP,
>just like her POP3 mailbox and SMTP relay server are today.

That'll cost more $$, just to *send* email.  As I said above, it's an
extra point of failure that is *designed* into IM2000 over and above
SMTP.

>> 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".
>
>Only in a simplistic view.  Real IM2000 MUAs will take care of most of this
>automatically.  Notifications about messages from known senders (my friends,
>colleagues, companies I voluntarily do business with, mailing lists I'm on,
>etc) will be automatically handled -- my MUA will just download the whole
>message.  Notifications about messages from new senders the MUA will likely
>download the summary headers automatically, the first time, and give me a
>simple "Retrieve this message?" dialog.  After reading it, it'll ask me
>"Always retrieve messages from this sender?" or similar.

That sounds pretty complicated after all!  And, AFAIK, today's SMTP
ecosystem could handle that with a fairly close approximation, though
not nearly as cleanly as IM2000.

>> 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.
>
>They're "willing" because it costs them almost nothing; the costs are borne by
>the recipients of their message.  Nothing you can do to SMTP changes that.
>IM2000 reverses it; they bear the brunt of the costs of their messages instead
>of the recipients.  That is the critical point.

Not according to JdBP; he keeps yelling at me for in any way implying
that IM2000 shifts some of the burdens for message exchange over to
the senders, which I do (possibly setting up a straw man, in his view)
in order to point out that that burden is possibly not sufficiently
difficult to overcome for determined spammers.
--------


--------
Jonathan de Boyne Pollard <[email protected]> wrote:
>JdeBP> Moreover, it is unlikely that SMTP-based Internet mail will
>JdeBP> improve.  Most of the changes to it in recent years have (in
>JdeBP> the long run) damaged, rather than improved, it.  I don't see
>JdeBP> that trend reversing.  Indeed, given how many people have
>JdeBP> recently expressed the conclusion that changing SMTP won't
>JdeBP> solve the problem, it seems probable that SMTP won't change
>JdeBP> much at all, let alone change for the better, in the future.
>
>JCB> Well, that's partly due to coming to a conclusion, at which I
>JCB> have not personally arrived.  If I believed IM2000 was the One
>JCB> True Way, I wouldn't put much effort into improving SMTP either.
>
>You're assuming that it is solely people who believe that IM2000 is the route
>to take that have been expressing this conclusion.

No; hence my use of the word "partly", above.  Personally, I have
serious doubts about the utility of improving SMTP as-is; I'm just
considering a variety of possibilities, keeping my mind open, and
since "everyone" knows SMTP already, it is, like Common LISP for a
certain other set of discussions, a useful common ground.

>People aren't going to put much effort into changing SMTP
>because they realise on its merits alone, irrespective of IM2000, that it
>isn't, and isn't going to be, the solution.

A big question in my mind is, given the "true" solution, will its
relationship between message notification and content transmission be:

  1.  Content always accompanies notification (as with SMTP).

  2.  Content never accompanies notification, must be pulled (IM2000).

  3.  Content never accompanies notification, must be pushed on
      request.

  4.  Content may accompany notification, or may later be pulled
      (IM2000 could be modified along these lines to allowed SMTP-like
      behavior).

  5.  Content may accompany notification, or may later be pushed
      on request (#3 with optional SMTP-like behavior).

  6.  Content may accompany notification, and may later be pushed or
      pulled as decided by the relevant agents (most-flexible
      architecture of all).

My problem with IM2000 is that it rejects choices 1, 3, 4, 5, and 6,
apparently on the theory that choice 1 isn't working for us today, yet
I don't think the costs of deploying it justifies locking everyone in
to choice 2.

>Which brings us back to the point that basing an argument upon the premise
>that SMTP _is_ going to improve is flawed.

Fortunately, that's not what I'm doing.  I'm asking *questions* based
upon the premise that SMTP *could* be improved, at least in theory, so
as to bring out just how worthwhile IM2000, which is *also* a theory,
is going to be.

>JCB> My concern is, what if IM2000 turns out to be a wasted
>JCB> opportunity to replace Internet email protocols wholesale, in
>JCB> that it ends up not really doing much to combat abuse, costs 
>JCB> $$ to deploy and replace SMTP on a sufficiently widespread 
>JCB> basis, and also fails to offer sufficient additional 
>JCB> flexibility, features, etc. to have really been worth all 
>JCB> the work?
>
>(IM2000 _does_ replace the mail transport protocols wholesale, of course.)

No, of course it does *not* do that.  All it does is offer an
alternative.  As long as people are willing to send and accept SMTP
email, IM2000 won't force them to switch.

>A few cost/benefit analyses would be interesting.  But they would have to
>factor in the huge cost of recieving UBM and consequently losing messages that
>the SMTP-based Internet mail system has.  (-:

Personally, I've been a big target of spam, vermin, and joe jobs, yet
I'm now more happily accepting incoming SMTP email than I've been for
the past couple of years, thanks to employing some mind-numbingly
simple anti-UBM measures that, of course, "won't work" in the long
run, but work great for now.

But, yes, I'm a big fan of factoring in costs that are normally
hand-waved by people making such assessments, e.g. the costs of
running proprietary and insecure software, which has led us
substantially to this point where SMTP is becoming difficult for many
sites to support.

>And I think that the evidence that people are seriously considering schemes,
>such as SPF, that will actually make _more_ radical changes to the
>architecture than IM2000 will once all of the (undesirable) ramifications are
>followed through, is good evidence that the benefits even of a solution that
>involves significant architectural change would be widely seen to outweigh the
>costs.

Yet, here I am, trying to figure out whether IM2000 is the Next Great
Thing, or just another C/R or SPF: an overly expensive way to break
email delivery.

;-)

>JCB> [...] especially if enough people gain a clearer understanding 
>JCB> of the problem and how to solve it, come to a *useful* consensus,
>JCB> and work together, they might decide that IM2000 is not really
>JCB> the One True Way, rather, another form of message delivery that
>JCB> an improved SMTP-like ecosystem should offer, in addition to 
>JCB> many others.
>
>That seems very unlikely.  As I pointed out right at the start, people are
>thinking this through for themselves and independently re-inventing IM2000. 
>(I saw yet another such occurrence just yesterday, incidentally.)

Sorry, but That Don't Impress Me Much.
--------


--------
Then he wrote:
>JCB> Sampling the spam my system gets, I notice some that are
>JCB> nothing but one of the following:
>JCB>   -  URLs to web sites with text advertising a product
>JCB>   -  URLs to web sites with only graphics (e.g. JPEGs)
>JCB>      advertising a product
>JCB>   -  MIME-encoded graphics (JPEGs) advertising a product
>JCB> How does the fundamental architectural difference between
>JCB> IM2000 and SMTP address UCE of those sorts?
>
>By having the sender store the messages concerned, and the recipients
>only download them when they choose to read them, of course.
>
>Hint: This argument has come up before.  Whilst it is fair to say that
>sending a message comprising solely a URL, with the expectation that the
>recipient will automatically view the web page at that URL, is the nearest
>that the SMTP-based Internet mail system can come to IM2000, there are also
>two very important points that most people miss:
>
>1.  Whilst it's the closest that the SMTP-based Internet mail system can
>come to IM2000, it's _not_ IM2000.  It's just a simulacrum.  In particular,
>note that the SMTP-based mail message contains a lot more than an IM2000
>notification would, and provides senders with trivial covert channels.
>
><URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/design.html#NoTrivialCovertChannels>

Yes, but, without whitelisting and similar content-agnostic tactics,
that could just mean one has 1000 emails waiting in one's in-box, all
from *reasonably* trustworthy message stores, but only 5 or 6 have
them actually aren't spam or vermin.

And there's no real way to know what they are without reading the
messages themselves, since there are no trivial covert channels.

I like your point about that, by the way.  I agree with it about half
the time; the other half, I believe it is important to provide some
limited space for arbitrary text (say, a 40-character "Subject:"
header).

So the answer just isn't clear to me.

>2.  Senders _use_ these covert channels in the SMTP-based Internet mail
>system.  People claim that they receive unsolicited bulk mail that
>comprises only a URL.  But they often unconsciously edit out what it is
>that they actually _are_ receiving, which _isn't_ as they describe.  My
>unsolicited bulk mail load comprises messages with URLs, but these URLs
>are invariably accompanied either by enticing text in the body encouraging
>one to view the web page with the advertisement on it ("click _here_ to
>remove yourself from our mailing list") or enticing text _in the headers_
>("Re: The web page I was telling you about").

Indeed, sometimes, but not always, and with tactics like including
just the following URL in a spam

  http://[email protected]/stories/43254829.html?DUDE_YOU_GOTTA_READ_THIS_STORY!!

it's hard to really and truly avoid the covert-channels problem
without getting all Totalitarian about email content (envelopes as
well as message headers and bodies)!

>2. It's an error to conflate transport and content.  The two are separate,
>and their problems are only very loosely related.  IM2000 addresses
>transport.  People want it to address content as well.  But that's a
>mistake.  The problems with transport and the problems with content can,
>and should, be addressed separately.  The "graphics advertising a product"
>notion is a red herring, therefore.  Your first two cases are identical
>as far as transport is concerned.

That's true: IM2000 separates the two, which is helpful.  The question
is, will it matter to the typical end user -- the typical target of
spam, who will probably need content to disambiguate incoming email?
--------


--------
Then he wrote:
>If you think that the situation is merely that lots of people think that
>IM2000 is a good idea, then you don't appreciate the full implications of what
>I have reported observing.  It's not merely the case that a lot of people
>think that IM2000 is a good idea.  It's also the case that a number of people
>are now, separately and independently (since each has implied the idea to be
>their own and made no mention of IM2000), thinking through the problem and
>coming to the same conclusion.

I am thinking through the problem to, have also thought through
IM2000, and am coming to a different conclusion: that relying on a
pull architecture to send email is unwise.

But I remain open to convincing arguments to the contrary.

>I didn't tell you what to decide.  I told you that you _should_ decide, and
>that the reason for this is that the time for the idea has evidently come.  I
>find it quite ironic that the one sentence that you disagree with actually
>_only_ tells you that you shouldn't be sitting on the fence with respect to
>IM2000.

Why not?  It won't hurt anybody but me, the one with pickets up his
butt, especially if every other smart person on the planet has already
independently decided IM2000 is the One True Way.

For gosh sakes, let me be the Ludditesque curmudgeon for once in my
life, okay?  ;-)
--------


--------
Then he wrote:
>JCB> And when I imagine how it'd actually be deployed, over the same
>JCB> breadth and depth of audience as present SMTP email has, it
>JCB> seems to me like it'd end up having pretty much the same
>JCB> weaknesses as SMTP has today, or will have as SMTP is
>JCB> incrementally improved.
>
>JdeBP> No, it won't.  The whole point of IM2000 is that by design 
>JdeBP> it does not have one, particular, very basic flaw of 
>JdeBP> SMTP-based Internet mail.
>
>JCB> And that flaw is?  
>
>... expressed both at the bottom of the web page that I suggested that 
>you read all of the way to the bottom, and at
><URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/design.html#SendingIsCheap>.

Well, we seem to be going around in circles in this, as your web page
sorta does there: "The fundamental problem with SMTP is that it is
cheap for senders to make copies of and to transmit messages" seems to
contradict "the IM2000 mail architecture takes advantage of the fact
that senders have low copying and transmission costs".

Now, that first statement ends with "putting senders at an advantage
with respect to recipients", and I agree that being an SMTP recipient
is *much* more expensive than a) it should be and b) being an IM2000
recipient, for at least some useful characteristics of incoming email.

But if IM2000 *in practice* isn't used that much differently from
SMTP, as far as recipients are concerned (if they usually turn on
local caching or outright acceptance of incoming email), then these
advantages aren't so strong.

In that case, why not look at a protocol that offers both push *and*
pull deliveries as options both with and out-of-band-with-respect-to
message notification, dispensing with some of the most noxious
characteristics of SMTP, such as bounces?

>JdeBP> The notion that you are buying into, that SMTP will improve in 
>JdeBP> the future and will end up just as good as IM2000, is a false 
>JdeBP> one.
>
>JCB> Whatever I'm "buying into" is irrelevant in this thread, since 
>JCB> I'm not in any way claiming that my own beliefs should be 
>JCB> considered in weighing the viability of IM2000.
>
>Of course it is, because yes you actually are.  You buy into the notion 
>that SMTP will actually be improved, and you base your argument, quoted 
>above, upon that belief.

SMTP is being tweaked all the time, as you acknowledge; in my case, as
an ecosystem, it *is* improved over what it was in 2002 and 2003.

What I don't see is that IM2000 has enough fundamental improvements to
make it worth deploying in place of SMTP.

>JCB> my focus isn't on the nuts and bolts of IM2000, rather, how might 
>JCB> I advocate its deployment (and the substantial costs of same) to 
>JCB> someone like my wife, who is *not* highly technical, but (at least 
>JCB> in her past) runs an IT department and therefore is likely to have 
>JCB> some very insightful, incisive questions regarding exactly what 
>JCB> IM2000 buys us that SMTP not only *doesn't*, but *can't*, regardless 
>JCB> of how it's incrementally improved as an ecosystem.
>
><URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/differences-from-smtp.html#SenderStoresInbox>

I already talked to my wife about it; she doesn't like it either,
though we both agree it's a nice *option* for incoming message servers
and/or their users to enable, which is difficult to do (impossible to
do cleanly) with SMTP.

Sorry.  ;-/
--------


--------
Then he wrote:
>JCB> In particular, a "pull" paradigm is not, from a resource point
>JCB> of view, all that much different from using Greylisting, Defer
>JCB> Hostility, or simply not having enough SMTP server resources to
>JCB> reliably and quickly accept all incoming email, with today's
>JCB> SMTP infrastructure.
>
>JdeBP> You have a very restricted definition of "from a resource
>JdeBP> point of view".  You are taking it to mean only network
>JdeBP> service availability (because that's the only respect in
>JdeBP> which what you describe is actually similar to a "pull
>JdeBP> delivery" system). But there's far more to a resource point
>JdeBP> of view than that.
>
>JCB> I don't see how I'm doing that.
>
>All of the measures/situations that you mention deal only with the
>resource of network service.

No.  Forcing the sender to continue taking responsibility for the
message, by temporarily rejecting it, deals with resources other than
network service, such as disk storage, outgoing-message-server
maintenance, and so on.

I'm pretty sure ISPs are motivated by more than "network resources"
and "don't want to offend others" by having TOS and other means to
prevent their *own* users from using their outgoing email servers to
send UBM.

I'd say not having their disks filled with outgoing email, or incoming
bounces, has a lot to do with it too!

>JCB> An SMTP server that defers questionable materials N times
>JCB> forces the SMTP client to *store* that message for a longer
>JCB> period of time, for example.
>
>... yet still, in the end, results in multiple messages stored by
>recipients in contrast to one message stored by a sender.

Huh?  Well, yeah, only in the sense that IM2000 recipients might
choose to do the same thing.  That's my point: the message is either
under the control of the sender (in which case it might not be
available when the recipient wants to read it) or the recipient (in
which case the recipient pays) or both (in which case both pay).

IM2000 cleans this up a bit, but doesn't change it fundamentally
compared to what can be done with SMTP as an ecosystem (without
changing SMTP as a *protocol*).

As I
>said in the remainder of that paragraph that you interrupted
>halfway through:
>
>	JdeBP> For example:  Storage is a resource, too, and a
>	JdeBP> "pull delivery" system has significant effects on
>	JdeBP> the distribution of storage costs, causing them
>	JdeBP> to be _very_ different to the case of
>	JdeBP> SMTP-plus-those-bodges.
>
>JCB> IM2000 [...] is a wonderfully (theoretically, anyway ;-)
>JCB> new, clean system,  [...]
>
>I have my doubts that IM2000 is wholly new.
>
>JCB> But these bodges [to SMTP] have a big advantage over IM2000:
>JCB> they can be (and some are) implemented today, piecemeal, and
>JCB> they pretty much automatically interoperate with the vast
>JCB> majority of *today's* email, and the SMTP clients that send
>JCB> it, that the users of those bodges (via their choice of ISP)
>JCB> *choose* to receive.
>
>No they haven't.
>
><URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/shims.html>

Which says people will lose bounce messages when IM2000 starts getting
deployed!

Well, shee-ucks, why not just start getting rid of bounce messages
from the SMTP ecosystem?  I'd *love* that!  Let's introduce protocols
to allow MUAs to query their outgoing message servers (usually SMTP)
about messages that have been sent, etc.  Hardly as big an upgrade as
IM2000, but it might be worthwhile, and it'd get rid of one of the
*huge* costs of UBM under SMTP, namely, bounce-message handling.

>JCB> As to the issue of storage, which you properly raise: looking
>JCB> at the big picture, I'm less enamoured with that as a *critical*
>JCB> resource.  After all, storage costs have been falling.  [...]
>
>Not the Moore's Law Fallacy again!  (-:
>
>If storage costs are unimportant, why does my ISP impose a quota
>on my mailbox ?  (Answer:  Because storage costs _are_ important,
>of course, which is in turn because UBM senders obey a variant of
>Parkinson's Law.)

No, because *professionally managed* storage costs are important.

It probably costs more to "rent" 2GB at a decent ISP for two years
than to buy a *20GB* disk of your own.

Now, which kind of storage do *spammers* want, to send email?  The
20GB *local* disk, running a phantom message store, or the disks on
zombie machines.

If we assume IM2000 will consist of "vetted" message stores, as seems
to be the case, then we've a) introduced a whole new point of failure,
of cost, of contract agreement, and b) recursed on the
whitelisting/blacklisting problem, this time for outgoing message
stores.
--------


--------
Then he wrote:
>JdeBP> Moreover, there are some very interesting possibilities that
>JdeBP> IM2000 yields in terms of behaviour modification through
>JdeBP> ostracism, as a matter of fact.
>
>JCB> I'm sure that's true.  I'm still trying to understand the
>JCB> parameters of such ostracism for IM2000, vis-a-vis SMTP and 
>JCB> its potential (however limited), so I can gauge how 
>JCB> worthwhile an IM2000 rollout might be.
>
>Read the case studies and the section dealing with notification processing
>policy.

Okay, I've done that now, and don't see much likelihood of it being
enough better than what can be done today within the SMTP ecosystem
(and the existing SMTP protocol) to be worthwhile.

But I'd love to be proved wrong...as long as I don't get shut out
because (e.g.) I'm a Comcast subscriber!  ;-/
--------


--------
Then he wrote:
>JCB> Surely if only a few "enlightened individuals" use im2000, [...]
>
>JdeBP> From following the news coverage second-hand, I speculate 
>JdeBP> that if an ISP were to come out with IM2000 this year, 
>JdeBP> popular sentiment is such that it will be overwhelmed - 
>JdeBP> not with mail but with customers.  (-:
>
>JCB> Hard to say.  ISP's might be more interested in SPF, for 
>JCB> various reasons, some of them probably short-sighted.
>
>ISP's might be.  SPF gives them customer lock-in.  Nonetheless, 
>I did write "customers", not "ISPs".

Customers of *what*, exactly?  ;-)

>JCB> Meanwhile, those enlightened individuals could get a pretty 
>JCB> big bang for the buck by simply switching to Any Protocol Other 
>JCB> Than SMTP in order to communicate with each other.  That is 
>JCB> basically why I posted originally: to explore *that* as the 
>JCB> germ of an idea to combat UBM.
>
><URL:http://homepages.tesco.net./~J.deBoynePollard/contacting-the-author.html#Fidonet>

I have no idea how to take advantage of that.  Better to just blast my
personal blathering to you via lists like this -- kinda like Linus
Torvalds (IIRC) saying something about not needing backups when you
can just put your stuff up via FTP and let the world mirror it
overnight.  ;-)

>JCB> But ISPs *could* offer something like that today, without 
>JCB> IM2000, via SMTP.  
>
>No, they couldn't.  Another IM2000 marketing slogan, remember, is 
>"Infinite Inbox quotas!".

IM2000 does this much better than SMTP could, in a vanilla world.

But, given all the filtering it looks (from your and CC's posts) that
IM2000 would need anyway, one could argue that, with that filtering on
top of SMTP and Defer Hostility in place (which does not change the
SMTP protocol), the differences would be small enough to not justify
an IM2000 rollout.

>JCB> [...] given the relative popularity of the two technologies, 
>JCB> it'd be a *more* reliable way to continue receiving and 
>JCB> sending email while maintaining those promises.
>
>For the sort of people who are affected by Inbox sizes in the
>first place, SMTP is hardly reliable now.

That's true.  And for people who *cannot* get around this, via any
combination of filtering, IM2000 is a *wonderful* invention, in that
they get to leave their emails with the senders.

I don't think that's a large-enough audience, however, even though, in
principle, I like the idea.

And, as I've suggested above, I'd prefer to choose among these options
*within* a messaging protocol, not via which protocol I *run* on my
system (or that my ISP runs).

>JCB> (After all, ISP's can hardly promise anything *useful* 
>JCB> regarding IM2000 in-box sizes unless their users also 
>JCB> promise to not sign up to receive in-bound *SMTP* 
>JCB> email...correct?  
>
>No.  What makes you think that signing up to receive mail via SMTP
>Relay affects IM2000 Inbox sizes one whit ?

Oh, if you're viewing incoming SMTP email as completely distinct from
their incoming IM2000 email, then, nothing.

But, if users are offered IM2000 readers that can handle incoming SMTP
email (notifications) just as well, those users won't really see
themselves as having distinct in-boxes, so their IM2000 in-boxes
*will* have incoming SMTP email sitting there, taking up space.

>Customers choosing not to sign up for old-style SMTP recipient 
>service is something that ISPs will like and encourage, because it
>means that they can just switch SMTP Relay service over to Snubby 
>The Mail Rejector, and re-use all of the hard discs that were 
>holding their mail queues and recipient mailboxes for IM2000 
>message stores.

Always remember this important point: rejecting SMTP email (e.g. in
favor of IM2000) is simply an *extreme* case of SMTP being broken for
a site.

Therefore, even half-measures that allow SMTP to continue to limp
along, delivering useful email, without soaking up too much resources,
will be viewed as some as worthwhile.

>But it has no bearing on whether ISPs can offer
>IM2000 recipient services to customers.

Agreed.

>JCB> the whole concept of SMTP email presently requires bounces...but
>JCB> it doesn't *have* to in future incarnations, which might be 
>JCB> more easily transitioned to than would be IM2000.
>
>No, they wouldn't.  If one has given up the basic "store and forward"
>nature of SMTP-based Internet mail, then it is almost certainly going
>to be as easy if not easier to move to IM2000 than it would be to move
>to such a hypothetical architecture.

Perhaps, but not necessarily.  I haven't thoroughly thought through
what a generic push architecture, with inquiries regarding previous
message deliveries in place of bounces, would look like -- but to the
extent I have, it seems simple enough to design and implement.

>But again, you are buying into the notion that there will be such
>a future incarnation of SMTP.

Again, no I'm not.  Why are you buying into the notion that there will
be widespread acceptance of IM2000, when you can't even convince *me*
that *I* want to use it?  (And I'm one of the "good guys"...right?)
--------


--------
Then he wrote:
>JdeBP> Moreover, you are falling into the trap, that people fall 
>JdeBP> into time and again, of addressing the wrong problem.  The
>JdeBP> problem isn't denial of network service.  It's unsolicited 
>JdeBP> bulk mail.  Denial of service is a completely different (and,
>JdeBP> as far as I can tell, unavoidable) problem.
>
>JCB> Hold on a second!  *Today's* problem *includes* denial of 
>JCB> network service.  
>
>It's not the intent, though.  It's merely a side-effect.  (The intent 
>of the opposition is, of course, to have people read their messages, 
>not to _prevent_ that.)  Denial of network service as an actual problem 
>is another, separate, problem in its own right.

Okay, I'm confused: you and CC both talk about how IM2000 will be more
efficient, ISPs will be able to mothball their big disks (pronounce
that carefully ;-) once they switch their users over from SMTP to
IM2000, the conjestion that results in valid SMTP email getting
bounced or dropped will go away, etc.

So maybe I just lost the thread of that discussion.  But it's
important, if it turns out that fixing that problem is a matter of
throwing *scalar* (multiplying) resources at serving email, whereas
deploying IM2000 is likely to be much more expensive *and* simply
reduces the costs of dealing with UBM by, again, a scalar factor,
meaning we'll end up in the same boat in some number of years unless
we employ *other* means that either we already *are* employing with
SMTP or perhaps we *could*.

Anyway, you're right, spammers don't usually want to DOS or dDOS
incoming message stores, but, what does that imply about IM2000's
*outgoing* message stores?

>JCB> If IM2000 addresses only UBE, then *sufficient* similarities
>JCB> between IM2000 as actually widely deployed and SMTP as deployed,
>JCB> such that IM2000 fails to *eliminate* UBE, would result in 
>JCB> denial of network service in a future IM2000 world, just as we
>JCB> have today.
>
>The existence or otherwise of UBM is irrelevant to denial of network 
>service.  As I said, it's a completely different (and, as far as I 
>can tell, unavoidable) problem.

Why are "we" moving to IM2000, then?  It won't stop, or even reduce,
UBM; it won't significantly reduce the expenses associated with
exchanging emails (it might even increase them for many legitimate
users), AFAICT.

>JCB> if "IM2000 does not directly incorporate direct recognition 
>JCB> of unsolicited and bulk qualities", [...] then UBE continues 
>JCB> to exist, possibly thrive, in an IM2000 world, since IM2000
>JCB> cannot, itself, *recognize* it.
>
>Read the very next sentence on the page as well.  

Yes, "recipients no longer bear the costs of receiving and storing
unwanted mail".

I don't believe that's true; I believe most of them will turn on local
caching of incoming email, and that any content-agnostic or
content-sensitive filtering they employ to straddle that space
(between "recipients don't store incoming messages at all" and
"recipients always store incoming messages" a la SMTP) is likely to be
deployable, if not already deployed, in the SMTP ecosystem.

>JCB> But I think we could do even *better* than IM2000, without 
>JCB> designing a system much more complicated than it; so, ignoring 
>JCB> deployment costs, why not design a better system, and, taking
>JCB> into account deployment costs, given that IM2000 is not yet 
>JCB> deployed, why not deploy that better system instead of wasting 
>JCB> time deploying IM2000?  
>
>Because the grass is not necessarily greener.  

Pot, meet kettle.

>JdeBP> Again, you are buying into the very dubious notion that an 
>JdeBP> "improved SMTP" will ever exist.  No-one has yet come up 
>JdeBP> with one, and as such you cannot say how flexible it might 
>JdeBP> be relative to IM2000.
>
>JCB> Again, that might be a sort of semantic quibble.  
>
>No.  It isn't.
>
>JCB> (Suppose we renamed IM2000 to "improved SMTP" [...])
>
>Then the comparison of the relative flexibility of IM2000 with 
>"improved SMTP" that you made would be a somewhat pointless one.

Okay, I've had enough of that: you're using my *hypothetical* improved
SMTP ecosystem (which is *not* necessarily going to require an
improved SMTP *protocol*) as a straw man to attack my arguments.

Let me ask you this: will your IM2000 system be able to interoperate
with SMTP?  Will the result be better, or worse, for SMTP users whose
email goes through IM2000 components?

If better, then *you* are proposing an "improved SMTP", in the form of
shims connecting it to IM2000.

If worse, then you're "breaking" SMTP to achieve compatibility, so why
don't we just *consider* what else we could accomplish by "breaking"
SMTP in those ways, without having to deploy a whole new (yet
strangely restrictive) email architecture like IM2000?
--------


--------
Then he wrote, in response to Ian Lance Taylor <[email protected]>:
>ILT> Why can't the spammer set up a zombie outgoing mail store on 
>ILT> a hacked system, just as spammers today set up zombie e-mail
>ILT> relay stations on hacked systems?
>
>He can.  But there are several important differences.  
>
>First: Recipients can choose to give different priorities to notifications
>according to whether they "know" the message stores that those notifications
>reference.  So a recipient could instruct his/her recipient MUA that it
>"knows" AOL's and Sally's message stores.  "New" mail on any other message
>stores would then be flagged as residing on an "unknown" message store, when
>the list of "new" mail is displayed.

This wouldn't be as useful in an SMTP ecosystem?  Why not?

>Second: Recipients, and recipient notification owners, can arrange to exchange
>information with one another about suspect message stores.  Recipients can
>also choose to delegate the decision about whom they will pull mail from, to
>vetting services.

They can do the former today in an SMTP ecosystem, correct?  Is that
as useful, or not as useful?

About the latter: true, they can so delegate, but in an SMTP
ecosystem, if they don't trust the *sender*, that's basically the same
as not trusting either the IM2000 *notifier* or its *outgoing message
store*, correct?

>Third: A message store is a server, whereas an SMTP Relay puppet is a client.

That's certainly true: an SMTP client, injecting a message, is not
necessarily known to be associated with any responsible message
server, whereas with IM2000, without a responsible message server, no
message can be sent.

I'm not sure that's an *advantage* of IM2000.  It's certainly a
*characteristic* of it, and it's a useful *option* of any new
protocol.  (Some try to implement it in SMTP during message receipt by
trying to contact the server to which they'd send a bounce; I don't
think that's a great idea, but it's not all that different,
architecturally, from IM2000, though IM2000 handles it much more
cleanly.)

>The traffic patterns for the two are noticably different.  And note that some
>organizations _already_ put measures in place to prevent all machines, other
>than the ones that they specifically designate, from running public servers. 
>(Think about it this way:  The solution to the "hijacked machine running a
>message store to serve up the hijacker's messages" problem is the same as the
>solution to the "hijacked machine running an FTP server or an SMB server to
>serve up the hijacker's files" problem.)

Seems like this can generally help with SMTP as well.

>Fourth, and perhaps most importantly: Setting up a message store on a hijacked
>machine doesn't get the mail delivered and seen.  IM2000 is, after all, a
>"pull system" and the recipients still have to choose to pull the mail from
>the message store.

Which they almost always will, unless they are magically able to
distinguish UBM from legit email based on "From:" and "To:".

>Setting up an SMTP Relay server in a hijacked machine, in
>contrast, causes mail to be pushed out to recipients.  (Think about it this
>way, if you like:  A hijacker can _right now_ set up a web server on such a
>hijacked machine, publishing web pages of the hijacker's choosing.  Yet we
>don't hear about an "unsolicited bulk web page" problem.)

We will, and I think ILT already responded saying we have.
--------


--------
Then he wrote (in response to my emails):
>JCB> (An exception: senders need not serve up message content in
>JCB> SMTP-land; they *must* do so in IM2000-land.  I'm nervous
>JCB> about requiring more widespread server deployment -- given 
>JCB> how poor server deployment already is for SMTP, DNS, HTTP, 
>JCB> and the like -- just to *send* messages.  Seems like it
>JCB> introduces another major "point of failure", in that, with
>JCB> IM2000, both the sender *and* the recipient of an email 
>JCB> must have working message-exchange servers.)
>
>This is worrying about nothing.  One already has such concerns with SMTP-based
>Internet mail.  The recipient's mailhost must have a working SMTP Relay
>server.  If call-back sender verification is in use, so too must the sender's
>mailhost.

The *sender* need not have a working server available on his machine,
or even his ISP's machine (which might be unavailable to the
recipient's), to send email with SMTP.

With IM2000, a sender who cannot afford to pay for an outgoing message
store, or whose store happens to be unreachable by the recipient when
he goes to read the message, is dead in the water.

>JCB> And note that this scenario, designed to favor IM2000, 
>JCB> assumes that readers of email will be willing and/or able to 
>JCB> take some extra steps when it comes to reading email, such as
>JCB> clicking an "obtain just the headers" button, waiting for 
>JCB> remote retrieval, reading what comes back, then clicking 
>JCB> "obtain the whole message" button, waiting for remote 
>JCB> retrieval, reading what comes back, then clicking "this is
>JCB> spam, I really didn't want to see it".
>
>You aren't thinking like an MUA writer.  MUAs don't necessarily have explicit 
>buttons for every single operation in the IMAP.  They just display a user
>interface and execute the appropriate sets of protocol transactions behind the
>scenes.  Why do you think that they must have explicit buttons for every
>single MSRAP transaction?

Well, I read your descriptions of why IM2000 is better, and your case
studies and, well, just connected the dots, I guess.  Or did you not
talk about "retrieving headers" somewhere?

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

I did.  They confuse me...I am just a simple caveman, thawed out and
told to read my email.
--------

--------
Then he wrote:
>JCB> (And, let's face it, im2000 *would* be at least a partial
>JCB> retreat against a victorious enemy.)
>
>JdeBP> No, it isn't.  Indeed, quite the converse.  Adopting
>JdeBP> IM2000 is the neutralisation of an enemy by completely
>JdeBP> eliminating the game that is biased in his/her favour.
>
>JCB> Well, here's where I think we might disagree pretty strongly.
>
>Yes, but mainly because (a) you've tried to rewrite your above comment into 
>being "retreating" from an aspect of reading (a somewhat distorted use of 
>"retreat", moreover) when it actually referred to retreating from UBM 
>senders (which you don't actually mention at all here), and (b) you
>are applying double standards.

Ummm...don't see how I'm doing that.

Yes or no: readers of IM2000 email will always have their message
content accompanying notifications of those messages, just like SMTP
and like real life.

If "no", that *is* a retreat.  It's not a double standard, because if
the SMTP ecosystem is improved (locally by a site admin) to allow for
some kind of Defer Hostility system whereby users are notified of
incoming email without the contents being unavailable, I'd call *that*
a retreat as well.

But with IM2000, it's a *wholesale* retreat -- the feature is given up
by *all* its users, *by design* -- whereas with SMTP, it's just an
option (albeit a weird one).

>JCB> With IM2000, I'm potentially offered the tantalizing "You Have
>JCB> IM2000 Mail From [someone spectacular]", and when I go to
>JCB> actually *read* that email, I'm told "the network is down"
>JCB> or "the MSRAP is unavailable".
>
>And with SMTP-based Internet mail, you're offered the tantalizing ability to
>send mail, but when you actually send it it bounces because the remote end is
>unreachable, the recipient's mailbox is full, or your connection to Internet
>is down for too long.  Here's a double standard.

No, because:

  -  If the remote end is unreachable, IM2000 mail notifications won't
     reach it either

  -  If the recipient's mailbox is full, then the recipient isn't
     (necessarily, though may be optionally with SMTP) told he has
     messages that he then can't read as with IM2000

  -  If my connection to the Internet is down for too long, then I
     couldn't deliver an IM2000 mail notification anyway

With IM2000, if the originating-message store is down when the
recipient goes to read the message, that recipient is *screwed*,
*period*.  No amount of hand-waving can change that.

And, in response to such screwage, the recipient will probably have to
be taught (in advance) what the implications of that situation are,
what his choices at that point are, and how to express those choices
via MUA.

I don't think expressing such choices is something people are used to
doing, just as they aren't used to getting notifications of, say,
certified mail or packages and then discovering that they have to
somehow reach the *originating* post office in order to retrieve it.

>JCB> what we're retreating from, by switching to IM2000, is the
>JCB> assurance of being able to *read* messages whose
>JCB> notifications are sitting in our in-boxes.
>
>And here's the very torturous rewriting of what we are supposed 
>to be retreating from.
>
>JCB> In general, IM2000 seems a bit like implementing, for that
>JCB> subset of computing activities known as "electronic mail",
>JCB> the enticing concept of "network terminals".  So computers
>JCB> in households don't really receive or store email, they just
>JCB> tie into a central mainframe (which is now called the Internet,
>JCB> and has an arbitrary, fairly loose arrangement of Message
>JCB> Stores) that takes care of that for them.
>
>Not at all.  Originator MUAs keep copies of mail that they send and recipient
>MUAs store copies of mail that they decide to take over responsibility for
>storing.

Okay, *where* and *when* do recipient MUAs store those copies?  In a
*recipient* in-box?  And as soon as notifications are received?

If that's the case, how is that substantially different from the
SMTP/POP3/IMAP ecosystem we have today?

If *not*, how does your scheme prevent the situation where a recipient
is told "you have a message from so-and-so" and, per your own case
study, is unable to retrieve the actual message content because the
*sender's* mail store is unreachable?

>JCB> it'll be hard to convince *lots* of people to leave their
>JCB> incoming email scattered all over the Internet instead of
>JCB> in their own in-boxes, safe and warm.
>
>Really ?  If having incoming mail stored locally on one's own machine is a
>feature that is highly prized by lots of people, how come Hotmail has
>customers ?

Because hotmail is available nearly 100% of the time, I would think,
and/or because those people don't want to keep their laptops on the
'net all the time and run *servers* that *accept* incoming email.

>JCB> I want my in-box to be ready, willing, and able,
>JCB> whenever *I* am.
>
>More double standards.  In the SMTP-based Internet mail system your inbox
>isn't available from everywhere that you might be (unless you provide
>encrypted POP3/IMAP service to the whole of Internet).

Yet, with IM2000 mail, your list of incoming message notifications
*will* be?

Okay, so maybe you've identified a "weakness" of the SMTP-based
system; but all IM2000 seems to do is add *another* point of failure
to it, namely, the *outgoing* message store.

>In the IM2000 Internet
>mail system your inbox is available everywhere that you might be because it
>isn't stored on _your_ machines at all.  It's distributed across a whole load
>of public-facing machines, which you can access wherever you may roam.  Just
>like the eyes on a painting follow one around the room without moving, an
>IM2000 inbox follows one around Internet without moving.

Yes, but without the list of incoming message *notifications* that
point me to all those nice friendly inboxen, what *good* does that do
me?

(Hey, maybe I'm about to discover my fundamental misunderstanding of
IM2000 here?  Anxiously awaiting a response on this important point.)

>JCB> IM2000 doesn't really help me all that much via its
>JCB> architectural differences from SMTP when it comes to making
>JCB> my *incoming* email less "friendly" to spammers;
>
>You haven't demonstrated that.  You've hardly discussed UBM from a
>recipient's perspective, at all.  Most of your discussions about UBM have
>centred upon the cost to senders, and have missed the point.

Nope.  You just haven't focused on my repeated discussions of how
little IM2000 improves things for most *recipients*, who'll need some
way to filter out UBM beyond just looking at the "From:" header and
the corresponding outgoing message store to make a decision.
--------


--------
Then he wrote:
>JCB> But if my SMTP server waited until *after* the DATA phase to
>JCB> temporarily reject a message, [...]
>
>Then there would be two copies of the message, one local and one remote, the
>entire message would have had to have been transferred across the network, and
>the remote end would be scheduled to send it _again_ at a later time.

Indeed.  That makes things a bit more tedious for everyone,
*including* the sender.

But note that IM2000 implies multiple copies of a message: IIRC, an
MUA may retrieve a message without taking responsibility for it,
display it, even store it.

>JCB> (And, again, this can't be done at all in IM2000-land if 
>JCB> the remote message store is unavailable.  I know a message 
>JCB> is waiting for me; I just can't see it.  I think that'd be 
>JCB> very frustrating.)
>
>Double standards yet again.  If network connectivity is unavailable, then the
>message couldn't have been sent via SMTP in the manner that you describe.

Of course it could have -- earlier, at the same time as IM2000 would
have sent the message notification.

>CC> If this happens more than once, I'll likely instruct my
>CC> notification agent to ignore notifications about messages on
>CC> foobar.example.com, /regardless of where the notification 
>CC> comes from/.
>
>JCB> Similarly, I'd likely instruct my SMTP server to permanently
>JCB> reject incoming messages from foobar.example.com, regardless 
>JCB> of relays through which such messages passed.  (Parsing
>JCB> "Received:" headers is a PITA, but it can be, and is, done.)
>
>This is where your attempt to make SMTP-based Internet mail do the same task
>stretches SMTP beyond its breaking point.  Trace headers can, have been, and
>are, forged.

Right, in which case, you don't trust anything beyond the "Received:"
header for a host which you don't trust to faithfully record that
info.  It's a basic trust issue, not inherent to SMTP's strengths or
weaknesses (except insofar as its strength is that it *does* provide
for recording relaying info, and weaknesses include that it does this
in the message content, not the envelope, and it's kinda hard to
parse).

>Whereas with IM2000 Internet mail there simply _is no_ relaying.

This has no negative effects on the transportability of an email from
a sender to a possibly-distant (in terms of network topography)
recipient?
--------


--------
Then he wrote:
>JCB> Why not create a protocol that allows for *each* message
>JCB> notification to include an optional resource identifier?  
>
>Because malicious senders will always choose SMTP-based Internet mail.

And recipients that don't agree to those terms will be able to reject
such proposals right off the bat.  (In a better world; I'm not talking
SMTP or IM2000, but something higher-level.)

>JCB> "I'm willing to store and later serve this message", or 
>JCB> "I want you to store this message", or "I'll pay you $.05 
>JCB> to store this message", or "You'll pay me $.10 to store and 
>JCB> later server this message, plus $.01 for each time you request 
>JCB> it without accepting responsibility for it", etc.
>
>Oooh!  Electronic postage stamps!  I summon the spirit of John R. Levine!
>Can you hear me, O spirit?
>
>(Hint: Where it says on my IM2000 anti-UBM page that other anti-UBM 
>measures have problems with the costs of enforcement, this is one 
>of the measures that it is referring to.)

Yet, after all this, it seems IM2000 is nearly indistinguishable from
employing several popular anti-UBM measures at once (increase sender's
burden; employ whitelisting, blacklisting, and so on, of envelope
sender addresses, SMTP client IP addresses, and so on, in order to
reduce recipient incoming mailbox size, etc.).

We can do better, IMO.
--------

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