Re: Hello from a new subscriber was Re: Just Wondering...

On 2004-06-01 21:32:16 -0000, James Craig Burley wrote:
> Though it seems like ages since I wrote that, I believe at the time I
> was actually pointing in a different direction -- towards JdBP's im2k
> proposal, which prohibits things like a "Subject:" header in a
> notification.
> 
> That is: { To: From: Date: }, tightly controlled fields, and nothing
> else (aside from the necessary glue, e.g. message store identifier,
> not normally shown to end users).

I agree with that.

> >>>A spammer tries to forge an email sender.  Result: your client can't pick
> >>>up an email from a server that doesn't exist.
> >>
> >> That's a big advantage of im2000.  Although, I think you mean "tries to
> >> forge an outgoing message store"; im2000 per se doesn't really "care"
> >> about the identity of an email *sender*, or does it?
> >
> >yes it does.  im2k message are supposed to be authenticated by a (possibly
> >PGP) key.
> 
> Really?  That's news to me.
> 
> But, then, why not just authenticate SMTP messages?  In fact, aren't
> people doing that *now*?

Yes, but only a few.

> Couldn't we then just slowly migrate to that
> model, if it's sufficiently useful?

Not without help from Microsoft. 

The large majority of users are using either Outlook or Outlook Express.
These mailers don't support PGP out of the box, and S/MIME is awkward
to set up (You have to generate a certificate request, send it to a CA,
prove your identity, wait for the certificate, import the certificate).

So most people won't use it. And if most people don't use it, you cannot
filter on it. End of story.


On im2k, however, there is no installed base which has to be convinced
to switch. Build cryptographic signatures into the protocol and
everybody will have to use it.

The notification should contain To:, From:, Date;, the message store
identifier, a hash of the message and be signed with the private key of
the sender. 

Then the recipient's agent can check whether the notification is consistent
(signature matches content, and key owner matches from) when the
notification is received and discard all forged notifications without
retrieving the content or bothering the user. If the notification is
consistent, the message will be retrieved and compared to the hash in
the notification. Only if this compares ok, the message is shown to the
user.


So what prevents a spammer from signing his messages? Nothing. But a web
of trust can be used to determine whether a given address is likely to
send "interesting" messages to a recipient. I wrote up my ideas about
that matter some time ago:

http://www.hjp.at/projekte/mail-wot/outline.rxml

	hp

-- 
   _  | Peter J. Holzer    | I think we need two definitions:
|_|_) | Sysadmin WSR       | 1) The problem the *users* want us to solve
| |   | [email protected]         | 2) The problem our solution addresses.
__/   | http://www.hjp.at/ |    -- Phillip Hallam-Baker on spam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAvUMffZ+RkG8quy0RAry7AJ4/veAZtZdCgIXJm5+APpnXVdvVnQCggHCO
sxPrf0C1dlNGY2AsZ4r7V+g=
=9h1B
-----END PGP SIGNATURE-----