Re: Refreshing qmail server

Oliver


Op 01-12-18 om 12:35 schreef Oliver Welter:
> 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.

I only use mysql for dovecot retreiving mailboxes (homedir, password,
used_size).
For routing mails towards the mailboxes I use a single userid setup.
This was already my setup because I thought and still think this is the
fastest with using the least resources (no SQL-connections)


users/assign  (users/cdb trough qmail-newu)
+domain1-org:popuser:888:888:/qmail/domains/domain1-org/:::
+domain2-com:popuser:888:888:/qmail/domains/doamin2-com/:::

control/virtualdomains
domain1.org:domain1-org
domain2.com:domain2-com

control/defaultdelivery
|bouncesaying "This mailbox has been deactived"


The dot-qmail-files have lines like these:
  for using quotachecks on a user (default not used)
|/var/qmail/bin/mailquotacheck /popboxes/user1/ 634468

  for enabling autoresponder
|qmail-autoresponder  /qmail/domains/domain1-org/user1.auto
/qmail/domains/domain1-org/auto

  for some basic virus-checks
|filterto virus@localhost /var/qmail/bin/antivirus.pl

  for use in our frontent antispam-filter
#/var/qmail/bin/antispam.pl

  to forward the mail to emailaddress
[email protected]

  to deliver the mail in a users mailbox
/qmail/popboxes/username1/Maildir/


The file is build by the enduser itself using our own interface for this.



Best regards,
Pascal


> 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).
>>>
>>
> 
>