IM2000: what it is and isn't

On Mon, 8 Mar 2004 11:47, Jon Ribbens wrote:
> Firstly, "cost to sender". UBE only exists because the cost to sender
> is low. Clearly if the cost of sending an email were somehow increased
> sufficiently, UBE would become unprofitable and the problem would be
> essentially solved.

This is all true, but I think you're following the wrong trail. The problem of 
spam is "rule #0: spam is theft". So long as the only costs involved in spam 
are applied to *willing* senders and *willing* recipients, it really doesn't 
matter what the cost is. So long as there are no unwilling participants, and 
non-participants are not bearing any costs, cost is irrelevant. The problem 
is not cost; it is cost-shifting from willing participants to unwilling 
participants and non-participants. It is the cost-shifting that is the 
primary concern, not the cost itself.

IM2000 potentially decreases all costs, since there are no bounces, and mail 
which is known to be unwanted is not sent over the network. SMTP can be 
operated in a somewhat similar manner if the MTA network is appropriately 
configured, but it typically isn't. For example, the IM2000 "pull" approach 
works better for forwarded mail. Forwarding in SMTP results in problems 
unless the policy of the final recipient is applied at the first recipient, 
and any system which retro-fitted such a policy-sharing mechanism would be 
more complex than the IM2000 approach.

> Furthermore, since the spammer will clearly be operating their own
> message store, they receive the great benefit of knowing who has
> decided to read their messages.

Slight correction: the sender knows which entities have *fetched* the mail, 
not whether they read it. Whether or not the recipient also read it depends 
on whether the fetch happened as the result of an attempt to read, or simply 
as a matter of pre-fetching for some other reason (such as to run through a 
spam filter). The spammer also knows which entities accept their mail under 
SMTP, but not whether they read it. Information about reading is best 
obtained by some other channel entirely, such as HTML mail and web bugs.

> The spammer wants to send the *same* message to a large number of
> people, so the message store will only have one copy of that message
> and just return it to any client that asks for a message, regardless
> of the message identifier.

Granted, IM2000 makes it feasible to send out templated mail in a highly 
efficient manner, since the mail can be generated on demand. Contrast this 
with SMTP in which it must be generated and sent over the network whether it 
is wanted or not. IM2000 reduces the cost to the network as a whole. You 
could argue that it also reduces the cost to the spammer as a result, and 
this will be true in those cases where the spammer isn't stealing third party 
resources to fuel his engine in the first place.

> Secondly, "cost to recipient". UBE is only a *problem* because the
> cost to recipient is high.

Actually it's a problem because the recipients are unwilling participants, but 
let's look at costs, briefly. Costs involved include end user time, end user 
bandwidth, MTA storage, MTA bandwidth, MTA processing power, ISP support 
costs, and so on. This is an end-to-end process, and although the middle is 
invisible when it works, it still results in costs. If an implementation of 
IM2000 cut all mail-related bandwidth in half, then that would be a benefit 
even if it had no impact on end-user-visible spam at all.

> It seems me that IM2000 increases the cost to the recipient. The
> recipient has less information about the message to make their
> decision as to whether or not the message is something they want to
> read.

Despite thoughts to the contrary on this list, IM2000 is not a protocol: it is 
a broad theory of mail technology based around the "pull" principle. "IM2000" 
is just DJB's catchy brand name for pull-based mail. Be careful whether you 
are arguing against IM2000 itself, or someone's attempt at implementing it. 
What you're arguing against here is a particularly bad way in which one might 
implement IM2000, rather than the principle of pull-based mail generally.

Sure, if your implementation of IM2000 effectively meant "mail a URL to the 
recipient using SMTP", then that would be a lousy implementation, although it 
still obeys the overarching principle of IM2000, in which the recipient 
domain pulls the message content from the sending domain. It's also possible 
to turn SMTP into a pull-based system which is only marginally different to 
push-based SMTP: see my BSc(Hons) thesis at the following URL.

  http://www.comp.mq.edu.au/~brett/bschons/index.html

> Finally, sender authentication. This is the problem that things like
> SPF try to address. ... IM2000 does not address this issue in any way
> so far as I can see.

IM2000 does not address the issue directly, but it does offer a firmer 
foundation than SMTP for an authentication layer. SPF is, necessarily, a 
horrible ugly hack. It uses the envelope sender field as an identity, and the 
envelope sender field was never intended to be an identity. The envelope 
sender is just the address to which the originator wants bounce messages 
delivered. A new mail protocol which uses IM2000 principles is in a very good 
position to overcome this problem, since it can include a "message 
originator" identity field, and authenticate that identity. (IM2000 has no 
need for an envelope sender field, since there are no bounces.) An SPF-like 
authentication system for IM2000 would restrict associations between message 
originators and IM2000 message stores.

Regards,
TFBW