💾 Archived View for bbs.geminispace.org › u › jeang3nie › 2751 captured on 2023-07-22 at 18:02:06. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "Just read through the spec. It is interesting. I will give..."
On the contrary, I think the client certificates already do a lot to improve the situation. If a piece of mail comes in with a previously unknown cert, then the receiving server can hold it, send a blank request to the domain of that cert and obtain the fingerprint. If there is no server on the other end, or no corresponding mailbox, or the fingerprint has changed, then it's spam.
In order to generate a bunch of identities, you would have to actually control the domain and be running a receiving server. Anyone attempting to spam like this would be easy to identify and that domain could be blocked. They could of course buy a new domain, or use a subdomain, but the point is that since you can't spoof a mailbox like in SMTP the mailbox has to actually exist, which makes the price for entry in the spam market much higher and also makes it easy to pinpoint where it's coming from and punish the bad actors.
This is assuming, of course, that server implementors take full advantage of the spec and do the proper challenge for new certificates.
2023-07-03 · 3 weeks ago
Just read through the spec. It is interesting. I will give that it _is_ simple enough for an average developer to grok pretty easily. Unlike gemini, though, it does not seem to do much to counteract some email negatives. Ex: Since you don't need a mailserver to write outgoing mail (like smtp) it can lead to the folks writing scripts that gen a throwaway cert and spam a bunch of addresses, then gen a new cert: repeat; eventually leading to IP blocking. So we end up blocking certs and IP...