Thank you for suggesting it. I don't know if that's something he's looking into, or if he wants to do more things related to code (I'm currently trying to have a clear understanding of what he's expecting).
213 karma · joined April 5, 2011
contact at cnicodeme.com
Working full time on GetFernand.com, PDFShift.io and DNSRadar.dev
Sold ImprovMX.com, VoilaNorbert.com, Transferslot.com and Selldom.io
At Christmas, he got Mario Maker 2, and he's completely crazy over it.
I think it's something I can help him make progress and take his enthusiasm as a fuel for his knowledge. Maybe he'll stay on and learn a ton, or at least learn the basics, whatever he wants, I'll be fine with it :)
(But I'd be almost ready to start some kind of course based on his need and improve it for others :p )
And I'm not even talking about 3D Secure!
As mentioned in the comments, a solution would be to migrate from Stripe to a merchant account with a bank where your service is vetted upfront.
Granted, horror stories just like OP's are not great, for Stripe and for those who use Stripe, but we tend to keep in mind the bad press more than the good.
With Stripe growing and having more and more business, it's just basic math that the number of bad press will grow along. OP's doesn't mention (maybe intentionally) what business he offers so maybe the team has a good reason to put 35% of their user on hold (granted, the communication around it isn't great).
You can not just store the credit card of your user (or have to go through a heavy compliance), and using services like Killbill.io or GetLago.com is just moving the single point of failure to another place.
How would you ensure that you are not 100% relying on a specific payment provider, without keeping all the credit card informations of your users?
My personal email is contact@{custom domain} and currently points to Gmail because I never took the hassle to change it, but if someday I decide to move elsewhere (I'm contemplating Fastmail and Protonmail), all I will have to do is update my destination email at ImprovMX and that's all.
This is a liberty that only us, tech people, can grasp. My parents, even my wife, doesn't see the importance of being locked to mail provider.
First, this will always depend on the product you offer. If you target highly specialized tech people, why not, they are most often open to changes. For the rest, it won't never be a good idea.
We tried implemeting a "one time login link" at ImprovMX, like a few others commented here. One drawback we saw was a surge in support requests from people having issues receiving the email, or not understanding how to connect. We could debate on this but definitely, doing something "original" was not a great idea.
But regarding the suggestions made by the original post, I can clearly see a lot (A LOT) of issues:
1. Changing the flow from what the users are used to: Clearly, once you have entered your email and password, you are expecting to receive an email. It's probable that a small percentage of users will close the window once they see the next page asking to send an email, without even reading it, loosing the "mailto:" link with the special token. They will also be lost on what to do; They'll expect an email, and won't understand the need to send one. In a more broader sense, changing the flow will require the users to think harder than usual on what to do, causing more users to leave and never finish the registration form
2. Matching the proper email If they happen to click on that mailto, they will have to remember which email they entered in the form, and will have to keep that in mind when sending the email. For me, if I click on a mailto, I'll have a GMail tab open to send that email, and I have 5 aliases registered. It will require an extra caution to select the appropriate one.
3. Having that email available If the user registers via his phone using an email not configured on that phone, he won't be able to send an email on that "mailto". This will require to copy/paste the link (and copying a mailto on a browser results in A LOT of changes on what is copied), find a way to share that copied data onto a device that has the appropriate email configured.
4. Custom emails Some users enter their email using the specialty of Gmail, such as user+label@gmail.com. When they'll send an email, they won't be able to add that "+label", causing the account creaton to fail
5. SPF/DKIM/DMARC, seriously? Wrapping your head around how these 3 standards works requires significat efforts. And yes, without them, you can not guarantee that the email is truly send by that domain. But still, many custom domains doesn't have a proper DMARC implemented and they can still spoof your account creation. In order to avoid this issue, the only best way is to keep the original flow : the services sends an email to the one the user gave.
Definitely, this is not a good idea to implement for so many reasons, but I agree on the original thought: The current flow has its own issues that needs to be resolved.
One flow I prefer, that doesn't fix everything but still remove a lot of headaches, is to send a code by email when the user has hit "Create my account". The next pages shows that the service expects the code sent by email. Once the user receives the code by email (ideally, having the code in the subject), they can enter it in order to validate their account and they are then automatically logged in a fully activated service.
This removes a few issues, such as:
Not having the email account configured on the same device Ending in a splash page right after creating an account Ending in a splash page when clicking on the link in the email Havign to connect to the service even though you did all the proper validation (I hate that)
The only issue remaining is to ensure the email arrives quite fast. But as long as we need email verification, we will have a hard time fixing this, as it is outside of both the service, and the user hand.
We did, tried something "original" in the login part, by offering a "one time login link" to our users instead of the standard flow. To be honest, we believe this was a bad idea.
The flow in itself is good and works fine (supposing email delivery works), but as @simonw perfectly said it, "resist the temptation to innovate around login!".
Offering that original "one time login link" is a frequent cause of support request because some users doesn't receive it, doesn't know what to do or how. They are not used to a change on login and this causes more troubles down the road than a standard flow.
That's why we later on decided to add the standard "password" login and tried to reverse that original flow. We still have users that have accounts with no password set though (still connecting via the original "one time login link").
In general, when this occurs, I stop doing whatever I'm doing, take a ibuprofen pill and go to bed for 20 minutes. After that, I have a massive headache but no aura.
What was odd is that the very next day, I got the same migraine, again! This rarely occurs to me (two days in row).
It was later that I realized that the screen light was low and that might be an explanation about why I got two migraines in two days.
Hopefully it can help someone else here :)
I created an account this morning but got no suggestions on my end... I don't know if I have to wait a few days or if what is done is done (ie: nothing).
We'll see.
"$10,264,760 saved on EC2" : I wouldn't be too happy if I were Jeff Bezos :D
Of course it's possible (and quite easy) to set up your own mail server, there are tons of guides out there for that, but this is just the tip of the iceberg! Once you have it up and running, you'll find yourself in a constant battle between those who spam you, and those who consider you spammer, real or not.
Using blacklists to filter out the bad incoming email is one efficient tool, but you need to rely on good, reliable and *honest* blacklist systems. Sorbs and Spamhaus comes to mind, compared to uceprotect and backscaterer. The last two asks you money to delist you regardless of what you did, and this is typically bad player playing on top of bad players. They do a race to the bottom by offering a racketing service.
But the worst is still that popular mail server uses these! Microsoft uses UCEProtect to filter email! So, as a mail provider like OP's, you find yourself in a pickle where you need to decide if you want your email to be delivered to Microsoft's users - that means paying, or not.
That is why managing emails has become a million dollars necessity if you want them to be up and running properly. You need to be close to the big ones, have a seat at the big tables where the decisions occurs and hopefully have your IPs added to whitelists.
To plug one very useful link in all this, I'd share Hetrix! (https://Hetrixtools.com), they monitor your IPs and notify you when they are listed on almost all the existing blacklists, and automatically delist them whenever possible, or provides you all the info to do to delist them. As a mail provider, this is on of the most useful tool there is.
Granted, we don't have chargebacks everyday, but we get some occasionals one that, at these price, would hurt way more.
Now, we still offer an alternative plan that is available only upon request (or on certain occasions). We call it the "Lite plan" at 30$ per year, where you have all the advantages of the premium plan, but without the SMTP sending part. If that interests you, just send a request to the support and we'll enable it for your account :=)
Our decision was to not use STARTTLS for port 25, but that's maybe not a good idea and we should allow it back: this would make both services happier ;)
In a nutshell: TLS via 465 works correctly, and STARTTLS via 587 too.
Don't hesitate if you want to weight on this, happy to discuss this further!
We are not Opensource, but that doesn't mean we track user's email (we don't, we wrote about it: https://improvmx.com/are-you-reading-my-emails/). On the contrary, screaming to anyone that one uses Opensource doesn't mean they respect user's privacy (like Forwardemail does): take their way of forwarding for instance: you need to add your email in the DNS settings, publicly available... they have a odd definition of privacy.
And don't get me started on their homepage full of misleading messages ... ;)