Re: Inexpensive anti-spamware/anti-verminware tactic

>Wrong.  It makes things better.  Like James, you aren't measuring the right 
>thing.   I'll say it again:  Sending is cheap.  It's the benefit that 
>Internet has.  We want it to remain cheap.  So we create a mail system that 
>_takes advantage_ of that, to replace the one that it confounded by it.  

So, sending UBM is cheap under IM2000, just like under SMTP.  But
that's not a problem, you say; tell that to Charles, who seems to be
under the illusion that sending UBM (and thus storing it on an
originating mail store that is not widely ignored) is more expensive
under IM2000 than under SMTP.

>James is stuck on the erroneous idea, that you repeat, that penalising 
>senders is the goal.  But it is not.

I've never claimed penalising senders is the goal that I can recall,
except insofar as I've quoted and expanded upon your own web page and
on what Charles (and possibly others) have said.

Now, if IM2000 doesn't make sending UBM more expensive, then UBM
continues to be sent.  And if IM2000 doesn't make *receiving* UBM more
expensive, then UBM continues to be received as well.

Why are people going to upgrade to IM2000, again?  Just so they can
avoid storing incoming email from sources that fit the following
criteria?:

  -  Sender identity and IP not whitelisted

  -  Recipient identity not whitelisted

  -  "Subject:" header (if this is allowed by IM2000; Charles seems to
     say yes, I assume you call it a covert channel) not whitelisted

  -  Outgoing message store not whitelisted

These *all* must be true for an email to fit the conceptually useful
model in which IM2000 avoids *pulling* the message, in many cases, but
SMTP would most likely allow it to be *pushed*, into the local
recipient's in-box.  (Here, the recipient is assumed to want assured,
"instant" access to his *good* incoming message content, instead of
depending on an external outgoing message store that he did not
choose.)

After all, for cases where various envelope-level attributes place an
incoming email on a recipient's *blacklist*, SMTP can block that too,
just as it can avoid dumping an email into a recipient's in-box if it
determines, during or after receiving it, that it is excluded by the
recipient's criteria.  So IM2000 doesn't really offer an advantage for
such emails, except for cases where the notification/envelope info
tells the server about an original outgoing mail store that it knows
it doesn't trust, which, for SMTP, requires accepting the entire email
and parsing the "Received:" headers in it.

>Tracking mail delivery, without having to rely upon a chain of
>intermediaries and upon the remote end, and without having to inject further
>messages into the system that aren't necessarily going to be delivered
>reliably themselves, gives a benefit to non-UBM senders.  Remember them ?
>In all of these discussions claiming that it's so terrible that the costs to 
>senders aren't drastically increased, they appear to have been completely 
>forgotten.

Except that I've said several times that this is an area in which
IM2000 improves substantially upon SMTP.

I'd *love* to see a protocol without bounces replace SMTP.  If that
could be IM2000, or something like it, great -- I'm really worried
about the feasability of that, obviously, especially the "must pull
message content" aspect of it.  Seems like hardly anybody else is,
though, so maybe I'm just a worry wart.

>JR> Bear in mind that it is highly unlikely the spammer would be
>JR> running "proper" message store software.
>
>The whole trust model of IM2000 is that recipients know that message stores 
>work for the senders, and so expect some message stores to be in collusion 
>with malicious senders.  The design accounts for this in a lot of places 
>(Read the section on notification processing policy and the case study of 
>reading mail, for starters.) and people are already familiar with the ways 
>of dealing with this problem.  After all, the same is true of web servers.  
>Malicious web site authors can and do run content HTTP server softwares that 
>do underhanded things (like present one page to Google and another page to 
>everyone else).  People who don't like the web pages simply ostracise those 
>web servers.

I wish I knew how they did that.  I don't know how to do it, and don't
really have the time to research it.  My browser doesn't seem
particularly cooperative, either; I'd have thought Mozilla in FC1
would know better than to let some web site refuse to let me close
windows by automatically popping up new ones, but it doesn't, and I
can't seem to turn that off without completely disabling JavaScript.

That's what worries me about depending too much on ordinary IM2000
users being sophisticated enough to know how to precisely designate
the undesirable characteristics of a given piece of email, or their
MUAs being poorly designed, or whatever other problems might result.

But I think IM2000 is more ductile than C/R or SPF, though I haven't
really thought through the issues all that well (and being unable to
send email when you can't contact your own outgoing message store
seems like a potential problem for roaming users).

>JR> I think storage space is a complete red herring here.
>
>Storage space is one of the several costs that IM2000 addresses, and it is far 
>from being a red herring.  I suggest that you listen to mail administrators 
>complaining about how much disc space they have to devote to their mail 
>queues, for a while.  And if you still don't understand, I suggest that you 
>ask a mailbox-hosting ISP why it places quotas on its customers' mailboxes.  
>And if you _still_ don't understand, don't delete any messages from your 
>"jon+usenet" mailbox and remove all quotas from it.

Storage space for *outgoing* email will likely become an issue -- read
the concerns I have about convincing remote sysadmins to not only back
up, but later restore, *your* incoming email that you have left on
*their* outgoing mail stores.

