Re: IM2000 Won't Be Worth It

>I think the main argument is eliminating bounce messages and
>simplifying mailing lists.

Eliminating bounce messages is orthagonal to the push vs. pull issue.

That is, receiver-side notification (bounce messages, DSNs) "works"
for a pull model of delivery just as sender-side notification
(explicitly tracking the status of an outgoing message) works for a
push model.

Simplifying mailing lists is also orthagonal to push vs. pull,
because, as you yourself noted, mailing lists can be special-cased
with regard to how notification is normally handled under IM2000.

The same can be done with the push model.  Upon receiving a new (and
approved) message to a mailing list, its manager simply pushes that
message to the entire network.  All "listeners" on the network push
that same message further down their subtrees, etc.

It sounds inefficient, but it isn't necessarily, in the presence of
various straightforward optimizations, and the resulting system, if we
had a new protocol (push-style, a la SMTP, but much better) that
implemented it, certain activities would be *much* easier to deal with
than they are today.

Further, the pull model *can* involve traditional list-style
subscription and recipient notification, of course.

So, from a meta-mail-protocol point of view, if my #1 and #2
priorities are eliminating bounce messages and simplifying mailing
lists, I will *not* immediately decide on a "pull" model over a "push"
model.

>Bounce messages are bad because they are widely mishandled today, and
>there is no realistic prospect for improvement.

If enough people switch to IM2000 from SMTP, SMTP users would no
longer be able to rely on bounce messages.  They would have to
implement some means to track the status of each outgoing messages, or
abandon SMTP in favor of IM2000 to send messages.  I doubt the latter
would be a sufficiently-widely-adopted approach such that SMTP would
not be so evolved by its remaining adherents, given the costs of
maintaining outgoing message stores, so....

...that implementation (SMTP plus allowing outgoing message tracking)
would undoubtedly track status of messages as they progress within the
portion of the SMTP ecosystem that has been upgraded, as well as the
entire IM2000 ecosystem.

Therefore, there *is* a realistic prospect for improving SMTP with
respect to bounce messages: go ahead and work on implementing
sender-side tracking, then start eliminating bounce messages.  "We"
can start work on that now.

That is, this can happen either as a result of, along with, or without
any need for, IM2000 deployment.

Similarly, "we" can start adding a "pull" option for delivering email
via an extended SMTP protocol, if we think it's useful enough.  (I'd
rather just move to a totally new protocol for that; IM2000,
especially if it offers a "push" option a la SMTP, seems an excellent
candidate.)

>I personally don't think IM2000 will help with the spam problem.  I
>find the various arguments on that front to be unconvincing--spammers
>have already demonstrated that they are highly adaptable, and I'm sure
>they would adapt to IM2000 as well.

But, if IM2000 proponents are so enthusiastic about its potential, and
have so many wonderful ideas about how to combat the problems we pose
with regard to dealing with rogue outgoing message stores, then let
'em have at it, and we can just "borrow" their ideas for making
push-style (SMTP etc.) delivery better, to the extent they'll work
over here.

(I still don't get why IM2000 *has* to be a *pull-only* model.  Make
it push or pull as negotiated by the sending and receiving
notification agents, and almost all the problems being argued about
here turn into arguments not against the *protocol*, rather against
particular choices that might be made by its users and agents.)

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