Follow US:

Practice English Speaking&Listening with: Turning Email Upside Down: RSS/Email and IM2000

Normal
(0)
Difficulty: 0

FEMALE SPEAKER: Hello, everyone.

We're fortunate enough to be joined today by Meng Wong and

Julian Haight.

And they are going to be discussing with us, Turning

Email Upside Down: RSS/Email and IM2000.

And Meng actually is the founder of Pobox.com, and

Julian is the founder of SpamCop.net.

So this should be a very interesting, engaging

presentation.

And I'll turn it over to these gents.

Thanks.

MENG WENG WONG: So, thanks for coming.

This is my first time at Google, and it's a real treat

to be here.

Thank you very much.

So, this project is really just a hobby project between

Julian and me.

It doesn't really have a name.

And it's kind of an idea that's been floating around

for a long time.

And so, people have been calling it things like IM2000.

I have been calling it RSS/Email.

You can call it Hypertext Mail Transport Protocol.

That's what Nathan Cheng calls it.

He wrote an article on CircleID a while ago.

We call it HTMP.

And we kind of came up with the name Stubmail after

awhile, or Stubbymail.

So, it's me and Julian.

We're going to talk about this.

Julian founded SpamCop.

How long ago, Julian, was that?

JULIAN HAIGHT: '98.

MENG WENG WONG: '98.

All right.

So.

You guys have heard of SpamCop, right?

Yes?

Good.

And I founded pobox.com back in '95.

And most recently, I've been working on a project called

SPF, which got embraced and extended by Microsoft.

So the basic idea here is, all right, let's start with the

idea that we've got this one thing, email, SMTP push.

And then, we could flip it around and say, instead of

doing push email, let's try and do pull email.

And there was a kind of a long tradition of doing pull

technologies now.

The web is basically pulling all this stuff on the website

and pull it out.

RSS does that, too.

And the way I see it, spam is basically an unsubscribe

problem, right?

If you go back about 10 years, to the early days of spam,

people are always like, stop spamming me.

Please unsubscribe me from your mailing list. And today,

we don't really talk about that very much.

But the idea is still there, right?

And we don't see this problem on the web with blogs.

You never complain, I subscribe to this blog, and it

keeps sending me stuff I don't want.

And I can't do anything about it, right?

You just unsubscribe.

You never say, I keep going to this

website, and I can't stop.

So if you think about email, the way mailing lists work,

it's like, I have to send a message to you to say, please

stop sending me stuff.

And that's completely backwards.

It just doesn't make any sense.

So I think we should put the power back in the hands of the

user and just say, well, you know, I'm going to keep track

of who I want to get mail from.

Now, this is an idea that's been around

about ten years now.

And ever since then, everyone has been saying, no, it's not

going to work.

It's impossible.

But I know the way Julian and I saw it was this just gives

us an opportunity to do science.

And science says let's come up with a hypothesis

and disprove it.

And so the hypothesis here is let's just build it and try to

make it work between the two of us, and if anybody else

wants to come in and join the party, then they're welcome.

And if it turns out that it does not, in fact, work, then

that's fine.

And so, just scoping the project, the goal is really,

really small.

This is just a hobby project between Julian and myself and

anybody else who wants to join.

And the objective is that we should be able to email each

other without worrying that the mail got

blocked by a spam filter.

So maybe I want to send Julian a message that says, hey,

check out this email.

It's a really clever spam, or it's a really clever phish.

Or, hey Julian, have you thought about getting some

Viagra, right?

I don't want that message to be blocked.

And today, we have to worry about that.

We're not trying to change the world.

We're not trying to tell everyone, OK, let's

discontinue email.

Let's do a big transition strategy.

I've tried to do that before with email.

And while it has worked to some extent, it is a much

bigger job than we can do part time.

So we're not trying to do that.

We're not trying to get everybody in the world to stop

using email and start using this, so not the goal.

If spam couldn't kill email, we can't kill email, right?

So let me talk you through.

For anybody here who's not that familiar with SMTP, this

is how the mail stream works.

So, you've got the user.

It sends mail.

It typically goes up to their sender ISP, your little MTA,

and the sender ISP dumps it over to the receiver ISP over

the net, where at some point it gets

pulled down by the receiver.

Now, if the receiver is not around--

suppose they're sitting in a technical

presentation, not online--

then the message just sort of sits on the receiver ISP until

the guy shows up.

And if he doesn't show up, then it just sort of piles up,

