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

>I think I understand just about your entire argument, except for this:
>
>>   - Participating intermediate MTAs don't save bandwidth over the
>>     current system, when it comes to such a message.  In fact, their
>>     per-message burden increases, because they not only have to deal
>>     with the full message contents as with vanilla SMTP, they have to
>>     deal with a stub version of a message *and* at least one DNS
>>     lookup to obtain the full contents -- a lookup based on arbitrary,
>>     attacker-provided data (which has problems I've posted about
>>     before).
>
>It seems to me that HTMP even *with* obfuscation will still, on 
>average, decrease the per-message bandwith burden for intermediate 
>MTAs, when taking both upstream and downstream bandwith into account. 
>Or is there some reason of which I am unaware that it is proper to 
>exclude upstream bandwith from your calculation?

I think you're right.  Let me walk it through to see where I went
wrong.

In SMTP, the entire payload -- message notification, message contents,
and responsibility for delivery -- are (typically) transmitted from
hop to hop:

  A -> B -> C -> ... -> Z

So, for a 10MB message, with negligible additional notification goo
(envelope sender and recipient, SMTP handshaking), an intermediate MTA
such as C must:

  - Accept 10MB worth of data coming down the pipe from upstream (B)

  - Save 10MB worth of data on a reliable persistent storage device
    (usually a hard drive)

  - Transmit 10MB worth of data further downstream (to D)

With vanilla IM2000 or HTMP, replace 10MB above with, say, 1KB or so
-- nice savings.  Also, perhaps delete the "Save..." item, depending
on responsibility issues.  Nice win there as well, for each
intermediate MTA.

But add obfuscation to HTMP (or IM2000 -- basically it'd be the same
deal to achieve the same stated goal), and the amount in the
"Accept..." item above goes back to 10MB, plus change, plus at least
one DNS lookup.

What does *not* happen is that the amount in the "Transmit..." item
changes back to 10MB.  D doesn't need to get the 10MB from C; rather,
it gets it directly from A.  All C transmits downstream to D is the
message notification (and maybe delivery responsibility).  Only if D
is downstream of the same Internet-connectivity pipe as C does the
bandwidth savings disappear -- but I had already covered that
possibility in my previous post.


So, indeed, you're right, and I'm wrong -- a typical intermediate MTA,
employing retrieval solely (or largely) for obfuscation purposes, cuts
its *combined* upstream and downstream bandwidth utilization roughly
in half, when compared to SMTP.  However, it still increases it
substantially (in direct proportion to message-content size) over
vanilla IM2000/HTMP.


Having thought about the underlying (privacy) issues more since my
previous post, it seems the more pertinent incompatibility to which I
alluded near the bottom of the post is between privacy and *retrieval*
(in pull-based systems like IM2000, HTMP, and HTTP).

In push-based systems (like SMTP), the message contents having been
delivered to an intermediary (such as a mailbox) that the *recipient*
has already trusted to preserve privacy and the like, the message may
be retrieved at any time, by that recipient, without the sender
necessarily knowing it has happened.  That's because the sender has
little or no control over the message store.

But, as we can see in the above walk-through, push-based systems
require the entire message contents be "pushed" from hop to hop,
though that naturally helps obscure details about the recipient's
activities (and about intermediate MTAs as well).

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