The subject sounds like a naive question, but let me provide some
background.
I have several qmail servers I put together, both many years old,
some going back to the nineties. There has been some local patching
over time, as my needs developed, but they've been stable for a lot
of years at this point.
This spring, Google decided to be dicks, and started rejecting my
email, with very uninformative messages in the bounces.
Sparing everyone here a detailed rant, it boils down to I need to
bite the bullet and tackle a bunch of reasonably-necessary features
like DKIM, TLS, etc.
As I'm running a bunch of ancient 32-bit distributions, for which the
necessary development libraries are not available, I guess now's
the time for a big update on the whole mess.
What I'm looking for is a contemporary and reasonably complete set
of instructions for pulling this all together.
On the surface, it looks like the venerable qmailtoaster.com site
will cover my bases, but I was wondering if the community is aware
of other options.
Vague arm-wavy concerns:
- qmailtoaster.com only seems to discuss CentOS 5, which is EOL,
and I'm worried that there may be a lot of divergence from what
a contemporary Fedora-ish distribution would need.
(Heck, I've already sparred with daemontools vs systemd, and that
was annoying...)
- I'm lazy, and want to avoid the manual gathering and patching.
I hoped I could find an all-signing, all-dancing container I would
just deploy, or a set of binaries, to save myself time.
I did find https://github.com/mbhangui/indimail-mta , but on the
surface, that look like a whole ecosystem, but I can't tell how
divergent it is from a classic qmail server.
As I did deeper, it looks like they actually have a lot of binary
packages for several OS distributions.
So - anyone willing to volunteer an opinion?
- Go the route of building from source a la Qmail Toaster?
- Dive deep into indimail-mta and the curated binaries? (Impressive
work, whoever's running that project, BTW.)
- Some other option I haven't considered? I'm not married to any
particular BSD/Linux distro.
As always, I'd appreciate any feedback...
--
Brian Reichert <reichert@numachi.com>
BSD admin/developer at large
background.
I have several qmail servers I put together, both many years old,
some going back to the nineties. There has been some local patching
over time, as my needs developed, but they've been stable for a lot
of years at this point.
This spring, Google decided to be dicks, and started rejecting my
email, with very uninformative messages in the bounces.
Sparing everyone here a detailed rant, it boils down to I need to
bite the bullet and tackle a bunch of reasonably-necessary features
like DKIM, TLS, etc.
As I'm running a bunch of ancient 32-bit distributions, for which the
necessary development libraries are not available, I guess now's
the time for a big update on the whole mess.
What I'm looking for is a contemporary and reasonably complete set
of instructions for pulling this all together.
On the surface, it looks like the venerable qmailtoaster.com site
will cover my bases, but I was wondering if the community is aware
of other options.
Vague arm-wavy concerns:
- qmailtoaster.com only seems to discuss CentOS 5, which is EOL,
and I'm worried that there may be a lot of divergence from what
a contemporary Fedora-ish distribution would need.
(Heck, I've already sparred with daemontools vs systemd, and that
was annoying...)
- I'm lazy, and want to avoid the manual gathering and patching.
I hoped I could find an all-signing, all-dancing container I would
just deploy, or a set of binaries, to save myself time.
I did find https://github.com/mbhangui/indimail-mta , but on the
surface, that look like a whole ecosystem, but I can't tell how
divergent it is from a classic qmail server.
As I did deeper, it looks like they actually have a lot of binary
packages for several OS distributions.
So - anyone willing to volunteer an opinion?
- Go the route of building from source a la Qmail Toaster?
- Dive deep into indimail-mta and the curated binaries? (Impressive
work, whoever's running that project, BTW.)
- Some other option I haven't considered? I'm not married to any
particular BSD/Linux distro.
As always, I'd appreciate any feedback...
--
Brian Reichert <reichert@numachi.com>
BSD admin/developer at large