and all this spam sits on the server, spinning, until he

does show up.

And then, he's like, oh my god, all this spam just came

down my connection.

And so, the poor end user, he's like, I don't like

getting all this spam.

I don't like getting all this stuff.

It's too much.

So what do the end users do?

They're like, all right.

I am just not going to bother with email.

In fact, I don't care about downloading my spam.

In fact, I don't care about this entire SMTP

infrastructure anymore.

All I want is to just talk to my friends.

And so, they're like, just IM me, right?

And a lot of people are doing this nowadays.

If you look at what the young people

are doing, the teenagers.

They're all using IM.

They're all using sort of closed Myspace-type systems.

Email is not really part of the picture for them.

But the problem with IM is that, if you're not both

online at the same time, then you've got this

disconnection problem.

And so you still need some kind of asynchronous mode,

where something that's always connected to the net is able

to buffer these messages for you.

So, I'm using this term very loosely.

Sender ISP, it's just something that's always

online, that the messages can sit on, even when the sender

and the receiver are not there.

So, the simple model here is the sender sends a message.

It goes up to the sender ISP.

And it gets pulled down directly by the receiver.

So it's very simple, you know.

Instead of popping your mail from your ISP, why not go pop

the mail from their ISP?

And 10 years ago, when IM2000 came around, the big paradigm

was email has to be stored and forwarded.

We've got all these different hops, and email has to be

forwarded from one hop to another.

Ten years down the road, everybody's used to the idea

of just doing RSS, just doing, sort of, the web.

They're used to the idea of, I'm going to upload stuff to

my server, and then if anybody's interested, they'll

go pull it down.

So, if the receiver goes away, if the receiver is not pulling

down mail, the mail will just end up sitting on

the sender's server.

And I'd much rather have it piling up on the sender's

server than at the receiver's server, right?

For a long time--

I've been working on anti-spam for the last three

or four years now.

A lot of people have been saying in the anti-spam

community, we could solve spam if only we could shift the

cost to the sender.

And there's been a lot of ideas that have been

proposed for this.

So, like, e-postage.

People are like, let's charge a milli-cent per message.

And all these schemes sound good, until you actually think

about how it would roll out, right?

Because a thousandth of a cent isn't that much here.

And you're like, all right, well I could send a couple

thousand emails, and it would only still be pennies.

But you got to Africa.

You don't want to charge Africans a lot of money to

send mail to the US, right?

So Microsoft had this idea, let's make the sender burn

lots of CPU.

So we slowed them down.

But the problem is, with zombies, the zombies have more

CPU than anybody else.

So I think the solution's actually really simple.

I think we can shift the burden to the sender if we

just look at it in terms of disc.

In the modern paradigm, with SMTP, the

receiver stores the message.

The receiver has to have lots of spinning disc.

And it's very expensive for a receiver ISP to

store email and spam.

Now, what happens is the email gets downloaded.

The spam stays on the server, right?

And I spent some time at Earthlink, and Earthlink was

not happy about this.

With the sender storing the message, spam becomes the

problem of the sender, which is where it belongs, right?

So I think, if we want to shift the cost to the sender,

looking at who has to maintain the disc is a really

good way to do it.

So I'm going to talk a little bit about kind of the

specifics here.

The receiver has to maintain an address book.

And, in the same way that you maintain a subscription list

for your RSS feeds, you maintain an address book for

who you want to get mail from.

And if there are three people in your address book, there

are three people sending mail to three different sender

ISPs, you have to pull down mail from each one of them.

And you might think that this is kind of a problem.

Because, OK so, he sends me mail.

It sits on his server.

I don't get the mail till I go out there and I pull it down.

It's inefficient, right?

And also, what if he sends me mail once, and then six months

go by, right?

I don't want to have to keep pulling.

But it seems that in the world of blogs and RSS, people are

like, well, we don't really see this as a problem.

We just do it, right?

And even if it's a waste of bandwidth, well, wasting

bandwidth makes, sort of, the gray beard IETF crowd upset.

But it doesn't really make anybody else upset, because

bandwidth is cheap.

So politics.

So in a simple case, I said, all right.

Well, maybe we can address that problem by adding these

little stubs, right?

These little UDP notifications, so that when I

send Julian a message, it actually sits on my server

waiting for him to come pick it up.

But at the same time, I send this tiny little UDP packet

that says, I just sent you mail, come and get it.

