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 <[email protected]> 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 <[email protected]> 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
