Re: Comments on IM2000

James, thanks for those carefully thought-out comments.

I should say that the document I wrote was intended originally to consider
IM2000 and how it would interact with spam; its scope has already crept to
include other random thoughts on IM2000. It certainly wasn't intended to be
a design for a FUSSP :-)

In reply to some of the points you raise:

* The trouble with Artificial Intelligence is, it isn't. Today, AI basically
means tree-searching and pattern-matching algorithms. Maybe in 50 or 100
years time, there will be AI which actually *understands* documents (and
people) at the highest semantic level; until then, I wouldn't trust it to
make any value judgements on the content of my mail. And if it really *did*
understand my mail, I probably wouldn't want it to be reading it anyway :-)

* It's an interesting point that the real criteria as to whether spam is
wanted or not is based on the content. However, I think you're imagining a
future world where a significant portion of bulk E-mail is sent from
legitimate businesses that you might actually want to deal with.

From my own experience, the vast majority of spam is downright fraudulent.
Even if I saw something in a spam that interested me - taking your example,
it was talking about saving the Brazilian rainforest - if it asked for a
donation of $20, there's no way I'd send it. That's because (a) the spam is
almost certainly fraudulent, difficult to trace, and the $20 would just line
somebody's pocket; and (b) conversely, I know that any legitimate
organisation which was active in this area, would not dare to send spam.

Therefore, the fact that it's received as UBE *automatically* classifies it
as uninteresting to me, regardless of content. And so it should for everyone
else; unfortunately, even with a hit rate of 1 in 1000 or less, there are
still enough born every minute to make it worth the fraudulent spammer's
time. The other 999 spams cause huge annoyance, but the law enforcement
agencies at present seem completely disinterested in tracking down these
fraudsters - even when the spams include postal or telephone contact points
which would be easy to trace or sting.

* There are I think a large proportion of people who would rather see no
advertising at all in their inbox, even if some of it might be of interest
(e.g. special offers or discounts from legitimate companies that they might
want to deal with)

There's a parallel with the real world. In the UK we have this thing called
the "Mailing Preference Service". All marketers who follow the Direct
Marketing Association code of practice are required to pre-filter their
mailshots and remove all MPS-registered people from it.

It's remarkably effective; the amount of junk paper mail I get is now very
low (and the credit card offers and the like that I still receive go
straight into the bin, as I know the company does not follow the DMA code of
practice). And when I tell someone about the MPS, almost without exception
they are completely delighted and register immediately.

I think you're right that we suffer from information overload; and
advertising is for most people the lowest form of information. Many people
are happy to accept the risk of losing out on an advert that might actually
interest them, for a reduction in the total amount of advertising that they
are bombarded with.

There are other services (the "Postal Preference Service" having being set
up by the direct marketers with an intentionally confusing name) which allow
you to register your interests and opt-*in* to receiving direct mail in
categories of your choice. The Postal Preference Service is sponsored by the
Royal Mail, who have a pretty obvious interest in expanding the use of
direct mail advertising :-)

I do occasionally receive chain letters and lottery frauds through the post.
However it's rare because the cost involved is that much higher than
spamming.

I think a similar kind of classification could work in the on-line world:

  - Bulk mail, untrusted sender
      => probably fraudulent (= chain letters)
  - Bulk mail, classified as legitimate advertising by trusted third party,
    classified by subject area
      => can choose to reject based on the fact it's advertising (= MPS)
      => can choose to accept or reject based on subject area (= PPS)

Such systems would work because you are not having to assess a level of
trust in potentially thousands of different organisations or individuals
trying to contact you each day, down to a handful of agencies who sign and
classify 'legitimate' advertising.

There's an SMTP service extension proposed for this (RFC 3865). I don't
think it will work unless it's combined with a whitelist - i.e. do a
third-party lookup to see whether mail from IP address x.x.x.x is
trustworthy with regards to its solicitations. And I think that would be a
lot less effective than the third party signing the message itself, rather
than asserting that all messages from a particular source are correctly
labelled. In particular, it would not work for messages sent via a shared
SMTP relay (smtp.example.net)

Spammers, of course, are not going to have any incentive to label their
messages according to RFC 3865 - they might as well label their IP packets
with the Evil bit (RFC 3514). So the only effect that RFC 3865 will have is
increased advertising presented to our mailboxes, albeit from more
'legitimate' sources. If spam is not correctly labelled, then you still have
all the existing difficulties with SMTP of tracing it back to source.

* While we are in a situation where on-line identities can be created at
will, and assuming you would like to be able to receive mail from people who
have not dealt with you before, whitelisting is not very useful for
controlling spam. It would require a network of trust which would prevent
individuals creating large numbers of identities at will; the identities
would have to be bound to a personal or corporate identity (and even
corporate identities would be weak, since companies can be created without
too much difficulty of expense).

Hence all E-mail senders would have to get their new on-line identity signed
by (say) their upstream ISP, in turn signed by some central authority; and
then unless you want to evaluate the trustworthiness of all those ISPs and
central authorities, you'd probably need a third party to do that for you
too.

I don't think many people will accept that they can't send E-mail unless
they've first had their identity checked.

However, it might be reasonable to receive mail only from domain X only if
the owner of domain X has got a certificate, and the existing X509
infrastructure would be fine for that.