And what the packet looks like is just a real simple, mail

from me, mail to you, and here's the URL where you can

go download the rest of the message.

And everybody sends these little stubs.

They end up being stored by the receiver ISP.

So there is some disc.

But I'd much rather have these little structured stubs,

right, in a database, than these arbitrarily large

messages taking up disc.

So, it's easier to manage these little DB things.

And even if the stubs don't get sent, it is still the

receiver's responsibility to go out and pull.

So, even if all these UDP things fail, that's OK.

So anyway, the receiver goes to their ISP and says, all

right, who has sent me mail?

Downloads, basically, your list of dirty senders, right?

It's a dirty list. And then he goes out and pulls the

original mail.

And I think that is enough of an answer to say, if we bring

in these little UDP stubs, then the inefficiency of

pulling becomes not that bad, right?

And what does that leave?

That leaves the first contact problem.

So, what happens if these guys over here are not yet in the

address book?

This is the question that everybody always asks me.

So the answer is, that's not really our problem.

We can say, let's go back to the idea of, like, the

opposite of every great idea, right?

Today, if I give you a business card, what that means

is, here is my email address.

Please mail me.

Maybe tomorrow, what that means is

here is my email address.

Let me mail you.

Right?

So you go back, and you type it into your address book,

just like you would.

But, instead of you being able to mail them, it just means

that they can mail you.

Maybe we can say, all right, let's use these little UDP

stubs to notify that there's this new guy out there, and he

wants to send me mail.

And if they just keep sending you these stubs, at some point

I might go download the message.

But this means that there's kind of a

policy change, right?

It means that receivers have to respect stub notifications.

And it changes the design a little bit.

And it brings back the spam problem.

So it's kind of an issue.

At that point, I think we can still bring

in reputation solutions.

We can say, let's figure out what people

think about these senders.

And if they're a good sender, then we'll read the mail.

And if they're not a good sender, then we won't.

And that solves the United Airlines problem, right?

Like, I sign up with United Airlines.

And they send me mileage plus notifications.

And at no point did I ever go in and put in United Airlines

into my address book.

But I still want to get these notifications.

Because they are a generally recognized OK group of people.

And I think reputation systems can help say, well, these are

the Fortune 1000.

If they send you mail, it's probably not spam.

And so on.

So, you know, going back to saying it's not our problem,

we will use some kind of out-of-band mechanism to

introduce new senders to the address book.

We can say, maybe one of those out-of-band mechanisms is

email, right?

I mean, email is still there.

We can still mail you.

Once you're in the address book, the MUA can do all kinds

of really smart things to say, all right, now that I've

gotten this first message from you, I can subsequently keep

pulling you.

And, you know, I've never heard of this objection to

other things like IM.

Yes, you had a question.

AUDIENCE: Sorry, I interrupted you.

MENG WENG WONG: Yes.

AUDIENCE: I mean, obviously you need something more

lightweight than TCP, but it's also [INAUDIBLE PHRASE].

MENG WENG WONG: Yes.

The reason I chose UDP was because you've got to think

about service tags.

You've got to think about spammers, right?

Spammers are going to try to send you lots of mail.

And if we reduced it to the point of, if spammers are

going to send us unsolicited stuff, I would rather it be

UDP than TCP.

Because there's going to be a lot of people out there

writing these implimentations, if this thing takes off.

And it's a lot easier to write a UDP server that is resistant

to flooding than to write a TCP server that's

resistant to flooding.

That's my theory.

AUDIENCE: Usually, it's more value to just reverse contacts

instead of--

and you lose things,

MENG WENG WONG: Yes.

So, instead of moving this little blue ball, instead of

saying it's UDP, maybe we could say it's some kind of

HDP request. So it's TCP.

Maybe you could submit some little XML things.

Like, here's the center, and instead of it being a small

UDP thing, it's a big TCP thing.

But the synaptic is basically the same.

AUDIENCE: Okay.

MENG WENG WONG: So, in IM, we've got the idea of, here's

my buddy list. If you're not in my buddy list, I'm probably

not going to accept messages from you.

And I haven't heard anyone complain.

Well, you know, as an open source author, I get lots of

unsolicited IM contacts from outside.

And I need to read those.

You know, it's just a different set of expectations.

Email is what I like to call the medium of

least reserve, right?

You can always expect to send somebody an email.

You can't always expect that they'll read it.

But that's the way it is now.

Did you have a question?

Yeah.

