Re: Refreshing qmail server

Hello Carlos,

might you share your scripts / documentation? I am messing around with
vpopmail without success and really want to get rid of it. I have no
problem to write shell/perl to grab user information from a database but
to be honest I dont understand how to do the "routing" right....

Oliver

Am 12.12.18 um 12:21 schrieb Carlos García Gómez:
> Hello Oliver,
> 
> First of all, I would comment that I am very happy that QMAIL is still
> alive, especially with the interest you have all of you.
> 
> User management is, in my point of view, something that has not evolved
> at all. Vpopmail has been KO for a long time.
> In my case, I have my own implementation but because I use the
> QMAIL-LDAP version that has never worked with Vpopmail
> I never understood why this release was discontinued (Qmail-LDAP)
> because I think it's the best design
> 
> I would like to know how you implement user management (Vpopmail or other)
> How do you do it?
> 
> Regards.
> 
> 
> -----Mensaje original----- From: Oliver Welter
> Sent: Saturday, December 01, 2018 12:35 PM
> To: qmail
> Subject: Re: Refreshing qmail server
> 
> Hi Pascal, All,
> 
> just another question - are you still using vpopmail or is there another
> way to get virtual users working more "elegant" with qmail?
> 
> I use dovecot with mysql for IMAP so this part is all set, I "just" need
> a tool to route the mails and alias stuff based on some SQL tables. I am
> not afraid to write some scripts to resolve directory path / redirects
> from user names but to be honest I dont get the idea how routing is done
> in qmail atm.
> 
> best regards
> 
> Oliver
> 
> Am 29.11.18 um 13:41 schrieb Pascal Nobus:
>> 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).
>>>
>>
> 
> 


-- 
Protect your environment -  close windows and adopt a penguin!