That is, if I receive a mail from [email protected], I could expect it to
have a certificate for mybank.com; and if I receive a mail from
[email protected] ISP, then at least the example.net ISP would have a
certificate.

IM2000 could do this at the transport layer, by requiring TLS and a valid
signed certificate before you download sent mail from a remote message
store. The big financial winners here would be the CA's of course :-) I
think there would need to be a free 'test CA' that you could get
certificates signed for initial testing, but in general MUAs would not
accept test CA certificates.

There's ESMTP STARTTLS, but typically it works the wrong way round: when
sender A connects to recipient B, B presents a certificate saying "I am B".

B *can* be configured to require A to present a valid client certificate.
However I don't think you'd ever get to a stage where you could safely
reject incoming mail because the sender doesn't have a certificate; partly
because a critical mass of MTAs with client certificates will not build up
unless there is a driver to do it, and partly because a lot of MTA software
out there is not sufficiently flexible.

In any case, the trust model is weakened somewhat by relaying. If mybank.com
choses to relay via smtp.example.net, then at the receiver all I'll get is a
certificate for smtp.example.net. And then the return address you see, e.g.
MAIL FROM:<[email protected]> is not validated at all by the certificate.

Using domain certificates is not going to help spam much anyway, if:
- spammers send out mail from 0wned machines with upstream ISP accounts; or
- spammers get lots of domains and certificates (although then new CAs
  may spring into life, whose remit is to sign only non-spammers domains)

However, it might stop spammers setting up mailstores on 0wned machines,
which would definitely be a good thing. If you want to run your own
mailstore, then not only do you need your own domain, but you need a
certificate. That's quite a high hurdle to jump; it might mean we have
fewer, larger mailstores in practice.

> Given that we'll never see this ideal world, and that latencies (as
> well as outages) *are* a huge problem, we then move on to the One Big
> Problem with IM2000 -- that of the end user seeing substantial delays
> when trying to pull up any given message after clicking "read" on a
> notification panel.

Yep, there's a real-world tradeoff here.

At the moment, people expect their POP3 server to be reliable and available
99.9% of the time (or perhaps to be offline at 3am when few people are using
it). If it isn't, then they complain to their ISP. If the ISP doesn't sort
their act out, then they change ISP.

With IM2000, if you have problems downloading your incoming mail, the fault
is at the remote ISP, which you have no control over; your own ISP can
happily point the finger. Worse, even though it may be 3am in the sender's
timezone, it may be the middle of the day in your own timezone. In many
parts of the world, Internet links are still highly congested and mail may
only successfully get out at certain times of the day.

So IM2000 assumes the Internet to be 'reliable' - perhaps moreso than it
really is.

>   Therefore, a receiving party can always choose to not confirm it
>   received the message, even though it did.  (The sender can insist on
>   breaking the message into a series of distinct message chunk,
>   sending each chunk only after receiving confirmation that a previous
>   chunk has been read; this doesn't really solve the problem for the
>   final chunk, and makes the transmission protocol much slower, as
>   latencies become amplified in their effect.)

And in any case, the receiver could send back automated
confirmation-of-reading messages to spoof this protocol.

>   a *sender* should be able to control just how
>   "persistent" his outgoing MUA is in terms of notifying the recipient
>   about the message being available, checking on the status of
>   delivery, and so on.
> 
>   IM2000, as presently formulated, really doesn't offer much more
>   flexibility in this regard than does SMTP.

I think in principle it does; a message in a message store is labelled with
how long you want to keep it there, and it could also be labelled with an
indication of how aggressively you wish to retry. There's a little of this
sort of stuff in ESMTP DSN, but I don't think it's that widely implemented
in MTAs, and less so in MUAs.

>   An advantage to giving senders a wider range of options when it
>   comes to notifying and inquiring about outgoing emails is that it
>   allows *recipient* systems to actually "bias" their prioritization
>   of incoming emails based on the apparent persistence of the sender.

But I don't think that any precedence or priority flag assigned by the
sender has any value in absolute terms.

I think it may have value as a [sender,priority] tuple. That is, if I
receive a mail from [my boss,Important] then I may treat it as important.
But mail from an unknown third party labelled as Important almost certainly
isn't. In fact, I would probably apply a negative weighting; the more
important the message screams that it is, the less important that it is
likely to be. Consider counting the exclamation marks in spam subject lines
:-)

> After all, UBE is really just a subset of UBI (Unsolicited Bulk
> Information), in the sense that UBI includes spam posted to blog and
> other web sites allowing posting of arbitrary anonymous content, as
> well as to USENET.  So the fight is really not *just* in the email
> arena, and many of the techniques used in that arena have plenty of
> applicability elsewhere (and, presumably, vice versa).

True. I think E-mail does have a special place, primarily because it's an
on-line analogy to a physical service we're all familiar with, and because
private one-to-one store-and-forward communication is an extremely useful
tool.

If you read someone's website or blog, then you've made an active decision
to go there and participate. If there's advertising there, then so be it. It
may be because the blogger put it there, or because spammers put it there
and the blogger does not control them. If it annoys you enough, you may
choose not to participate there. However, one's inbox is considered
'personal space' and not to be infiltrated by advertisers, and especially
fraudsters.

It would be interesting to see a list of desirable features or
characteristics of the GUIXP system you describe.

Cheers,

Brian.