AUDIENCE: Maybe you were going to answer it later.

But anytime you introduce any kind of receiver

[INAUDIBLE PHRASE].

you introduce the opportunity for spoofing.

MENG WENG WONG: Right.

AUDIENCE: So, you could easily say, here's a message from

someone in your address book.

Go to this URL, which is not [INAUDIBLE PHRASE]

the address book.

How would--

MENG WENG WONG: You'd have to tie it really tightly.

You'd have to say, the address book is the authoritative

source of sender outbox URLs.

And if somebody sends me a URL that claims to be from the

sender but isn't really that sender, I

have to discard that.

But let me get into the address book

a little bit more.

Let's go back to the goal, right?

The goal here is for Julian and Meng to be able to email

each other.

So some of these issues don't really apply to the goal.

I think we can get around them.

So, Julian, maybe you want to talk through a little bit of

what we've done?

JULIAN HAIGHT: Yeah, so I guess that contact problem, I

mean, I could talk--

MALE SPEAKER: Could you use the microphone?

MENG WENG WONG: Why don't you get up to the mike, and we'll

take a couple of questions, and--

MALE SPEAKER: Come join me up on the podium.

MENG WENG WONG: We'll take a question, we'll go over--

let's talk about the benefits, the pros, the cons, the

architecture.

And then we'll get into the implementation, okay?

You have a question?

AUDIENCE: Yeah, you assume that senders [INAUDIBLE]

resources so that spammers paying for their

[INAUDIBLE PHRASE].

But a spammer can generate a message on the fly.

[INAUDIBLE PHRASE].

MENG WENG WONG: Right.

So, this is a good point.

Spammers are actually more agile than

regular email sites.

Because they can dynamically generate messages.

So if you're getting real email from someone, if you

issue a 400 error code and say, come back again, that

real sender has to then spool that message on disc.

A spammer is basically running all of this out of this huge

mail-merge template, right?

And they've just got a whole database that says, well, this

guy checked email, and this guy didn't.

But they've got one message that they're just trying to

send a lot.

In my model, I'm assuming that--

I'm trying to shift the cost of disc to the sender.

I'm assuming that, even if you're a spammer, you've got

to have some disc, somewhere, that's

permanently connected, right?

And maintaining that site, even if it's not economically

costly, it will be a way that we can track you down, right?

So, with zombies, what will zombies do?

Zombies will say, all right, instead of getting our own

spam server with an IP address, let's send mail

through the ISP.

And the ISP, at that point, has a place where they can

say, OK, let's do zombie litigation.

If they're sending this virus, if they're sending this spam,

we know that this customer is infected, and we

can deal with that.

JULIAN HAIGHT: All right, let me answer the same question.

I reject this whole idea of trying to layer on a first

contact solution.

You have to be introduced.

Or somehow you have to, out-of-band, get

this person's thing.

Like, instead of you giving me your email address, we give

each other our email addresses.

Once we send each other email then we're introduced and we

can communicate.

The United Airlines example is good, too.

I would say, the way you do that is when you sign up for

the mileage plus program, you click on a link which brings

that address into your address book.

And, you know, the first contact problem

is similar to email.

You have to have some way to initially do it out-of-band.

Even now, it's like, you click on an email address on a

website to get to somebody, or, you know, how

does anybody get there?

You kind of layer on things at that point.

AUDIENCE: I don't see how you can argue that.

You're clearly losing functionality,

just like Meng said.

[INAUDIBLE PHRASE] get a lot of unsolicited mail.

It's a clear loss of functionality.

[INAUDIBLE PHRASE], especially if you can solve it, but I

don't see how you can just say, it's not a problem.

JULIAN HAIGHT: It is a problem.

I mean, it's a loss of functionality.

But it's an intentional cutting off of a cancer.

MENG WENG WONG: The way we broke it down is we said,

there is stuff that we're trying to solve, and then

there's stuff that's not our problem.

And we intentionally said, that is out of scope.

AUDIENCE: So, if you're very successful [INAUDIBLE PHRASE]

does this, doesn't it mean that the recovery ISP has to

support many more connections than they do currently?

They just have their user base to call right now.

They don't have to support anybody in the world who's

polling them.

And that doesn't seem to be-- somebody like AOL or Gmail--

JULIAN HAIGHT: Why don't I go through the implementation

that I've actually done for this.

MENG WENG WONG: Just to address that point, I think I

would be much happier in a world without spam, with all

