Tip:
Highlight text to annotate it
X
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
***, 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 ***, 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.