Solved Email server options
-
@FATeknollogee Found this in their GitHub "We require Docker because that makes it a lot easier to handle updates and make the installations much more reproducible. Since Docker is the de-factor standard nowadays, we see no reason to change it. Maintaining both a dockerized and a plain Mailcow would be quite a lot of work."
That might be a show stopper for us. Given that their dev team isn't full time, and Docker puts the onus of support on the dev team primarily, this is a huge problem. Looks like there was an older version that wasn't so limited, but they've pulled back. This sounds to me like a dev team thinking about dev needs and ignoring production needs. That's up to them, but it a huge concern for us.
It used to be mailcow and mailcow:dockerized now the "production" option is gone. As is the full time team behind it
-
@scottalanmiller
That one is interesting. To me:- If the software maker says it is not production ready, most likely it is not. If it says it is production ready, it may be
- If the service provider says it is production ready, most likely it is
- If the end user says it is production ready, it could be
In this world of marketing gimmicks I usually believe more the service provider than the maker or end user. That is why I ask colleagues how their experience has been with a product and consider that experience in the decision making process.
Of course, that is only my (probably wrong) opinion.
-
From mailcow blog: https://mailcow.email/2019/04/18/mid-april-updates/
Doesn't specify who is in charge of support:
"For commercially used mailcows, please consider buying a support subscription or help to keep mailcow alive by donating.
I really, really miss working on mailcow full time. Only because of all amazing contributors, mailcow is still growing and gaining new features. Thanks!!!
Greetings to tinc.gmbh!
-
@dave_c said in Email server options:
If the service provider says it is production ready, most likely it is
This isn't true or in any way logical.
- They don't have any interest in thinking in a production way.
- They aren't responsible for our production.
- We don't have the slightest reason to think that they are qualified to even know.
Developers traditional are some of the worst people to talk about production readiness. They don't operate workloads, they create them. It's not their skin in the game when data is lost, that falls to IT (aka operations.) If you talk purely to developers, they will tell you some pretty crazy stuff (like you don't need backups.)
-
@dave_c said in Email server options:
If the end user says it is production ready, it could be
This is the ONLY person who can know. We work in IT, we alone know what is and isn't production ready. Developers can't know, vendors have an interest in tricking us.
-
@dave_c said in Email server options:
In this world of marketing gimmicks I usually believe more the service provider than the maker or end user. That is why I ask colleagues how their experience has been with a product and consider that experience in the decision making process.
Right, but the "service provider" here is the end user. So that's one and the same.
So in your example, the service providers are questioning the product model and development situation. And the maker (that none of us trust) is the one saying that it is production ready.
As a service provider that has tried their Docker process, their Docker process is fragile and risky. Not production ready. I'm sure it works "sometimes", but unless it works "reliably", it's not production ready.
-
@scottalanmiller
In this case, I am the service provider (as Curtis or NTG) and the end user is someone with a mailbox. I trust the service provider -
@dave_c said in Email server options:
@scottalanmiller
In this case, I am the service provider (as Curtis or NTG) and the end user is someone with a mailbox. I trust the service providerThat's later in the process. In the "dev / IT" scenario of deploying a product, we are the end users of dev's product. Right now, in the scope of "does it run", NTG is the end user saying "no, the deployment process does not work."
-
Once we put email into production, then our mailbox holders are the end users of "the service we provide from our email product."
But of the software itself, we in IT are the end users.
-
@scottalanmiller
Good point. Let me rephrase: I trust the ones deploying and servicing the software -
@dave_c said in Email server options:
@scottalanmiller
Good point. Let me rephrase: I trust the ones deploying and servicing the softwareYeah, that's what I was trying to say.
My issue there is that Docker makes that so much "assumed blind." Docker installs scare me because the assumed reason for using Docker is so that it is easy to install, but hard to fix - like driving front wheel drive in snow. It sounds like a great idea till you hit ice, start to skid, and realize that the ability to deploy easily comes at the cost of control in production.
Not that Docker can't be managed, but the logic behind it is skipping all the knowledge and effort of configuring a setup and just saving "issues" till production time. I'll take a lot of headache during deployment over outages in production anyday.
-
@scottalanmiller Or you could standardize on the two platforms that practically every business uses - G Suite or Exchange. Out of the hundreds of businesses I support I encounter two different kinds of businesses - those already on exchange/G-suite or those using the e-mail platform included with their web hosting which is a few GB of storage and basic POP/IMAP support. Any client I've picked up and converted to exchange is always thrilled with the ability sync their contacts/calendar items and the added bonus of a Apps for their smartphones/tablets that are polished and a joy to use in comparison to what they're used to. I don't know any other MSP/IT firm in the area that's pushing for any other solution. EOP1 licenses are cheap, it work's and ANY IT person can support it.
-
@scottalanmiller
It seems like I am very bad communicating. So I edited my reply @FATeknollogee to: It is to me and my use case -
@frodooftheshire said in Email server options:
Or you could standardize on the two platforms that practically every business uses - G Suite or Exchange.
Have used both, both are so much worse. We know Zimbra is better than those for us. Standardizing on "what everyone does" is a bad process. That's how you get bloat and expense. "Most people" make decisions based on a sales person's profit margins, not what is good for them. We know that our uptime with Zimbra beats O365, and that the product is nicer for us to use and manage. It saves us money month to month, and it lowers our support cost.
-
@scottalanmiller From what I'm reading in the last couple of threads, sticking with Zimbra seems the way to go.
-
@frodooftheshire said in Email server options:
Out of the hundreds of businesses I support I encounter two different kinds of businesses - those already on exchange/G-suite or those using the e-mail platform included with their web hosting which is a few GB of storage and basic POP/IMAP support. Any client I've picked up and converted to exchange is always thrilled with the ability sync their contacts/calendar items and the added bonus of a Apps for their smartphones/tablets that are polished and a joy to use in comparison to what they're used to.
We consider those "hobbies". We really never run into that. We find those on O365 and G Suite, sure. And on alternatives. And lots on O365 considering other options.
If those are the only things being compared, of course O365 seems great. And it's fine, but that makes it seem like an obvious choice rather than "just a contender."
-
@frodooftheshire said in Email server options:
I don't know any other MSP/IT firm in the area that's pushing for any other solution. EOP1 licenses are cheap, it work's and ANY IT person can support it.
That's because almost all MSPs you know are not MSPs but VARs and they make money selling those solutions. I know almost zero that recommend it and don't make money on it. As an ITSP I can tell you that supporting Zimbra is easier than supporting users on O365. And I can tell you that logic like "ANY IT person can support it" is a terrible reason, because that isn't what any business wants, they want something that makes sense. That even really bad people can support it makes no business logic and is a sales trick that people use to make VARs see dollar signs in being able to deploy cheap labor and charge a lot per hour. But an IT department should know that one good person is way, way more cost effective. It's the bottom line in the end.
EOP1 aren't cheap, they are "decent." There is no email platform worth looking at that doesn't have plenty of support in the market, even Exchange which is the most difficult. So availability of support is never a factor, there is more support available in the market than is needed across the board.
-
That's not to say that ITSPs that aren't VARs never recommend it. We do recommend O365 from time to time, but it's just one of many solutions. Are up to 400% the cost of Zoho, which is arguable a nicer platform anyway, it can be hard to justify. We have customers who want enterprise, hosted email, but are moving off of the O365/GSuite family because it just doesn't make sense for them.
As the cost of hosting has come down, the email providers aren't lowering cost (not the big two, anyway) making them priced more and more out of the market.
-
Just updated my mailcow server to the latest version
-
So the client is sticking with Microsoft, because their other systems are also Microsoft.
Here are the final numbers, unless someone freaks, they will be going with Office 365 Exchange Online Plan 1.