the network load that we've imposed, than a world with

spam, with all the network load that that imposes.

JULIAN HAIGHT: Because our ISP is doing all those SMTP

sessions from all the spammers.

So it's not just POP.

AUDIENCE: There's actually not that many spammers.

There's a lot of users.

And it's a lot of connections.

JULIAN HAIGHT: There are a lot of SMTP connections that, ISP,

that's being spammed.

I mean, you often run into denial of service.

AUDIENCE: Not every home PC is a zombie, but every home PC

receives mail.

So that's how much you're going to increase your--

JULIAN HAIGHT: But each zombie is doing exponentially more

than a regular person.

A zombie is maintaining thousands of simultaneous

connections, continually, 24 hours a day.

So the load they're imposing on the infrastructure is much

higher than a legitimate user, who checks one POP server,

once every five minutes.

A zombie is doing thousands of connections every minute.

AUDIENCE: You can also rate-limit each URL, right?

I mean, if I was an ISP, I could say, I don't want people

polling for email stored on my server more than once every

five minutes.

JULIAN HAIGHT: Sure.

Sure.

And here, I'll go through this, and it'll help show how

we've tried to address some of these issues with

the protocol as well.

OK.

So I've been talking with Meng about this.

And at some point, I sort of gathered a bunch of the ideas

that I thought were practical and feasible, and decided to

just run with them and implement a solution.

Under my implementation, I really was interested in

having security be a major part of it.

And so I made it as a shell around GPG, where all the

messages are signed and encrypted by default, and the

GPG key ring serves as the address book/white list.

I also wanted it to be easy for somebody

to get started with.

So my implementation is also an SMTP proxy.

So it can be used with any mail reader.

And it fetches into a mail cue.

Again, to provide compatibility with all the

existing software.

Obviously spam free, as Meng already talked about.

There's no unsolicited contact.

And so, this is the network model that I ran with.

It can change, obviously.

But here we have the sender server, which is just an

Apache server running a CGI.

Again, ease of adoption.

That CGI then spawns a daemon which will listen for polling.

And the polling is done in UDP, but they don't have a UDP

notification in this implementation.

Instead, the recipient continually

polls all their senders.

So they're blasting out a bunch of UDP packets for

everybody in their address book every,

whatever, five minutes.

They expect to receive back a packet.

If they don't, then they fall back on a heavyweight polling,

where they actually do an HTTP request that signed.

And that's how they get their mail.

These are the three parts.

The smtp2stub is a gateway between SMTP and pushing the

mail by HTTP onto the sender mail server.

Http2mbox is the recipient side.

Poll all the people in the white list. Pull down any mail

that exists.

Post_manager is the CGI that does both sides of the sender

server mail store.

Basically, an outline of the UDP protocol.

There's a cookie that is established when the

heavyweight polling occurs, which is signed, so that you

know which recipient and sender you're talking about.

Basically, how you tie in the encryption.

Cookie's hard to guess.

If the server sees a request it doesn't understand, it just

doesn't respond.

If it sees one where there's no one in the address, or

there's no associated authentication with the

cookie, it responds saying, you're going to have to do a

heavyweight poll.

Basically, talking about the PGP, encryption happens on a

local machine.

So it's end-to-end secure.

A man in the middle can maybe cause someone to poll when

they don't have to or see who is sending mail to who, but

the messages themselves are encrypted.

Let's talk just a little bit about how you can defend this

against a denial of service by trying to correlate between

the UDP and the TCP.

This is one of the things I think about, having dealt with

a lot of denial of service attacks before.

So I tried to avoid some of the things I've seen go wrong

with smtp with this.

You know, it should allow people to completely ignore

the UDP packets if they want to and force the client to do

a little extra work, to do an HTTP signed do you

have mail from me?

And this is an alternative to the default installation,

which I would envision being on the person's local PC.

Instead, you can imagine having this installed on a LAN

server, and the people using it aren't even aware that

they're using it.

This just takes over for your regular SMTP server and your

regular POP server by running it in a centralized place, so

that, for instance, you could monitor

everybody's email or whatever.

And then there's all sorts of future ideas about extensions

that you could do.

First contact things, like the stub notifications.

If you want it, you can turn that sort of thing on, but

then you're back in the world of spam.

And right now the implementation assumes that

your local machine is secure.

In a future implementation, you'd like to see the entire

local mail spool, and all the mailboxes and all

