[messaging] Hashing entries in a transparency log

[Tom Ritter]

What is the metadata people are talking about?  Origin IP?  I agree we
should not be bringing that back.  From/To addresses? I haven't see a
proposal for how to hide those. I'm going to assume From/To are in the
clear to providers at least.

On 4 September 2014 11:49, Mike Hearn <mike at plan99.net> wrote:
> Email addresses are free whereas domains are not. If you allow an attacker
> to insert arbitrary keys into your database then you can very quickly run
> out of resources. Spammers are a tricky lot ....

I believe you, but that that's surprising to me. I assumed that for
many spammers, domains were essentially free either through the
register-and-return route, or the other tricks squatters use to hold a
domain after expiration for a couple days to see how much traffic it
gets.  Like IPv6 addresses, I'd expect spammers to rotate domains very
quickly.  (Not one-per-spam mind you, but still 'quickly').

On 4 September 2014 12:52, Mike Hearn <mike at plan99.net> wrote:
> If you encrypt all payloads you may as well also scramble metadata, and rely
> on a totally different anti spam approach like using Bitcoin deposits or
> micropayments. That's why I'm more interested in Pond than systems that'd
> try and globally upgrade SMTP. And I actually implemented Bitcoin
> micropayments as a library, though not for spam.


I was wondering if there could perhaps be some sort of signed token a
recipient could include in a reply that would basically be 'proof of
not being a dick',  I include that in an outbound header on subsequent
email to that user. It'd be a flag to both outbound and inbound spam
filters that this is less likely to be spam, as the recipient replied
and is interacting at least.

More metadata about communication of course, but to get access to see
that token, you'll see the From and To metadata anyway, and you would
learn the same from the From/To as the token if we assume you maintain
semi-persistence access to the channel you compromised.


I was also wondering if there was perhaps some feedback mechanism
where a spam recipient who marks something spam would send the
(potentially plaintext) message back to the sending provider, for
incorporation into origin spam-filtering. It'd be authenticated by
either the sender's signature (but I know some people are vehemently
against signing outbound messages) or by the DKIM signature.

> Failing that, various kinds of clever PIR protocols might allow client apps
> to do spam filtering themselves with the support of big databases in the
> cloud, but the maths for this makes my head explode and usually comes with
> giant caveats that render it unworkable.

IIRC, the safe browsing database is clientside for... some browser.
Maybe Chrome on Android?

-tom