- cross-posted to:
- [email protected]
- fediverse
- cross-posted to:
- [email protected]
- fediverse
Interesting history and analysis of SMTP’s history. How can we prevent fedi and other open protocols from suffering the same fates?
Interesting history and analysis of SMTP’s history. How can we prevent fedi and other open protocols from suffering the same fates?
Defederating bad actors/spammers should in theory be good enough? Domains aren’t free and I don’t think it’s worth it for them to buy a new domain to just be able to spam for a short time again.
Literally what e-mail spammers do.
Agreed defederating can help solve obviously malicious instances, it doesn’t solve spammers abusing good instances. E-mail and AP are very similar at a protocol structure level.
Is it though? Don’t email spammers just spoof the domain or send without a domain? I’m not entirely sure if that’s different from how the fediverse works. I’m not too knowledgeable about this topic.
Very much so. Out of the spam that I do see in my inbox, the sender domains are usually spoofed, while the reply-to addresses are usually gmail.com, hotmail.com or outlook.com.
You need to set up dkim to prevent spoofing. Each message sent has a digital signature that matches one on a DNS record for your domain. You can also set an SPF record, which will tell the recipient what up addresses are authorized to send mail on behalf of your domain.
The recipent must have policies in place that reject mail which fails dkim/spf
They do both, depending on the spammer and the type of spam they send. In e-mail, you have an e-mail server, you can use it to send mail to users on other e-mail servers. Each e-mail server can choose to accept or reject email from other e-mail servers based on whatever reason they want. AP/Lemmy/Mastodon is basically identical to this. I’m not sure how exactly bluesky is setup but I get the impression it’s similar. In Nostr, servers aren’t federated (each relay is seperate, if you want to send/recieve content to another user on a different relays you just talk to that relay directly instead of having “your relay” act as an intermediary), but the structure is still pretty similar.
Nostr does have this hashcash type system (requiring proof-of-work to weed out spam), but I haven’t come across any relays that actually enforce it, it will be interesting to see if that changes in time. I also saw a GitHub issue about adding something similar to AP but I think they chose not to implement it.
Replying to your edit:
This is an instance moderation problem. If you’re letting spammers in, you need to use a better application process or something similar to that. A big problem with email spam is that most email services allow anyone to sign up for free without any checks.
Ultimately defederating bad actors and defederating “good” actors who fail to moderate their own users is necessary.
Which is one reason, this author is arguing, that e-mail has become so centralized. Doing that kind of manual moderation and curation is expensive, the bigger instances out-compete the smaller ones who don’t have as much resources to dedicate to it. As more and more instances get “de-federated” for not having as good of anti-spam measures as the bigger instances, more users will sign up at big instances to avoid defederation risk. Just like how many people use gmail simply because their email delivery rate is so good. If I send from g-mail, there’s very few servers which will reject my message or throw it in the spam folder. I’d love to run my own mail server, but even as a dedicated sysadmin it’s impossible to get decent delivery rates.
The more anti-spam checks we have, yes we weed out spam, but we also make it accessible to less users as well.
AP has been blessed so far with not having to fight too much spam. Look at very popular, very centralized, very resourced platforms like Facebook, spam is still a problem on their platform despite massive resources put towards fighting it.
Hmm I feel like some pooling of effort with spam detection built into the software (lemmy for instance) could help spread the effort of spam fighting to other, smaller instances and not just centralised to the big ones.
But it’s difficult to say what will happen I guess. We need to just keep being vigilant when it comes to stopping spam while keeping in mind our shared goal of a decentralised social Internet.
Agreed :)
Agreed, and this is what makes the Fediverse so good. It would be annoying to lose your instance, true, but you just move to another or roll your own. Additionally, let’s say they start spamming Mastodon from mastodon.social; their messages would go to the Global channel, but if I only ever read Local or Subscriptions, I’ll never see their spam.
The Fediverse and ActivityPub will continue to evolve, but unlike SMTP, they were created after the internet became adversarial. This author isn’t the first to try to fearmonger over the future of AP, and they won’t be the last.
This is a problem nostr solved, and I believe bluesky solves as well though idk as much about the protocol. On nostr, your identity and your instance are different things. Relay goes down? There’s no meaningful impact to you. You’re typically connected to several, each of which store your content. You identity isn’t username@somerelay dot com, it’s just username.
As a user, I had this happen to me early in mastodon and it was very frustrating to lose all my follows, followers, tweets, settings, etc. I realize there’s now ways to manually backup etc but properly moving an account requires a cooperative instance which can’t happen if it’s de-federated or just drops offline randomly like mine did.
This isn’t fearmongering, it’s him reviewing the ways SMTP tried to solve the spam problem and became centralized as a result. These questions of how we tackle spam and moderation are valid, important questions. And Fediverse, at a structural level, is basically the same as SMTP. We have users at instances (e-mail hosts), they can send messages/tweets/links (emails) to users on other instances. Each instance is free to accept/reject messages from other instances based on their own criteria. That’s the whole thing. That’s exactly how SMTP works.
It is fearmongering, albeit unintended, but I don’t think it completely applies to the Fediverse as it stands. We should always remain vigilant and never complacent, and I’m sure the devs and moderators are keeping spam control in their minds. This isn’t the 1980s, and we’re not trying to retrofit a protocol that came before spam was ever a thing.
But most people don’t pay for software, especially if there are “free” and legal alternatives.
I’m not sure what you mean with that or how it relates to what I said, could you elaborate?
As I understood you said that we should make email paid to stop spammers.
Nono, I’m saying it costs to spam because spammers have to keep buying new domains as their previous domains get blocked or defederated.
Why don’t they use existing domains? I don’t think 100% of them require a phone number. And didn’t know it’s possible to defederate an email provider.
No, my point is that if spammers were to spam on the fediverse, they’d need to buy new domains constantly as their previous domains are defederated, I’m not talking about email.
So you’re offering a system that requires the instance/provider admins to manually federate with others instead of the federation being enabled by default?
You’re misunderstanding me again. Please try reading what I said again.
I’m not suggesting allowlist federation, though that is another tactic that could be used. I’m just saying that a spammer on the fediverse would be quickly defederated and would have to buy a new domain to keep spamming, which would probably be too expensive to justify.
It absolutely is, your mail provider “de-federates” aka blocks mail from plenty of other e-mail providers.