the key ring encrypted.

Right, and right now the implementation is limited.

It has a few inefficiencies that you can easily see where

there would be room to improve.

For instance, if you're having Hotmail and Yahoo talking to

each other, you want Yahoo to be able to say, do you have

mail from any of these people to any of these people, rather

than saying, for each of these people, do you have mail from

this guy to that guy, from this guy to

that guy, et cetera.

So there's various places where you could improve the

protocol, as-is.

And that's it.

And all that software is written.

You can go to stubmail.com, download it and

start to use it.

It ties into the GPG.

If you haven't used GPG before, all you have to do is

install it.

It'll created a keyring for you.

It'll create a key pair for you.

So it really tries to make adoption easy.

It will, if you want to integrate it into your

existing email structure, when you send a message to this

system, it will check to see if the recipient is compliant.

If not, it'll fall back on regular

email to send the message.

And, you know, hacks are welcome.

If you download it, and you want to add any of the stuff

or whatever your pet feature is, go for it.

It's all open source.

MENG WENG WONG: Let me point one thing out though, which is

that a lot of these extensions, like the whole

idea of doing UDP, of doing crypto, all these extensions

are peripheral to the core concept, which is that the

sender has to store the mail and the

receiver pulls it down.

You can layer all kinds of enhancements on top of that.

But if you don't like them, there's

different ways to do them.

You have a comment?

AUDIENCE: No, I have a question.

I'm a little confused about the economic argument.

So, currently, the idea is the spammer is paying for

bandwidth already, and this will add in the cost of

storage on top of that.

So, what are the numbers?

How much does the spammer currently pay to spam people?

And how much more money will this impose on the spammer?

I always thought disc was really cheap.

MENG WENG WONG: Disc is really cheap, unless you are

Earthlink or Gmail.

And then you're spending a little bit more money.

What we're trying to do is cut the receiver

ISP out of the loop.

Instead of storing mail up here, which is

one centralized point.

If you have a million users, you have a million mailboxes,

or a million units.

If we move the mail from here to here, then it becomes

possible, when you actually want to download the mail, the

mail gets downloaded straight to the client.

And there's a million hard drives out there.

Each client has their own.

So the economic argument isn't quite so much that, let's try

and make it expensive and painful for the spammers, as

much as it is let's just try and make it less painful for

the receivers.

The spammers are paying a certain amount of money in

traditional scenarios.

But most of the time, they're actually sending

mail through zombies.

Is that right, Julian?

Yes.

AUDIENCE: I want to go back to that disc is cheap.

Because it actually doesn't cost that much to store spam

on the receiver ISP [INAUDIBLE PHRASE].

And actually, most users don't actually care about that.

They don't want to go through-- they don't care that

Earthlink pays money for that, right?

MENG WENG WONG: Right.

AUDIENCE: They just care about spam.

MENG WENG WONG: Earthlink cares.

AUDIENCE: If Earthlink cares, then they ought to impose a

whole array [INAUDIBLE] on users to solve the problem

that they're causing.

MENG WENG WONG: That's true.

That's true, too.

JULIAN HAIGHT: [INAUDIBLE] the ITP thing, or all ISPs had an

ITP server, but now it's sort of a value-added pay us money

and we'll give you access to our new server.

Maybe 20 years down the road, if everybody is doing this or

IM or something like that, an email account is an add-on to

an ISP account, where the ISP is really back to just

maintaining a network, not all these add-on services.

And maybe you save $5 a month.

It is one of the big cost centers for ISP.

It's not so much in the infrastructure itself, but in

the people to manage it and take the complaints and try to

build the filters and sort of prop the whole thing up.

AUDIENCE: So, users now store all their mail

on their home PC.

JULIAN HAIGHT: In this model, it's either on the sender

server or their home PC.

MALE SPEAKER: Can you access anything, use your laptop

while you're [INAUDIBLE]?

JULIAN HAIGHT: Well, you can still implement web mail.

MENG WENG WONG: No, no, no.

I would suggest that if you're going to have that kind of

synchronization situation, with multiple end points, that

each one of those end points should maintain

a copy of the mailbox.

And you could just go out and pull that

message down each time.

Right?

It's kind of like IMAP.

AUDIENCE: So when does the sender get to get rid of it?

JULIAN HAIGHT: Only when the receiver says so.

There's a separate API for [INAUDIBLE] message.

And you can do a message almost anytime you want.

If the sender says so.

