Solved Email server options
-
-
@Jim4232 said in Email server options:
Just a quick question, you already transitioned to Google for spam filtering, why have you discounted the GSuite option? GSuite for business might be something to consider, it would give you more options with the office type suite even if it is not used much it is still there.
We have not transitioned to Google for Spam filtering. They purchased our Spam filtering provider and transitioned us.
It is a horrible, unmanageable solution in the current form. Google obviously does not want former Postini customers to continue being customers unless they switch to full GSuite. Last I knew, you cannot even buy this solution. Only converted Postini customers get it.
GSuite is, as mentioned, not on the table. I do not want an office package. I want an email solution.
-
@FATeknollogee
Yes, it is.It is to me and my use case. The solution is a docker setup of production open source components (postfix, dovecot, rspamd, SOGo, etc.) and a PHP based control panel. Updated via git.
I started using it just after they moved to Docker. At the time the other contender was Zimbra Community but I went for mailcow: dockerized and I do not regret it.
Full disclosure: I use it to host both internal and customer's mailboxes but that is not my primary line of business. -
@FATeknollogee said in Email server options:
@Curtis @dave_c Is mailcow:dockerized considered production ready?
that's a question for the end users, not the company. Asking the wrong party will always give you weird answers.
-
@Jim4232 said in Email server options:
Just a quick question, you already transitioned to Google for spam filtering,
He didn't, he got stuck with the as the company he chose was bought by them.
-
@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.
