Why do so many services require email configuration?
from artyom@piefed.social to selfhosted@lemmy.world on 12 Nov 16:50
https://piefed.social/c/selfhosted/p/1468973/why-do-so-many-services-require-email-configuration
from artyom@piefed.social to selfhosted@lemmy.world on 12 Nov 16:50
https://piefed.social/c/selfhosted/p/1468973/why-do-so-many-services-require-email-configuration
Recently I was locked out of my own Ghost blog platform because they decided they were going to add Email 2FA. I also cannot add any other authors because that requires email verification.
Today I was looking at installing Bonfire and came across this:
Bonfire requires working email for user signups, password resets, and notifications. Most installations will need email configuration before the instance is usable.
Setting up email is a pain in the ass, costs money, is dependent on 3rd parties, violates privacy, and is just completely unnecessary. Why wouldn’t you give users the option to not use it? It’s infuriating!
threaded - newest
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.
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.
How are they not universal?
Most people have no idea they exist.
That is my point.
If you write software, and need a way for it communicate with the user outside of the app, implementing email is simple, just about everyone with internet access has an email address and it is free.
XMPP/Matrix is a lot of added work that will only benefit those who:
I think you will find that the groups of persons who all three critera fits is vanishingly small.
So, please tell me why a developer should focus their time doing that rather than building the core features of the app.
EDIT:
I write this as someone who has used Jabber/XMPP and Matrix in the past, they are great services and I wish they had a longer reach. This is not a hill for you to die on.
It’s a whole lot less work than configuring email.
How much work do you think it is to add a toggle that makes email optional?
It’s a crapload more work to support XMPP/Matrix/whatever messaging on any platform than just using a robust, reliable, resilient, widely supported good old SMTP. For you it might be easier to input your account (which at least on XMPP resemble quite a bit of email address) but for the developer it’s totally different thing. Also practically everyone accessing a website has an email address and if they’d decide to support some mesaging platform it’d make more sense to use whatsapp than XMPP since it’s vastly more popular.
It’s absolutely not.
It’d make far less sense considering both the fact that it’s a Meta-owned proprietary data collection and advertising product, and also that they simply don’t support such a functionality.
And you know this since you’ve written code to manage both on different environments, right?
Also, whatsapp supports all kinds of “bots” and it has absolutely massive userspace compared to pretty much any other instant message application. It doesn’t matter if you create the perfect protocol and platform for this kind of thing if there’s 7 people globally using it.
You don’t have to write code to configure Matrix/XMPP.
You keep saying this as if user adoption is the only thing that matters. 99% of self-hosted stuff has tiny “userspace” so I don’t know what you’re on about.
How you imagine things send messages to reset your passwords, sending notifications and whatever is currently managed via email than some piece of code creating and sending messages, managing possible errors with them and potentially also monitoring/logging the message traffic for statistics or debugging?
User adoption matters if you want your thing to be actually useful for the actual users. And supporting any messaging system requires effort, so it makes sense to spend limited resources on a thing which has the biggest userspace. If you want to run matrix server which has you and your dog using it, go ahead, but don’t be surprised if you want to contact your neighbor and he’ll look like you have two heads when you start to explain how to reach you.
It makes zero sense to spend any resources on adding compatibility with proprietary and malicious protocols, regardless of “userspace”.
I had a look at the system, and it is a commercial product, I would imagine that their customers have requested these features.
Since you are a customer, why not request your features to be added as well?
Or, better yet, since you have explained that creating an XMPP/Matrix module as an alternative to email requires no coding, and the plattform is open source, why not just slap it together yourself?
You do realize that the developers need to write code to configure a Matrix/XMPP module? The module doesn’t just appear out your immagination.
Then it will need to be maintained as security holes are discovered.
Tell me again why developers should spend the time and resources to maintain a feature that at best will have a marginal impact on the userbase, over focusing on the core of the project.
For the minimal of sending out a message to their accounts, they are just as easy as each other. Heck, there are simple packages to send XMPP messages from the CLI.
That’s cute, but very much a bubble view. Usually not worth the effort unless the devs themselves are users.
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.
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.
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).
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.
That depends who’s hosting it. There’s few good reviews of email hosting out there at the moment.
The right way to deal with spam is not to use filters in the first place. It’s not like Gmail or Proton or <insert your favorite email provider here>'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.
Depending on 3rd parties is a pain in the ass
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 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.
Why do you assume everyone you interact with is a software developer?
To be fair, you are on a Self-hosting community but maybe read up the wiki or file the issue to suggest an option to make it not required on their git repo? 🤷
Otherwise, I'm not sure what else are we suppose to say
I wasn’t asking for advice, I was asking for an explanation.
You should probably ask the developers then. But the answer is probably to support things like password resets in environments with multiple users. It’s less development effort to implement it this way than to maintain multiple code paths with varying levels of account management.
…which ones?
github.com/TryGhost/Ghost
This is the repo (unless I have the wrong software).
However, it seems they’re running a business, which means revenue generating features will probably be prioritized. They’re not running a charity.
I’m sure if you donate enough money you can probably get them to implement better self hosting functionality. Chances are the email requirement is just what they have for other features.
Ghost is just one piece of selfhosted software. But I have inquired and they have declined.
They are, actually. They’re a registered non-profit.
More unnecessary functionality.
What was their reason for declining?
I see they’re a non profit business. That doesn’t make them a charity. They have paying customers.
I don’t think that assumption was inherent in the comment
If you want an unpopular feature that doesn’t exist on an open source platform sometimes your only options are to code it, or ask someone else to. The skillset of the feature requester doesn’t change that
I wasn’t asking for options, I was asking for an explanation.
In your OP, sure.
But this comment reads as a desired state, and in some situations thats a feature request (in this case it seems like there are architecture / system workarounds):
Did you get an explanation you’re happy with?
Was about to add that very idea, maybe I should write a compos file with postfix setup
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!
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).
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.
Thank you.
Since then you would need to have another way to achive the goals e-mail does. Like password resets, user invitations etc. Thats all software burden for that one user that does not want it.
None of these i would actually say. To work around it you can just simply set up local reachable postfix. Done. You can setup a complete local mail server, with a few clicks.
Choose the software you want to use wisely and dont jump to the first solution you find when you are that licky about your requirements. If you are ao reluctant about e-mail and the service requires it, then maybe the design goals of the software do not fit your goals.
None of those things are necessary. Like I don’t even have email configured on my server because I don’t need it at all except when the developer unnecessarily integrates it to the extent that it breaks it.
I am not at all the only one. Just look at the other comments and votes in this thread.
That makes no sense. Nothing about the software goals are related to email integration.
Depending on the view, a functioning service something like password reset is necessary. To design the software that it can ship without functioning password can or cannot make sense, depening on the design choices. Depending on what else got send via e-mail designing the software around that can be challenging and burdening for the future of developing.
If the setup required you to setup e-mail, the software and then also the developer can always assume there is a communication path to the individual user.
As i said, it can and cannot make sense, but saying
and not even trying to put yourself into other shoes just does not make sense.
It is not necessary if you don’t lose your password, which I don’t ever, because I use a password manager. It’s also not necessary if you have administrative access to the server.
Brother we have the opposite problem. You are not putting yourself in my shoes, or other people like me.
I am not suggesting everyone should get rid of it, I’m asking why it can’t be optional and easily disabled…
Bold claim. But no i am putting myself in your shoes and yes there was also a time were i tried to work around to host mail myself. But its easy and no headache to set up.
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.
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.
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.
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…