Meanwhile, as long as recipients insist on reliable, instant deliveryo
of incoming message content, IM2000 won't truly "address" the
storage-space issue.

>JR> It seems me that IM2000 increases the cost to the recipient. The
>JR> recipient has less information about the message to make their
>JR> decision as to whether or not the message is something they want to read. 
>
>False.  If it is required, the recipient has the same information to work
>with as can be obtained via "TOP 0" in POP3.  Read the case studies and the
>design principles.  The advantage of IM2000 is that refusal of unwanted 
>mail can _also_ occur, under the direct control of individual recipients, 
>_without even that much_ information having been transferred.

Is this a wide-enough band of likely possibilities to be worth the
deployment?

It won't be if most readers of IM2000 insist on their servers caching
their incoming email, especially if ISPs, as many likely will (if they
even bother to offer IM2000), "promise" users that their incoming
email will "always be there, even in case of external network outage",
in order to allay fears about not being able to read mails one has
been notified about.

>JR> If they decide they should read a message, there is then a 
>JR> (potentially indefinite) delay while it is fetched from its 
>JR> remote message store. 
>
>Just like the cases with POP3, IMAP, "web mail" systems, and mailboxes
>hosted on Microsoft Exchange.  (Ironically, I experienced a delay of several 
>hours fetching mail from a POP3 server just yesterday.)  If you want red 
>herrings, _that_ is a red herring.

No, because in *all* those cases, *recipients* have chosen those
systems and technologies.

With IM2000, *senders* choose the systems and technologies
*recipients* will use to obtain email sent to them.

Or are you actually looking *forward* to the day that you can't read
half your incoming email because it's hosted by various servers all
running "Microsoft Exchange IM2000", or whatever it'll be called?

For myself, it won't be a problem; I'll just have my IM2000 server
automatically transfer all incoming email to my in-box, just like with
SMTP.  Which defeats the storage-space advantages of IM2000 over SMTP,
but that'll be *my* choice.

Of course, if the *sender* can't reach his outgoing message store, he
won't be able to send me the (IM2000) email in the first place, even
if he can reach *my* IM2000 server!

But that's *his* problem; he chose IM2000, and he chose that message
store for his outgoing email.

;-/

>JR> In fact UBE messages are likely to frequently have delays at 
>JR> this point because the spammer's message store has been detected 
>JR> and taken off-line. 
>
>False.  The "connection refused" or "unable to find a server to connect to" 
>response would be immediate, just as it is when one tries to point a web 
>browser at <URL:http://unequivocal.co.uk./>.

That depends on *how* and the *extent* to which it was taken offline,
actually; another response to a dDOS (an inadvertent or intended
result of an outgoing message store becoming hijacked in order to host
spam and/or vermin) is that it stops responding to incoming requests
for messages quickly or at all.

Meanwhile, for who-knows-what other reasons, I've seen plenty of
longish delays pulling up web sites, using URLs from sites like
google, slashdot, etc.

Heck, just the additional DNS lookup(s) required to "pull" email from
a message store represent another point of failure.

In other words, if your DNS ain't working right, you probably won't be
able to read lots of your incoming messages.

(That sounds kinda like what happens when people deploy SPF, except
SPF on top of flaky DNS means *sending* doesn't work right; and the
portions of DNS SPF relies upon to work are less widely tested, TXT
records being not nearly as widely and correctly supported as A
records.)

>JR> So the process of extracting your good messages from the UBE in 
>JR> your mailbox is more complicated and takes longer than under the 
>JR> current mail system.
>
>Being based upon an incorrect analysis, this conclusion is false.

Looking at your web page, it sure *seems* to be true; either the
recipient is carefully choosing whether to request a "pull" of each
and every message, after first determining whether it should be worth
getting, in order to extract "good" messages from UBE, or all the
messages are already sitting there, a la push-style delivery; though
they might just be cached, they certainly represent a similar amount
of space in the recipient's in-box.

Now, your case study is probably misleading in that it focuses on a
"mailx" replacement.

But I'm thinking of Emacs "rmail" and wondering how in the world
IM2000-style mail reading will be practicable when I'm already used to
using "n", "p", "d", and "^d" (Control-D ;-) to do the essential
navigation between email messages in my in-box, whether I'm doing that
within the message window or the message-summary window.

(For those who don't know this model: I run "rmail" under Emacs, it
pulls in all my email and puts the first one up in my main window,
complete with headers and content.  "n" and "p" go to the next and
previous messages, respectively; "d" and "^d" delete the current and
then go to the next and previous messages, respectively.)

>* True, but artificially increasing the cost of the Internet mail system 
>  is not the goal.

I can easily design a new protocol that substantially *decreases* the
cost of the Internet mail system, especially for senders, *especially*
for senders of BM (U or S); but it wouldn't depend on a "pull"
paradigm, though it would probably offer one as an option.

Given that possibility, why deploy IM2000, which *restricts* everyone
to a "pull" paradigm, and which therefore introduces another major
point of failure (the outgoing message store) for all message
exchange?

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