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

>> I argued on my critique page that IM2000 would make spamming far cheaper for
>> the spammer. They only need to store *one* copy of the spam body on their
>> disk, and then send out as many notifications as they like. Furthermore,
>> inactive recipients will not retrieve the mail, so their bandwidth costs
>> will be minimised too.
>> 
>> Given that they will write their own IM2000 message store optimised for
>> spamming, they can choose either to send out the same opaque key to all
>> recipients, or to send out different ones. The latter case lets them track
>> who has read their spam and when, for a cost of a few bytes of storage per
>> recipient. A cheap 250GB drive holds a *lot* of recipient information.
>
>My obfuscation technique would eliminate both of those benefits to 
>spammers (by multiplying bandwith usage over current levels & filling 
>log files with useless information), but would require modifying MTAs 
>to retrieve every email they handle while masquerading as an MUA. So 
>definitely not an ideal solution, but a solution nonetheless. If you 
>can poke holes in it, please do.

It does seem to offer the advantages you cite.  By automatically
retrieving ("pulling") the stored message regardless of "need":

  - Each intermediate MTA helps confuse a reader of the message-store
    log as to whether a given retrieval represents an automated or a
    human retrieval.

  - The message-store system bears a greater cost for sending a
    message that goes through one or more intermediate MTAs when
    compared to the current system, because it has to transmit the
    entire message contents to each (automatically-retrieving)
    intermediate MTA.

It also offers disadvantages:

  - 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).

  - Participating intermediate MTAs sharing a given provider (upstream
    bandwdith) would, in fact, cause that provider to also bear a
    greater cost for *receiving* a message, since that set of MTAs
    would retrieve a message's contents multiple times via the same
    pipe.

  - Readers of message-store logs would have more visibility into how
    MTAs in internal LANs operated, in return for losing clarity with
    regard to exactly which retrieval is for human viewing.  So it
    would potentially be easier to see that recipient "bobsmith" is in
    a different department (different second or third intermediate
    MTA) than recipient "janejones", unless NAT or other (further)
    obfuscation techniques were used (meaning a shared provider bears
    a greater burden for multiple retrievals).

  - Either network connectivity and message-store availability would
    have to be higher, to accommodate a *series* of (arbitrary)
    requests from various MTAs, or intermediate MTAs would have to
    consider such retrievals to be secondary to their mission of
    forwarding the corresponding stub emails in order to survive
    failure to retrieve:

      o If forwarding stubs depends on obtaining message contents (for
        obfuscation purposes), forwarding is delayed or halted at each
        hop, depending on how long it takes to obtain the contents, if
        they are even available to that intermediate MTA at that time.
        An unavailable (even legitimate) outgoing message store thus
        causes mail queues to "back up" for *intermediate* MTAs,
        rather than at an end-user's Mail Agent (MTA or MUA), delaying
        delivery of legitimate mail further, potentially causing
        dropped or bounced mail if queues get too large.

      o Otherwise -- if forwarding doesn't depend on successful
        retrieval of contents -- stub forwarding (to the end user)
        might *complete* before even the first participating MTA
        finishes obtaining the message contents, which (on the plus
        side) "confuses" anyone reading the log file further, but (on
        the minus side) means the end-user trying to read a message is
        potentially competing with a number of intermediate MTAs for
        both upstream (if shared) and downstream (from the
        message-content provider) bandwidth to get its own individual
        copy of the message contents.

Those last points really get to the crux of the issue: What Problem
Are You Trying To Solve, that you're modifying a Store-And-Forward
protocol (SMTP), which was employed specifically to allow a message to
propagate from A to B to C ... to Z, without there ever having to be
simultaneous connectivity between any *three* points or any two
*non-neighboring* points, such that those very desirable properties of
storing and forwarding are rendered nearly useless (or worse)?

Vanilla IM2000 (and its less-efficient variants, like your *vanilla*
HTMP proposal), on the other hand, offers the rather blatant advantage
that only the *notification* is stored/forwarded, until it reaches the
endpoint.  Only when the end user retrieves a message need there be
any connectivity between that user's system (including intermediate
MTAs) and the originating message store.  (That still is a heavier
burden on the network than imposed by vanilla SMTP, but less than
imposed by HTMP with the obfuscation method you propose.  That is,
given the A->Z forwarding illustrated in the paragraph above, IM2000
adds the requirements that Z be able to contact A when the end user
wants to read a message.  Your proposal further adds the requirements
that B, C, ..., and Y all be able to contact A as they propagate a
stub email, aka notification in IM2000-land.)

When it comes to "privacy", I cannot see how to reconcile the idea
that a recipient must be able to accept delivery of a thing (a
message) without the sender being informed of that fact with the
concepts of reliability and ductility, which require that the sender
assume that the recipient has not taken delivery until a sufficiently
trusted confirmation of such receipt has been received by the sender.

Either the recipient somehow arranges to not make any untrusted
intermediate transfer agent aware of his taking delivery, or the
recipient must accept that the sender might indeed learn not just
*that* delivery was taken, but, to some approximations, *when* and
*where* it was taken.

In the former situation, the recipient must accept that a sufficiently
motivated sender will repeatedly attempt delivery until either receipt
is confirmed (via ordinary confirmation, or some other event,
observable by the sender, occurs that confirms receipt, such as
receiving a response to an email or seeing a web site get updated) or
will try to use some other means to transmit the message.

Since spammers don't generally care to use other means or go to any
trouble to gather data on receipt of individual messages, probably the
best approach is for recipients to be given the option of whether to
confirm receipt on a per-message bases, letting their MUA prioritize
or categorize messages to make such confirmation automatic or manual,
and perhaps letting the MUA use simpler obfuscation techniques (like
time-shifting confirmation of receipts).

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