
Modern anti-spam and E2E crypto (2014) - Artemis2
https://moderncrypto.org/mail-archive/messaging/2014/000780.html#
======
Dolores12
Its kinda fun to see he didn't mention at all that google won't be able to
serve personalized advertisement if a message is encrypted. And since google
is an advertisement company by implementing this it will shoot itself in the
foot.

~~~
mike_hearn
Because I was asked to talk specifically about spam by the moderator of the
list, not all issues that true E2E crypto would raise.

Regardless, this is one of the easier problems to solve. Lots of people pay
for Gmail and they can disable adverts. It's businesses and universities,
mostly. In a world where email was fully encrypted that would presumably be
extended to everyone and you would have to pay for consumer email accounts
too.

The problem with doing it that way is that lots of people couldn't/wouldn't
pay for email, and the internet benefits greatly from being able to assume
everyone has an email account. If that assumption were to be violated then
everyone would have to rethink their authentication systems, for instance,
because there'd be no way to send password reset emails to people. So there'd
be massive externalised costs from ending free, ad supported webmail.

~~~
wtbob
> If that assumption were to be violated then everyone would have to rethink
> their authentication systems, for instance, because there'd be no way to
> send password reset emails to people.

I don't think that's necessarily true. Running email is simple enough that
ISPs (to include mobile ISPs) could return to doing it for their customers.
Heck, if you're a node on the Internet then by default you can receive email
anyway …

~~~
mike_hearn
Many internet users are not customers of an ISP.

~~~
nerdponx
How is that possible? Do they just do all their Internet browsing at Wi-Fi
hotspots and libraries?

~~~
mike_hearn
Consider developing countries.

------
dredmorbius
That's an excellent history and summary of the spam situation. It adds a few
pieces I'm not familiar with (I'd gotten out of the fight by the late 2000s),
but validates a few approaches I've also considered.

 _Reputation is a crucial element_ , and ultimately _the_ crucial element in
large networked systems.

I'd make one correction about new accounts: if a new entity (email address,
domain, IP) starts peering, SMTP actually offers a really good options for
limiting: a non-permanent rejection. If new traffic shows up from an unknown
source, you can simply tell it "not right now". In theory, the sending server
is supposed to follow a back-off protocol, with a few minutes delay initially.
This gives time to start building up reputations through other means. And
failure to follow the retry schedule is a strong sign of misbehavior itself.
Teergrubing uses this mechanism.

The idea of vouched reputations is another one. If all peers or senders need
to have someone vouch for them, then even new agents can engage in email.

The one resource all clients, regardless of compute power, access uniformly,
is time. A protocol _mandating_ a specific time interval (say, by requesting a
specific future NIST randomness server value), might be interesting.

Another element that's helpful to the spam-fighters is that _most_
communications patterns follow a strong frequency curve -- most comms are
well-established, whilst less-frequent comms are often spam. Whitelisting
based on established comms (and overriding those with specific blacklists),
and treating _all_ novel comms as suspect until some token of merit is
received (a vouch, time delay, earned reputation elsewhere) should help.

The idea of multiple levels of encryption, with an outer envelope which an
email server can read, with an inner envelope for the actual recipient, is
another option. Here trust information can be placed in the outer envelope,
but contents are protected. Possibly a protocol might request contents _must_
be readable by the server for certain classes of sender.

~~~
mike_hearn
Spam filters do treat mail between friends differently and this is why
spammers switched to hacking accounts (vs creating them fresh) and then
spamming the contact lists about 6 years ago.

Reputation is effectively a way to do your token of merit proposal. Reading a
mail and not reporting it as spam is taken to be the "vouch" but of course
that requires the mail to be delivered. If you open an account at a high
reputation mail provider and send, then that's earned reputation elsewhere and
it's up to that provider to keep a lid on people trying to abuse that
reputation.

 _> The idea of multiple levels of encryption, with an outer envelope which an
email server can read, with an inner envelope for the actual recipient, is
another option. Possibly a protocol might request contents must be readable by
the server for certain classes of sender._