You know, if the sender's like, that's been on the mail

dock queue for 100 days, I'm going to get rid of it,

despite the fact that the receiver isn't

[INAUDIBLE PHRASE].

MENG WENG WONG: One of the benefits is that the sender

knows when the message has been retrieved.

Yes.

AUDIENCE: So, you've create another tier of email.

You know, so now I'll have a set of email which I'm pretty

confident is spam-free.

And I might want to limit the number of people who arrive at

that channel.

Do you have any provision for putting someone back into the

generic semi-SMTP email?

Like, Oh, I arranged for this secure channel with you, but I

don't like to email your mailing list that sends me too

much stuff, whatever.

Go back into the normal documents.

JULIAN HAIGHT: That's a good question.

I don't think there is.

I mean, it's pretty much domain by domain.

If a domain supports this protocol, then senders are

going to assume that that person will fetch from them.

AUDIENCE: [INAUDIBLE PHRASE]

JULIAN HAIGHT: Yeah, just take their key out of your keyring.

AUDIENCE: Your SMTP, presumably, right?

Presumably, they wouldn't be sending you two copies.

JULIAN HAIGHT: Right, right.

The sender won't know that he's done this.

The mail will just start to go away.

Well, it will pile up on the sender SMTP server.

AUDIENCE: Have you DJB?

Do you know what it is?

MENG WENG WONG: I have not talked to DJB.

I'm afraid of talking to him.

AUDIENCE: I think something like this actually has a

benefit for actually sending out spam, or preventing spam,

in a good way.

So, if I want to send a large file to a whole bunch of

people, this is a really good way to do it.

JULIAN HAIGHT: Right.

Right.

AUDIENCE: And I can see that being--

JULIAN HAIGHT: If you want to talk about Viagra, this is a

good way to do it.

AUDIENCE: You don't actually have to alter a whole email

protocol to do that.

You just add something saying, there's a large message

sitting on this server [INAUDIBLE PHRASE].

MENG WENG WONG: Sure you could.

But, so you could send a stub.

Not as UDP, not as a TCP, but an email message.

But we were a little bit worried that if we did that,

they might not get through.

JULIAN HAIGHT: Right.

That's another thing, is the reliability.

More and more now, people are complaining, like, I didn't

get your email.

Or they send an email and they follow up with a phone call.

Like, make sure you got that message from me.

And things start falling on the floor, more and more.

AUDIENCE: If you use SMTP and it really does prevent spam,

then the spam assassin will just have

rules of how that works.

JULIAN HAIGHT: A spam assassin might.

Who knows?

AUDIENCE: That may be a way to evolve this rather than have

people just change everything.

MENG WENG WONG: Solving the I didn't get your mail problem,

if I'm the receiver, I can just sit there and keep

banging on my refresh button, right?

And I can say, with confidence, I'm looking at

everything that's in your outbox for me, and you haven't

sent me anything.

Much more confidence that way.

So that's one of the benefits.

You can send a 2 gig video, if you want.

You upload the video, and if they pull it down,

they pull it down.

If they don't, they don't.

So each attachment could be a separate file.

AUDIENCE: That application actually sounds a lot like,

just, uploading via a web server and mail the URL.

MENG WENG WONG: Right.

JULIAN HAIGHT: Absolutely.

It's pretty much equivalent to that.

AUDIENCE: I'm not familiar with DJB's original proposal,

but I'm curious how your implementation

differs from it at all.

MENG WENG WONG: He has no implementation.

JULIAN HAIGHT: Yeah, I'm not that familiar with it, either.

MENG WENG WONG: It was just an idea, as far as I know.

AUDIENCE: As to what he was suggesting, did you take that

idea and extend it to sender storers?

JULIAN HAIGHT: I mean, his core theory was

sender-storers.

I'm not sure exactly how he proposed to implement that.

I doubt it was via polling UDP.

MENG WENG WONG: Yeah, if you look at his website, his

website basically says, well here's the basic idea.

And there are a whole bunch of questions that

this idea leads to.

For example, how do you do polling?

How do you do encryption?

How do you do this?

How do you do that?

And we've answered those questions, basically by

saying, all right, the core idea is to do HTTP GET, and

we're going to have encryption.

And everything on top of that idea, you know, how you answer

all of these additional peripheral questions?

You can answer them in different ways.

You can say, all right, fine.

Let's use PGP for the address book.

That's one thing that we're doing.

