Re: Comments on IM2000

It was thus said that the Great James Craig Burley once stated:
> 
> LKML then sends a tracking request out to each of the remaining
> recipients about a minute later.  Assuming they work pretty much as
> they do today, they'll have committed the messages to disk, done any
> preliminary O(N)-type scanning of content, and accepted the messages,
> so they'll respond "I've accepted responsibility".

  See, this is where I don't understand the tracking mechanism.  Today, you
(more or less) have

	MUAs -> MTAs -> MTAr -> MUAr

  I don't see any real difference with SMTP now and what you are proposing,
except for the overhead of polling ("Did Bob get this yet?  Did Bob get
this now?  What about now?  Now?  Did he just read his email?") and a
possible annoyance factor [1].  I would also think this tracking mechanism
would be quite expensive for a large mailing list.  Now, for each outgoing
message you have *two* connections, one for the sending of the email, and
then another one (or two, or three) constantly nagging the other end "Did
Bob get this?" (okay, maybe not that often, but still ...).

> Only two more tracking request per remaining recipient would be sent,
> assuming the recipients didn't respond.  The LKML server would,
> presumably, treat inadequate response by any recipient after the final
> tracking request as it would if it received a bounce in today's
> system.

  I understood the IM2k method as working like this:  LKML would send out a
notification of email to each recipient:

	MTAs -notice->  MTAr1
			MTAr2
			MTAr3
			MTAr4
			...

  As each person then logs in to check their email, they receive
notification that there's an email waiting for them from LKML:

			MTAr1 -notice-> MUAr1

  User selects "Yes, I want to read that":

			MTAr1 <-getbody- MUAr1
	MTAs <-getbody- MTAr1
	MTAs -body->	MTAr1
			MTAr1 -body->	MUAr1

  LKML now knows that Bob just read the email.  LKML can keep track of the
number of recipients that have actually *read* (read:  requested) the body,
and delete the message from the store once everybody has read it, or just
expire it after a period of time (much like NNTP).  Or keep it---hey, it's a
mailing list.  

  Going back to individuals sending email, it works simularly.  Alice sends
Bob an email [2]:

	Alice -send-> 	Iago
			Iago -notice-> 	Ibby
	Alice <-stored- Iago

					Ibby -notice-> 	Bob
					Ibby <-getbody-	Bob
			Iago <-getbody-	Ibby
			Iago -body->	Ibby
					Ibby -body->	Bob
	Alice <-recv-	Iago

  (that last step assumes Alice is online at the time---otherwise, the
notification can happen the next time she checks her email).

> Since handling an incoming bounce is inherently much more expensive
> than sending a tracking request and receiving a response (or waiting
> for one that doesn't arrive), the question is how does the ratio of
> all those tracking requests and responses compare to the (presumably
> smaller) number of actual bounces?
> 
> The third-party costs are lowered as well, because sending bounces or
> DSNs requires DNS lookups in the *reverse* direction.  That's
> conceptually a waste of resources (DNS caches), since bounces/DSNs
> aren't really *original* communications, they are *responses* to
> communications.

  Sending the intial email requires DNS lookups to begin with---actually, a
minimum of two (one for the MX record, then for the A record of the MX
host) and possibly more.  I don't see this as being a major issue.

> Tracking requests and responses would not be DNS-addressed -- they'd
> be more ephemeral than bounces. 

  Um ... how else do you know who to send the tracking requests to? 
Granted, IP addresses may not change that often, but they do change
(renumbering, moving to a new provider, etc).

> >  -spc (And what's with the tracking anyway?)
> 
> Not sure what you mean by that.  Don't you track important packages
> you send via FedEx &c. using their online web sites?

  Um ... nope.  Nor do I track regular snail mail (is that even possible?)

> It does seem as though IM2000 wouldn't provide any tracking at all,
> beyond an indication to the sender of whether the message was
> unpinned, and possibly of who (as in IP address) has retrieved the
> message.
> 
> Such information seems to require some kind of handshaking between the
> sender and the message store to take place, however -- it seems too
> "remote" to me to be sufficiently reliable.
> 
> That's why I keep coming back to wanting direct MUA<->MUA
> communications, which takes me away from *presuming* there'll be large
> monolithic third-party systems, stores, data bases, etc. that enable
> email exchange.  (Although, in practice, even under my proposal, such
> entities would likely exist, though more to add value in various ways
> than to merely *enable* email exchange, as IM2000 and, increasingly,
> SMTP seem to do.)

  Well, until IPv6 become common, don't expect full peer-to-peer
communications on the Internet [3].  

  -spc (Who sadly remembers when he had 32 static IP addresses routed
	to his home ... )

[1]	Years ago I worked at IBM and used its internal email system (not
	SMTP based---some proprietary mainframe format that required users
	to log *into* the mainframe before checking) and it had tracking
	capabilities much like you mention and believe me, I *hated it*. 
	Managers (and team leaders) would routinely mark their email with
	return receipts indicating not only when I received it, but when I
	*read* it.
	
	A friend of mine found a way around the tracking mechanism though (I
	think by reading the spool file directly but it's been way too many
	years).  Just because *you* want it doesn't mean *everybody* wants
	it.

[2]	Cast of characters:

        Alice
        Bob
        Carol
        Dave            - regular users of email.

        Matilda         - sends out mass numbers of *wanted* email (a
                          mailing list for example)
        Sam             - Spammer
        Trent           - trusted authentication source

        Iago            - runs Alice's ISP
        Ibby            - runs Bob's ISP
        Ichabod         - runs Carol's ISP
        Idelle          - runs Dave's ISP
        Immanuel        - runs Matilda's ISP
        Isabel          - runs Sam's ISP (not knowing Sam is a spammer)
        Isam            - aka Sam, running his own ISP
        Itani           - runs Trent's ISP

	Names can reference the people themselves, or the machines they run.

[3]	Yes, the Internet was designed to be peer-to-peer, but since 1994
	it's become less and less peer-to-peer, what with firewalls, NAT and
	the assumed scarcity of IP addresses.