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
@Jarland explains it here https://billing.mxroute.com/index.php?rp=/knowledgebase/42/What-is-your-relation-to-mxrouteio.html
Cheers!
But to be clear, for the benefit of @JoeMerit, you have nothing to do with the running support of MXRoute?
I do answer many tickets there as well, yes
Edit: not sure I got your question right, its 7am and am damn tired.
Yes. yes. This... This is why we need you off the admin team. It's like reading a young @wss before he used up all his grade A material on script kiddies for the 1000th time.
Miguel most definitely helps with support on mxroute.com, and if your ticket isn't waiting a month for a reply, you have him to thank
Jalrand = @jarland ? el typo ?
I was probably drinking.
I had not noticed it, at all!
He's a functional drinker.
Well at least we know @JoeMerit’s cancellation wasn’t in vain.
Had to log in after a couple of years just to say i love Mxroute.
See you guys on 2020.
o/
+1 for MXRoute, I just set the emails up and leave the rest to @Jarland; one less thing for me to worry about.
We'll have news very soon. Starting to work on some features you guys are going to love.
But, no promises yet, and won't mention yet what we're talking about... :P
Stop scaring us...
Hopefully it has nothing to do with the choice of using cpanel, as it's beyond Perfect! The SSL and other functions make it marvelous for those of us that know how to twiddle around. Coupled with the fact that it's familiar it makes all the complex matters easy as pie. I hope cpanel stays now that I've made it juuust right
Nah, but I'm going to completely overhaul how you interact with cPanel this year. I'm almost done
Am I the only one that prefers the original MXRoute? Wonderful simplicity.
Yeah, because you wouldn't believe how often I got this ticket:
"Oh you don't have this complex feature that almost no one wants? I guess I'll just have to take my 60 cents elsewhere."
That really died down with cPanel. Just letting them handle all the implementations I didn't want to waste time on like per domain archiving of sent/received, etc.
Guess I'm just a simple man with simple tastes.
FWIW, I've not setup any of my MXRoute cPanel accounts, despite the fact I have a couple on the UK plans, I just end up setting up new domains on my original plan.
I hope you can fix the issue where cpanel allows the cpanel account owner to get into all of the mailboxes.
-_-.. Fine but if it's new and different then I'm going to open 10 tickets about it. But then realize it's for the best and be too proud to say anything else about it. -every annoying user that thinks a cheap plan means managed.
Depends on your use case. If your doing it just for yourself then it doesn't matter. If your doing it for clients one would assume you give just sign up for individuals accounts for them with their own cpanel. Art tiffs price point is really very affordable and worth while IMO
While I can see the perspective, I'd have to disagree that it's an issue. Adding barriers like that for account admins to manage their service would possibly please 1-5 customers while increasing support tickets for the rest. It would, at best, be a cosmetic barrier because when you create an email account you have the authority over it, from the perspective of Linux file ownership down to the ability to reset it's password. If someone should be delegated that authority and it should be removed from you, they should have their own admin account. If that delegation is split on the same domain, I'd say there's a trust issue within the organization and a lack of IT leadership structure.
Now if I'm mistaken and you're referring to the cPanel user password functioning on webmail login for any of their users, that part is disabled.
Of course you're entitled to your own viewpoint, but it looks to me like it's a minority view. EVERY other email host that I know of doesn't let the admin access user emails except for certain types of enterprise accounts where it's a wanted feature. There is good reason for that. I don't want to give someone a mailbox and tell them I won't go into it. I want to give them the mailbox and tell them I can't go into it. Sure, there is a level of trust in both giving and accepting the mailbox, but it's best to get rid of any possible doubt.
A password reset is different: if the admin resets the password, the user at minimum is locked out of the mailbox and knows something is up. Better still would be for the user to enroll a backup address when they get the mailbox, so if they need a reset, the reset link gets sent to the backup address without the admin being able to see it. Or there could be knowledge-based authentication (what's your pet's name) etc.
So I just see this as a weird cpanel artifact that one can possibly find rationalizations for after the fact, but IMHO it decreases mxroute's usefulness. I don't think it would exist if it weren't for the accident of using cpanel.
So EVERY host you know of doesn't have an option to click on webmail for a sub user? Additionally they'll need to have no file manager, shell access, or backup options for that to be even remotely of value.
I ask because I'll start logging into every major cpanel host around the world if that's legitimately your claim and I'll either find out that you're right or that what you just said was something between hyperbole or dishonesty. Alternative being you don't know of many cPanel based hosts which I would find a bit odd for you.
Also can we talk about why you're giving away mailboxes to people you don't have that kind of trust relationship with? You do know you're accountable for their actions right?
Literally what I just read was "I don't want people, that I give things to, to have to trust me, but they'll have to trust me."
Sorry, I should have said "every email host I've used". There are obviously lots that I know of but haven't used and whose practices I can't report with certainty.
Fastmail, Migadu, Gandi, Tucows, and my home ISP (I have used all of these) all offer multiple mailboxes and do NOT allow the admin to get into them. The 800 pound gorilla is Gmail so I'd like to know how they handle this.
Those are web hosts for whom email is a usually-almost-irrelevant side feature whose functions or misfunctions nobody really cares about. I don't think they are operating in the email space the way mxroute is, so if they're not following good email hosting practices it doesn't really matter.
Unless mxroute sees itself as yet another cpanel shared hosting provider except its web hosting feature happens to be busted, I think it should act like an email host and not a web host.
Trust but verify. I want them to be able to verify that I didn't access their mailbox, by establishing that I can't access their mailbox.
They're friends and family, there's not an issue of their abusing the mailbox. But in any circle there will always be situations where someone seems to know something they're not supposed to know. If there is a possibility that email spying is going on, suspicions will fall on the email admin. So it's best for that person's sanity to remove the possibility.
Yes, what's the problem? If you borrowed a mobile phone from your buddy and they told you "by the way, I promise not to listen to them, but the phone is set up to record all your conversations" would you want to use that phone for anything private? Especially if (say) you and the phone owner had both been dating the same person? I don't mind lending someone my phone but I'd want to turn off the recording "feature" instead of asking them to trust me.
This is just basic information security. Minimize the number of trusted entities in the system. If I can remove myself as a trusted entity then good practice is that I should do so.
Yeah sorry, I tried lol. I just can't wrap my brain around it. To me I see the concept as being a shift from the barrier of choice to the barrier of another choice. A security barrier in my mind is one that requires someone to have something they shouldn't to get beyond it, where as I see removing one method of access from an admin as more like removing a choice. With or without it the only significant barrier that exists is the desire to access it, the rest is merely the method chosen to do it.
Oh well, I tried :P
I can't say I understood the entire post but yeah, that's what I mean, removing the choice from the admin creates a security barrier where there wasn't one before (to get past it, the admin then needs to have something they shouldn't). From an infosec or privacy perspective, if you can replace a trust requirement with a security barrier, you should always do so.
How is it a security barrier if the admin can just reset the password and let themself in?
The choice to access something you should have administrative rights over isn't a security barrier is what I mean, it's a choice barrier. You could choose to download a zipped backup, enable archiving to mirror it, forward incoming silently, set a filter that forwards above user level, or reset the password. All of those are vital features for someone, not vulnerabilities because they are the account admins.
Removing one choice isn't adding a security barrier, it's at best pandering to a singular and isolated perspective. Perhaps making it less enticing in the moment if the admin is easily tempted but lazy. But by no means is that removing any ability for the admin to be considered capable of accessing data unless the admin is being dishonest, in which case they could simply choose to be dishonest about one more layer.
This to say, a choice barrier is "I can but I won't" and a security barrier is "I shouldn't be able to."
I couldn't agree more. Even under exchange you are able to delegate an additional user to have access to a mailbox. The trust dynamic of a IT manager and their clients is one where this is always a possibility.
If you want true seperation you'll need to make a dedicated account set it up and have them change the password. Otherwise this isn't probably what your looking for. At this price point i don't believe it's meant to be a "reseller" account by any stretch of the imagination.
I mean we could definitely say a point of agreement is mxroute isn't suitable for a user who wants to be the admin of a sub user but wants to lack methods of accessing their data. That would certainly be a fair point.
I'd argue that couldn't be true anywhere, and that any feeling that it is would be based on a lack of creative thinking on how to utilize the available features (IMO), but it would be objectively true regardless.