But you don't have to use PGP for the address book.

You can use some other kind of address book, if you want.

You can answer all these questions in different ways.

You can say, let's do introduction by going to

science fiction cons and doing PGP key signing.

JULIAN HAIGHT: I thought it would be fun to do a cell

phone bluetooth application for key exchange.

MENG WENG WONG: But you don't have to do it that way.

You can do it any way you like.

So I end up building this huge list of different extensions

and enhancements that are completely optional, that

different people can implement in different ways.

But if none of them are there, you can still get the core

functionality.

So, I don't know if that quite answers the question.

But this is sort of an approach to the philosophy.

JULIAN HAIGHT: One of the reasons to put the crypto in

the core is just to make sure that you're getting messages

from who you think you are.

If you do the key exchange in a secure way, then the whole

thing is more authentic.

MENG WENG WONG: Right.

JULIAN HAIGHT: You know who you're talking to.

MENG WENG WONG: Yeah, we felt it was high time to get real

PKI into the system.

And we didn't want to have to do PKI as a patch.

We wanted to be in on the ground floor.

JULIAN HAIGHT: And you don't have to have

a password or anything.

It sort of solves a lot of the other authentication problems

that just become non-issues once all the

messages are encrypted.

You know, if I guess the message ID of the message that

you have and download it, it's garbage.

It's just random crap.

MENG WENG WONG: Any other comments?

Questions?

AUDIENCE: So you could also just locate Gmail accounts and

send each other mail.

You could never put in a spam filter.

MENG WENG WONG: Yes.

We're seeing this movement back to closed systems. This

is why Myspace is very popular.

If you want to talk to anybody who is 15 years old, you've

got to get a Myspace account.

AUDIENCE: Other solutions like this have been tried, but

they're all closed.

And I think that's one of the reasons they

haven't taken off.

Because with this one, you can talk to somebody in Africa or

a different domain or whatever, without being

beholden to one provider of technology,

one host, et cetera.

MENG WENG WONG: Yeah.

The moment you move from--

AUDIENCE: As much as we all love Gmail.

MENG WENG WONG: The moment you move from closed systems to

open systems, and the moment you have federation,

you will have spam.

If it's push.

If it's pull, then you have a fighting chance.

Yeah.

AUDIENCE: So you have an implementation.

Is anyone using it?

Or is the user base still two?

MENG WENG WONG: We exchanged email for the

first time last night.

So, a little bit of a background, all right?

So, this is the goal, remember?

We can email each other.

And it's done, because we started in April.

We had a little hackathon.

We got together and we said, all right, guys.

You guys have been talking about this.

Some guy actually wrote a PhD thesis on the idea of pulling.

You know, I don't know if he actually implemented it.

He just wrote a thesis on it.

And so we said let's do it.

We did it.

We built it.

And yesterday, we had the first

interoperable exchange of email.

Thank you for providing a forcing function.

But it works.

JULIAN HAIGHT: And we would love to

expand the circle, though.

The software is on the website.

You can download it.

And once we get your key, we can exchange some email.

MENG WENG WONG: Hey, it's kind of like how Gmail is invite

only, right?

You've got to have the connection to the system.

JULIAN HAIGHT: You'll have to email us your address.

Well, one simplification on this, that's not entirely

secure, is key exchange happens automatically, with

just a simple email address.

So, he gives me his email address, I give him my email

address, and as soon as I send mail to him, stubmail

automatically asks his domain server,

where is your key server?

Asks the key server, what's his key?

brings it into the local key keyring, and then encrypts

mail to him and so-on.

MENG WENG WONG: Well, that's one implementage.

That's the current implementation.

There are lots of ways to do this.

Here is an alternative, right?

Here's my PGP keyring.

Here's my key.

And you'll notice in the comment field in this little

UID here, I have got a URL, right?

So, I've got my name.

I've got my email address.

And I've got my outbox URL.

And you can go retrieve your mail from that outbox URL.

AUDIENCE: Without talking to the main server.

Without talking to the URL.

JULIAN HAIGHT: And that's one of the things we are going to

implement RSM.

MENG WENG WONG: Right.

So, if you want to change your high-speed, all you have to do

is go edit your keyring, dump it out.

And then, suddenly people are looking for your mail

somewhere else.

Securely.

Without any issue about spoofing.

[APPLAUSE]

MENG WENG WONG: Thank you.

The Description of Turning Email Upside Down: RSS/Email and IM2000