Since a lot of comments are arguing your point OP I just want to comment that I agree. Theres no reason to force email registration for self hosted services, it's very annoying.
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Thank you.
If you're self hosting, the email service only needs to be accessible to those services. Set up a postfix container if you don't want these messages going out.
You can read them locally, or configure postfix to forward them to some other host if you desire.
I'm starting to wonder if a mailpit instance is a bad idea. Just a page you go to where any email goes, make sure it's not externally accessible.
Ooh, that's a useful thing to know about! Thanks!
Was about to add that very idea, maybe I should write a compos file with postfix setup
I don't want email to be accessible to those services. I don't want those services to use email at all.
Then you're free to patch it out.
Do you know of any other near-universal messaging system to use instead?
Edit: also, the downsides you mentioned depend really hard on the email service you choose to use, or choose to host yourself.
Web push for notifications. Sure, there's privacy implications, but it's already near universal. There's other options like ntfy.sh if you're not limited to existing infrastructure. UnifiedPush also works well as a protocol for push notifications.
Everything else can be handled in-app. Password reset will have to be done by an admin, though it's completely doable for a small selfhosted service.
Some of the downsides OP listed may or may not always apply, but there are always downsides. Either you have to set up your own email server (with extra maintenance burden), or your "selfhosted" app suddenly relies on third party infrastructure, like your email provider (or those of other users on your instance).
XMPP? Matrix?
Why do I need a messaging system in the first place?
XMPP and Matrix are not near universal.
Most people have no idea about that the hell the first one is, and are even more confused as to why you start talking about a movie when you just complained about email.
XMPP? Matrix?
That's cute, but very much a bubble view. Usually not worth the effort unless the devs themselves are users.
Why do I need a messaging system in the first place?
You might not need one, but the majority of users want and/or need one for user management, password reset, notifications etc.
And it is being developed for the majority of users.
the majority of users want and/or need one for user management
Is it too much to ask for self-hosted users/developers to use something slightly more modern, convenient, and easier to implement? Or to simply make it optional? As long as it's not even an option we're pretty much doomed to the dinosaur-era of internetting permanently.
You're getting ragged on but I would very much prefer an approach with these things that used some sort of modular system.
I'm imagining the service would have the option for "address for communication bridge" and it'd pass messages to it using JSON or something. The communication bridge would then decide which medium that would go through (email, SMS, smoke signals, whatever the owner configures).
As far as the service is concerned messages come and go (or just go) and how that side of things works isn't its problem. It'd also mean that one could configure fallback messaging mediums and use dummy ones for if one doesn't want anything like that (much like the "emails print to the console" debug tool Django has).
Eh, I agree.
I have root access to the server and can directly interact with the backend DB. Forcing email for a password reset doesn't protect me from me.
is a pain in the ass
is dependent on 3rd parties
Well, one of the two, at any rate.
If it's not one it's definitely the other.
Even if you self-host, other people's mailservers still interact with it, unless you only chat with other users you host. And some of the big webmails variously get really pernickity about your DNS, DKIM and more, or they deploy some pretty obnoxious countermeasures against your server with little explanation. So I'd say it's more often both than not, no matter what you do. If you think it's not being a pain, there's probably an unpleasant surprise in your server logs or coming soon!
It's still often worth self-hosting, but that's more big webmail really sucks, even ISPs often don't set their mailservers up well and it's often an early casualty of ISP managers looking for costs to cut.
Even if you have a proper clean IP, running a mail server is a hassle imo. By far having a single relay to send is fine if you get things set right, but also dealing with incoming spam is just way more work than paying to have it hosted.
I much prefer paying for email hosting and just dealing with outgoing emails if needed.
dealing with incoming spam is just way more work than paying to have it hosted.
The right way to deal with spam is not to use filters in the first place. It's not like Gmail or Proton or 's spam filters are perfect either, far from it, they still let a ton of shit through. The right way to deal with spam is to use unique aliases for each account that you can shut down if they leak.
That depends who's hosting it. There's few good reviews of email hosting out there at the moment.
Depending on 3rd parties is a pain in the ass
Ghost needs emails for a couple of reasons.
-
(Required) Ghost does not do user passwords. They use magtic links, which they send out via email when signing in. It's just how they have chosen to do it. You can ask them why they don't want to save passwords.
-
(Optional) Ghost has a newsletter function. If you enable it, you need to setup a bulk email service, like Mailgun. Even regular SMTP won't really work there. It can send out a newsletter everytime a blog post is published, so the members will get notified.
I recently had to do this email dance with a Ghost instance setup, where most of the email ports are blocked on the network. I know how you feel. I also wanted to just use passwords, but not currently possible with Ghost.
Other services might do the same as Ghost. I do host many services, that does not require email setup though.
Same I almost got locked out from my Ghost account because of email 2FA. Luckily you could change the config to override it.
Same annoying was with Mastodon, but luckily as admin you can approve accounts to override the email confirmation.
Exactly for the reason you said. They don't care about your privacy they want your verified email address to sell to the higher bidder.
They don't get my email address on a privately-hosted server...
its funny how the up and down votes are almost in sync for all comments.
let me clarify for everyone: email is not needed for a selfhosted setup, and shouldn't be. I am in doubt that the majority of selfhosters run mail servers.