New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Comments
I agree, AI is just a tool. A lot of code has been developed using AI. However, developers must review their code.
I've always had the same approach at work when it comes to subcontracting software development. Give them stuff you know how to do and that they'll do for cheaper... and that you can fix. It's a bit the same with AI.
What's the recommendation/best practice regarding panels. I have a new account I'm starting to configure. Should I do everything on panel.mxroute.com instead of Direct Admin as that will "future proof" me the best? It doesn't matter what panel I use because they both pull from the same data/or anything will be migrated in the future? Am I asking the right questions?
I would recommend using panel.mxroute.com. However, you'll see that all of my documentation is still for DirectAdmin. Fortunately I feel like the new panel needs less documentation.
There's a couple of remaining bugs for resellers but they're minor.
There's still several of these reseller packages left if anyone wants to get in on it. The reseller panel is now feature complete. Not to say there aren't valid asks for it, but the most pressing ones will be finished before anyone runs into a concern (handling disk quotas, for example, is inherited from DA and it's implementation is not what I want... so I'll be replacing it).
This should be the last time that we make a big changelog entry full of disconnected parts: https://docs.mxroute.com/docs/changelog/mxroute-3.9.html
By end of the month all of these pieces will be interconnected into one cohesive user experience that feels like the premium product I've always wanted to give you guys. I just wanted to share with you the milestone, the proper announcement of it, and the vision. We're almost there!
You guys might like what was added to reseller branding:
You've never been able to whitelabel MXroute to this degree before, this is practically a whole new service, only nothing was broken in the process, you only gained.
As a former QA manager, that's typical from developers. You need at least another person to make big changes. You also need to think really stupid, and that generally finds novel ways to break shit you didn't think anyone would do.
Use an AI to make a script that does this for you from the command line. Makes you feel better by making use of idling VPS.
Great service, glad to be with you all these years.
1) would you ever add feature to make application specific passwords for IMAP connections? So webmail could have different passcode than outlook mail client for example.
2) Moving to new unified servers, does this mean we can move/upgrade/change plans without having to completely setup everything again and imapsync all of our old e-mail?
Thanks.
I would in theory, but it would have to be a different software stack or at least dramatically different structure. If I implemented it right now there would be no way to know which password was used at any time, making a compromise even more stressful because you'd have to rotate them all at once because you wouldn't know which one was compromised. That's about the only benefit I see to it, and without that the benefit is negative.
That's the plan. Of course most users already can, but it's the moves between Regular, Large Storage, and Reseller that have been impossible (and still are for most users).
New "Calendar & Contacts" section added to panel.mxroute.com. Currently hidden for reseller customers using reseller's custom URLs, as dav.mxroute.com can't be white labeled at the moment. New billing system frontend almost done (https://management.mxroute.com). Once it's all done, docs.mxroute.com will be updated, hostbill email templates will be updated, and the new UX will be considered live.
Will customer access to the Direct Admin panel and the old billing system be removed once the new systems are soon officially live?
Thanks for the update.
Is it possible to add an app password for email acc?
I'm gonna try to kill access to accounts.mxroute.com (we'll see how much success I have), but direct DA access won't be going anywhere for probably 2-ish years.
With our software stack it just wouldn't make sense. You'd have to rotate all of the passwords at once the moment any password was compromised, and IMAP/SMTP can't use 2FA. It might make more sense a few years in the future when I've been able to fully build out the inbound stack from my own vision instead of from a stack managed by licensed software.
Please check your inbox, I'm having some problems logging in to my email account in outlook. Thank you
What purpose does continued customer access to DA serve?
Virtually none. But a few customers will insist that the spam folder delivery option in DA is worth it's continued use, until they find out why it isn't and open a support ticket asking why something happened that they didn't expect.
I was happy to add that calendar exactly because it's hosted with the reliable trustworthy provider - in my case disclosing that is a plus.
For resellers: I have configured automated DA backups of my reseller user accounts to my storage server.
Does the full DA account backup also include the contacts, or is that on a separate server?
This reminds me of the old joke:
They send my compatriot, Mujo, into space along with a dog, Jackie.
Ground control calls:
** Jackie, over.
Woof!
** Adjust the thrusters for a stable orbit.
Woof, woof!
** Mujo, over.
Yes?
** Feed the dog and don't touch any buttons!
Happy new year 2026 @jar .Thanks for providing good and stable service over the years
You as well! Can't wait to do a million times better for everyone in 2026 💜
Billing front end looks great.
I hate the Hostbill end-user UI so much.
Happy New Year!
The biggest delay to deployment came from the most insane compromise event to date. One attacker gained access to multiple Gmail accounts for customers, at least one claimed to have 2FA on it (so token compromised too?). The attacker used this to create a huge tangle of accounts spread throughout our platform, was able to get past outbound filtering, and I'll be surprised if t-online.de doesn't hate us right now. This was a huge event. I traced every avenue, assumed everything compromised, and concluded that this was a multi user event in which each user was personally compromised by methods external to the platform itself. I don't feel any relief that it wasn't a platform level compromise, because frankly I don't think that would have reduced my workload today any at all.
This attacker has made one thing abundantly clear: They want MXroute accounts.
What's less clear, but I highly suspect from specifics of their behavior, is that they want me to pay.
This has been one of the most exhausting days of running MXroute to date. I am not happy. I absolutely will retaliate with some powerful new monitoring around user account access.
Why can't we just have nice things, I just want to pay a few bucks for a solid email experience away from the corporate overlords.
And yet time needs to be dedicated to drop-kicks like this.
@jar I appreciate all you have, and will do for us and MXRoute.
Happy New Year, @jar! Thank you for your service.
Thank you for your work. Sounds like a not-fun way to end the year.
To me at least, it sounds like someone implemented searching for MXRoute related emails in their stealer malware, and just sold a batch of stealer logs to someone that was looking for them.
I don't think it's much more than that.
They would have to scan hundreds of millions of Gmail accounts to find a bunch of accounts with MXRoute related emails.
Some stealers already do these scans for crypto exchange emails.. I don't think it'd be that hard to add one extra keyword to the list.
Could be. On one of them, if I believe the customer, they obtained Gmail access behind 2FA. Because I changed the user's password and then they issued a pw reset to continue their phishing. So I'm heavily leaning toward malware.
How would the scammer have overcome 2FA?
Google account cookies last a while... The attacker probably grabbed those, and they haven't expired yet.