Re: Refreshing qmail server

A point of view from a user.

I had the same problem: several Qmail-servers with a couple of thousand
users.
Changing towards Postfix or Exim was not really an option because we
have a backoffice build on .qmail-files, some scripts that where
activated when mail was send to, mailinglists, (de-)activate autoreplys,
etc.
After my search I ended up with s/qmail, it worked exactly as I wanted it.
No patches where needed after a blank install, and we had modern things
like TLS, IPv6 and smtp-authentication.
For antispam I use a front-proxy (assp), which is more specialized in
all these rapidly changing techniques.

The only thing I'm still missing is SRS.


For the rest: Install it, Configure it, and forget about it.
I've been running it for more then a year now without a single problem.
Thx Erwin!







Op 29-11-18 om 12:55 schreef Manvendra Bhangui:
> On Thu, 29 Nov 2018 at 00:06, Kai Peter <[email protected]> wrote:
>>
>> On 2018-11-25 19:32, Oliver Welter wrote:
>>> Hi All,
>>>
>>> Finally - some time there was an announcement that s/qmail and eQmail
>>> want to join forces - are there any news on this?
>>
>> Now, I was hoping that Erwin replies to this question - anyway.
>>
>> To be honest I couldn't say that aQmail will come out soon. To be more
>> honest I think it doesn't make sense to wait for it. May be it will or
>> it will not come out.
>>
>> IMHO there are the following alternatives:
>>
>> - eQmail 1.08.1 to 1.10
>> - indimail
>> - s/qmail
>>
>> The order is alphabetical. Whatever you like and prefer. I couldn't say
>> a lot about s/qmail or inidmail. If they would fit my needs, I never
>> would have created eQmail. eQmail works perfect to me. But Erwin and
>> Manvendra would say the same ;-)
>>
> Exactly. Ultimately it will be the end-user who needs to decide what
> he/she is comfortable with. But one need to get hands dirty to figure
> that out.
> 
> But It looks like there is just a tiny crowd left, who are still
> working with qmail/netqmail to add new features required in the
> current times.  Erwin, Kai Peter,  Amitai Schleier, Thibault Richards
> and myself. As far as indimail is concerned, it is a hobby for me. I
> keep on working on it because I love the way DJB coded qmail,
> ucsp-tcp, daemontools and all of his other works. Coding in djb style
> is lot of hard work, but fun. Even simple things like formatting
> strings is about carefully crafting together the fmt_str, fmt_ulong,
> etc instead of just one statement sprintf. You might have to put in
> few substdio_put statements instead of just one printf from the
> standard c library. But with substdio you know that your data has got
> out successfully (unlike printf). Maybe it is just me, but sprintf,
> printf are ugly. Arbitrary string lengths are ugly. I have seen
> Erwin's code and his code is also with lot of care like djb without
> arbitrary string lengths or variable sizes. s/qmail and eQmail are
> much smaller and simpler to install and maintain than indimail, while
> indimail has almost everything that I need to run and cater to large
> number of users, but it has far too many control files and environment
> variables to configure. qmailrocks has good documentation that any
> newbie can follow and set it up. Mostly you won't go wrong if you have
> simple needs and go with s/qmail, eQmail, qmailrocks or indimail-mta
> (a much smaller version of indimail).
>