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

On Thu, Feb 23, 2006 at 11:57:02AM -0600, Bryan Campbell wrote:
> This is all very insightful and entertaining, but, could we just stop.
> 
> It is obvious that there are a great many ways to exploit e-mail 
> systems.  The current systems are abused daily.  And, we can all think 
> of ways in which IM2000-ish stuff could be abused.  So, why don't we 
> think outside the box a bit.
> 
> For example.
> 
> Can we augment, or work around, the current e-mail systems MTUs and MUAs 
> to give end-users anti-spam features without having to re-write the 
> whole guts of the internet.
> 
> For example . . .

. . . see http://www.rhyolite.com/anti-spam/you-might-be.html :-)

Seriously: consider the question, "what do people want from E-mail?" At the
basic level for this discussion, I'd say the key ones are:

1. People want to receive E-mail from their real-life buddies and
colleagues, plus people they've only meet via the Internet (e.g. on mailing
lists, E-bay, dating sites, chat rooms etc), without any of it being lost,
and preferably with rapid delivery.

2. People don't want to receive E-mail from scammers, fraudsters, phishers,
worms, viruses etc

3. People may or may not want to receive advertising or special offers from
legitimate businesses [this is a personal choice]

So setting aside point (3) for the moment, they want an E-mail system which
can tell the difference between mail from someone who is friendly or somehow
beneficial to hear from, and someone who is malicious or irrelevant. I
assert that there is not a technical solution to this problem.

> use a formatted message notification with checksums, 
> signatures and other information.  Make a Thunderbird/OE/O/whatever MUA 
> plugin which will recognize a properly formatted notice and mark it as a 
> properly formatted notice.  The notice must have truly identifying 
> information in it which cannot be forged.

What sort of identity? A government-certified "this person's birth
certificate contains the name Thelonius Q. Wildebeest?" Or an ISP-certified
"this person has E-mail address [email protected]"?

In the first case, it means that once a spammer has been identified, you can
permanently block all mail from that person ever again. However, I believe
that people won't use E-mail if it involves visiting their local government
agency in person and producing their identity credentials just to get a
certified E-mail address.

In the second case, such E-mail addresses are trivially obtainable in bulk
by spammers. Therefore, the test "does this message come from a valid E-mail
account?" in no way corresponds to "does this message come from a friend or
a foe?"

Consider the situation say 10 years ago. Spammers used to send spam with
harmless but invalid return addresses, such as

   MAIL FROM:<abcdefg@hijklmnop>

The logic then went:

1. Almost all of my spam has an invalid domain in the return address.
2. All my non-spam has a valid domain in the return address. [*]
3. Therefore, if I block all mails with invalid domains in the return
address, then I will block almost all of my spam.

Lovely, so that's what everyone did. Of course, the spammers instantly
retalliated by changing their return addresses to use valid domains, or even
valid E-mail addresses (after all, big lists of valid E-mail addresses are
core business for a spammer). And so the "Joe Job" was born.

This is why sender validation techniques are bound to fail as spam control
measures. As long as spammers can create accounts at will, and as long as
there are thousands of ISPs in the world, most of whom don't bother to
process their abuse mail or to limit account creation, new E-mail addresses
will appear all the time. When you receive a mail from a new identity, how
can you know whether it's a friend or foe?

But it seems people are determined to implement this sort of thing (witness
DomainKeys and the like). So what happens when that's implemented? Well, the
next domino topples. Take Challenge-Response systems, for example. The logic
goes:

1. Almost all of my spam has a forged return address.
2. All my non-spam has a valid return address. [*]
3. Therefore, if I send a challenge to the return address, and the person
replies to me again, I can prove they sent the mail in the first place and
are not a spammer.

But by now, we've forced spammers to send from their own real accounts
(obtained by various means listed in a previous mail), which they can
generate on demand. So now of course they can collect and process the
challenges, and set up automated systems to send the responses, and so
spammers become indistinguishable from non-spammers to these systems.

[*] Actually, in my experience this is not true. I used to work for a UK ISP
which had a lot of old customers under a particular domain, I'll call it
example.net. Looking at mail relay logs, I could see mails from

     [email protected]
     [email protected]

which were basically misconfiguration of the client's MUA. Mails could go
out normally, but they would never see bounces. In the current world, now
many E-mail systems will reject their mail - but because the return address
is bad, the sender will never know. The message is simply blackholed.

The point here is: the test "is this sending machine properly configured?"
is no good as a test for "is this a friend or foe?" either. The same applies
to trying to cross match domains in HELO/EHLO to IP addresses, for example
(which incidentally is *not* required by RFC to happen in any case)

> Within the notice could be an 
> embedded link to allow for the person who receives the message to 
> acknowledge that they really do want the message.

And how do you know whether you want each message or not? What information
is presented to the user to enable them to make that choice?

The information I currently get in my MUA maildrop listing comprises
(claimed) sender name, and subject header. I certainly *can* make a decision
based on that as to whether I want the message or not, but it's a PITA to
have to keep doing that, and occasionally I do skip over mails which I
really wanted to see.

Regards,

Brian.