That's PGP. The assumption behind E2E crypto is that the infrastructure
provider can't be trusted, so if you let the infrastructure provider
automatically request unencrypted copies of an email then it seems the point
is lost.

~~~
wtbob
> The assumption behind E2E crypto is that the infrastructure provider can't
> be trusted, so if you let the infrastructure provider automatically request
> unencrypted copies of an email then it seems the point is lost.

The difference would be that I get to choose which emails I send unencrypted.
I might have no problem sending the latest Sears or LinkedIn semi-spam back up
to the provider, but might have a problem sending the results of a blood test
back.

------
wtbob
I wonder to what extent he's actually correct that end-to-end & reputation
really aren't compatible. After all, if one ignores forwarding for a moment
then a server will always know the peer who is sending it email, and if it
knows that peer then it can calculate reputation for it (it can know the total
emails it has received from that peer, and the number reported by users as
spam). The problem then becomes one of making it more expensive to create a
new peer, which I _think_ is doable.

------
Xeoncross
I've had a hard time finding discussions like this from people who have
actually tried to link privacy with global communication. I would easily pay a
subscription fee to read papers and ask questions from people who have worked
on P2P networks, email providers, PGP alternatives, etc...

Good Privacy & Free, Open Communication seem like two things we just can't
seem to reconcile.

~~~
jcranmer
The ultimate takeaway is that abuse is the price you pay for anonymity--the
more you give leeway for people to be jerks with minimal repercussions, the
more jerks will take advantage of it. Reputation analysis for email drove down
the anonymity (in the sense that email service providers have a much greater
stake in policing their users to prevent abuse), and it remains the single
most effective anti-spam strategy.

------
nerdponx
If you need people to trust your company enough to not encrypt their data, you
shouldn't play fast and loose with their privacy.

------
loup-vaillant
> _Botnets appeared as a way to get around RBLs, and in response spam fighters
> mapped out the internet to create a "policy block list" \- ranges of IPs
> that were assigned to residential connections and thus should not be sending
> any email at all._

This is the wrong way to do it.

It may make things easier for Google. It may save them time, money, and
worries.

This is _still_ the wrong way to do it, for one simple reason: _it is now
impossible to send email from home_. Instead, you have to have a relay or a
VPN that does it from a fixed IP that'd better not belong to a subnet in
disrepute. It keeps the email network centralised, an antithesis to its
origins, where an email went straight to the machine of the final recipient,
from the machine of the original sender —with no intermediates besides the DNS
servers.

I cannot help but notice this centralization is _convenient_ for Google and
other huge mail providers. Whatever their actual intentions when they did this
I don't know, but they clearly have no incentive to change that back (their
business is to read your email for profit after all —the fact this is all
automated only makes it worse, not better).

~~~
tedunangst
> an antithesis to its origins, where an email went straight to the machine of
> the final recipient, from the machine of the original sender —with no
> intermediates besides the DNS servers.

Wow, is that some historical revisionism. Emails used to look like
thrash!cmu!ucb!vax!tedu which meant send it to thrash, who will send it to
cmu, who will send it to ucb, who will send it to the vax, which will deliver
it to tedu. If you had a direct line, you could skip a few hops, but very few
people were talking directly to the machine of the final recipient.

~~~
drfuchs
No, you're the one with incorrect history. The uucp email scheme with all the
exclamation points actually appeared the better part of a decade after ARPANET
email with the simple, direct addressing and delivery was in wide use. Perhaps
you are confused because UNIX came late to the nascent Internet, while the
various 36-bit DEC machines and OSes were there from the very beginning. Many
thousands of students and academics were sending email to foo@bar.edu for
dozens of values of bar before anybody ever saw !ucbvax! in an address.

~~~
tedunangst
Yes, that works when the network is small enough to put literally every
computer in the hosts file. But once your local sysadmin tires of updating the
file every time some university across the world plugs in a computer, it
starts falling apart.

To the original point, if I somehow plugged my time warped laptop into
arpanet, nobody would be able to send me email until I made a bunch of phone
calls.

(But thanks for the correction, I'd overlooked even earlier history.)

