Mailing List Archive

On 25 Nov 2018, at 13:32, Oliver Welter wrote:

> 2) Does anybody here provide packages or at least build specs for
> installing s/qmail on debian? I am a big fan of using packages for
> staging/testing and not build/install on the boxes.

If my qmail installation went south and I needed something new, I'd want
to look at s/qmail too. One catch: without something like my destdir
patch (https://schmonz.com/qmail/destdir), I can't build the kind of
package I'd need in order to be willing to put it into production.
Hoping Dr. Hoffmann will integrate the destdir patch or something
morally equivalent. And I'm also curious to hear his answers to your
other questions.

- Amitai

Hello,

I’ve made https://qmailrocks.thibs.com/ but I still have to update it for Debian 9

Best Regards

Thibault

Envoyé de mon iPad

> Le 25 nov. 2018 à 19:32, Oliver Welter <mail@oliwel.de> a écrit :
>
> Hi All,
>
> after being a good friend for 16 years my qmail installation stopped to build as the underlying gentoo system changed too much so I am now forced to replace it quickly =(
>
> After evaluating the alternatives for a while, I think that s/qmail matches my expectations most, but I have two questions I can not answer myself.
>
> 1) I use qmail-spp and two self-written plugin to block password bruteforcing and rate-limit SMTP relay submissions - does s/qmail still provide a similar interface or offer solutions for this functionality "inline"
>
> 2) Does anybody here provide packages or at least build specs for installing s/qmail on debian? I am a big fan of using packages for staging/testing and not build/install on the boxes.
>
> Finally - some time there was an announcement that s/qmail and eQmail want to join forces - are there any news on this?
>
> best regards
>
> Oliver
>
>
> Protect your environment - close windows and adopt a penguin!

On Sun, Nov 25, 2018, at 12:32 PM, Oliver Welter wrote:
> after being a good friend for 16 years my qmail installation stopped to
> build as the underlying gentoo system changed too much so I am now
> forced to replace it quickly =(
>
> After evaluating the alternatives for a while, I think that s/qmail
> matches my expectations most, but I have two questions I can not answer
> myself.

Hi, Oliver.

I'm not trying to persuade you to not use s/qmail, but I did think I should at least point out Amitai Schleier's set of qmail patches and programs:

https://schmonz.com/qmail/

It's a collection of patches and programs based on or designed for netqmail. He also has packaged them for pkgsrc. Even if you don't use pkgsrc, the packages are possibly of interest if you want to just see what he sets up as a default set of patches.

I only mention this because I think Amitai's work would yield something that is the closest to your 16-year-old friend that stopped building. And again, I'm not saying anything against s/qmail; it could very well be the best choice, but I just wanted to make sure you were aware of Amitai's stuff.

Regards,

Lewis

On 25 Nov 2018, at 22:03, J. Lewis Muir wrote:

> https://schmonz.com/qmail/
[...]
> I only mention this because I think Amitai's work would yield
> something that is the closest to your 16-year-old friend that stopped
> building.

Now that you mention it, maybe pkgsrc is a good candidate. I was
hesitant to mention it given the OP was looking for Debian packaging.
But if any decent packaging will do, try setting up pkgsrc and
installing mail/qmail. If you don't like it, it uninstalls cleanly; if
you do like it, that might be in part because, inspired by Gentoo's
qmail package, I recently incorporated qmail-spp.

pkgsrc's qmail should be no less portable than netqmail itself. You
might also want qmail-run, though I wouldn't expect the init scripts to
integrate nicely on anything other than NetBSD. (Yet -- it's on my
list.)

Like Lewis, I very much don't want to discourage anyone from running
s/qmail. I'm grateful that it exists and intend to try it myself. In the
meantime, I've happily borrowed various bits of s/qmail code and hope to
keep doing so. :-)

- Amitai

On 2018-11-25 19:32, Oliver Welter wrote:
> Hi All,
>
> after being a good friend for 16 years my qmail installation stopped
> to build as the underlying gentoo system changed too much so I am now
> forced to replace it quickly =(
>
I don't want install the gentoo packages, but I just did compile it
(with USE=ssl only, which is the default) using the following command:

ebuild {/path/to/portage}/mail-mta/netqmail/netqmail-1.06-r2.ebuild
compile

and it builds fine. So it doesn't looks like an Gentoo issue to me.
Could you provide a more detailed error message? And additional the
gcc version and architecture? Maybe it is possible to solve this
issue.

I do compile djb like stuff quite often on Gentoo and doesn't have real
issues.

--
Sent with eQmail-1.11 beta - a fork of djb's famous qmail

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


>
> best regards
>
> Oliver
>
>
> Protect your environment - close windows and adopt a penguin!

--
Sent with eQmail-1.11 beta - a fork of djb's famous qmail

On Thu, 29 Nov 2018 at 00:06, Kai Peter <kp@lists.openqmail.org> 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).

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 <kp@lists.openqmail.org> 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).
>

Hello Kai,

to be honest the problem was not qmail itself but mainly vpopmail/mysql
support which creates circular deps and conflicts with
mariadb/virtual-mysql and some other blockers in several libs.

I used gentoo and linux-vserver (all self compiled) for all my hosting
over years which was "expensive" but ok when you run a lot of boxes but
as I moved to new hardware and a new software stack based on debian last
year and this qmail server is the last bastion running gentoo its also
time to get rid of this...

Oliver

Am 28.11.18 um 19:12 schrieb Kai Peter:
> On 2018-11-25 19:32, Oliver Welter wrote:
>> Hi All,
>>
>> after being a good friend for 16 years my qmail installation stopped
>> to build as the underlying gentoo system changed too much so I am now
>> forced to replace it quickly =(
>>
> I don't want install the gentoo packages, but I just did compile it
> (with USE=ssl only, which is the default) using the following command:
>
> ebuild {/path/to/portage}/mail-mta/netqmail/netqmail-1.06-r2.ebuild compile
>
> and it builds fine. So it doesn't looks like an Gentoo issue to me.
> Could you provide a more detailed error message? And additional the
> gcc version and architecture? Maybe it is possible to solve this
> issue.
>
> I do compile djb like stuff quite often on Gentoo and doesn't have real
> issues.
>


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

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 <kp@lists.openqmail.org> 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!

Hi Oliver,


> Am 01.12.2018 um 12:35 schrieb Oliver Welter <mail@oliwel.de>:
>
> 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?

vmailmgr was always the competitor for vpopmail -- and still is.

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

What do you mean by 'route'? Standard delivery?

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

s/qmail provides a native recipient interface for vpopmail and vmailmgr in case local maildirs do exist.
Thus, those accounts are initially accepted for SMTP RCPT TO:

Do you expect more?

Apart from that: Since you use Dovecot as IMAP server, s/qmail also has a authentication hook for that.

Check s/qmail's documentation on-line.

Regards.
--eh.

> 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 <kp@lists.openqmail.org> 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!
>

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE

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
user2@hotmail.com

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 <kp@lists.openqmail.org> 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).
>>>
>>
>
>

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 <kp@lists.openqmail.org> 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!

Hi All,

thanks to Erwin I finally made it and have my system now running for a
"test domain" and it looks promissing.

I documented the setup using sqmail based on debian 9 on my website
https://www.oliwel.de/basissystem-und-sqmail/

I did it in german but its only very little text and a lot of config
dumps so it should be worth even if you are not familiar with german
language.

Feedback is welcome - the part about SMTP Auth with blacklisting, etc is
still work in progress and will be published once I am done.

best regards

Oliver

Am 25.11.18 um 19:32 schrieb Oliver Welter:
> Hi All,
>
> after being a good friend for 16 years my qmail installation stopped to
> build as the underlying gentoo system changed too much so I am now
> forced to replace it quickly =(
>
> After evaluating the alternatives for a while, I think that s/qmail
> matches my expectations most, but I have two questions I can not answer
> myself.
>
> 1) I use qmail-spp and two self-written plugin to block password
> bruteforcing and rate-limit SMTP relay submissions - does s/qmail still
> provide a similar interface or offer solutions for this functionality
> "inline"
>
> 2) Does anybody here provide packages or at least build specs for
> installing s/qmail on debian? I am a big fan of using packages for
> staging/testing and not build/install on the boxes.
>
> Finally - some time there was an announcement that s/qmail and eQmail
> want to join forces - are there any news on this?
>
> best regards
>
> Oliver
>
>
> Protect your environment -  close windows and adopt a penguin!
>


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

Hello,

It sounds really cool !

If you agree, I'll update my guide https://qmailrocks.thibs.com/ based on yours (and I should rename it sqmailrocks ????)

Best Regards

Thibault


-----Message d'origine-----
De : Oliver Welter <mail@oliwel.de>
Envoyé : mercredi 16 janvier 2019 19:15
À : qmail mailing list <qmail@list.cr.yp.to>
Objet : Re: Refreshing qmail server

Hi All,

thanks to Erwin I finally made it and have my system now running for a
"test domain" and it looks promissing.

I documented the setup using sqmail based on debian 9 on my website
https://www.oliwel.de/basissystem-und-sqmail/

I did it in german but its only very little text and a lot of config
dumps so it should be worth even if you are not familiar with german
language.

Feedback is welcome - the part about SMTP Auth with blacklisting, etc is
still work in progress and will be published once I am done.

best regards

Oliver

Am 25.11.18 um 19:32 schrieb Oliver Welter:
> Hi All,
>
> after being a good friend for 16 years my qmail installation stopped to
> build as the underlying gentoo system changed too much so I am now
> forced to replace it quickly =(
>
> After evaluating the alternatives for a while, I think that s/qmail
> matches my expectations most, but I have two questions I can not answer
> myself.
>
> 1) I use qmail-spp and two self-written plugin to block password
> bruteforcing and rate-limit SMTP relay submissions - does s/qmail still
> provide a similar interface or offer solutions for this functionality
> "inline"
>
> 2) Does anybody here provide packages or at least build specs for
> installing s/qmail on debian? I am a big fan of using packages for
> staging/testing and not build/install on the boxes.
>
> Finally - some time there was an announcement that s/qmail and eQmail
> want to join forces - are there any news on this?
>
> best regards
>
> Oliver
>
>
> Protect your environment - close windows and adopt a penguin!
>


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

Hi Thibault,

feel free to use it - as long as you don't blame me if it does not work ;)

Oliver

Am 18.01.19 um 11:24 schrieb Thibault Richard:
> Hello,
>
> It sounds really cool !
>
> If you agree, I'll update my guide https://qmailrocks.thibs.com/ based on yours (and I should rename it sqmailrocks ????)
>
> Best Regards
>
> Thibault
>
>
> -----Message d'origine-----
> De : Oliver Welter <mail@oliwel.de>
> Envoyé : mercredi 16 janvier 2019 19:15
> À : qmail mailing list <qmail@list.cr.yp.to>
> Objet : Re: Refreshing qmail server
>
> Hi All,
>
> thanks to Erwin I finally made it and have my system now running for a
> "test domain" and it looks promissing.
>
> I documented the setup using sqmail based on debian 9 on my website
> https://www.oliwel.de/basissystem-und-sqmail/
>
> I did it in german but its only very little text and a lot of config
> dumps so it should be worth even if you are not familiar with german
> language.
>
> Feedback is welcome - the part about SMTP Auth with blacklisting, etc is
> still work in progress and will be published once I am done.
>
> best regards
>
> Oliver
>
> Am 25.11.18 um 19:32 schrieb Oliver Welter:
>> Hi All,
>>
>> after being a good friend for 16 years my qmail installation stopped to
>> build as the underlying gentoo system changed too much so I am now
>> forced to replace it quickly =(
>>
>> After evaluating the alternatives for a while, I think that s/qmail
>> matches my expectations most, but I have two questions I can not answer
>> myself.
>>
>> 1) I use qmail-spp and two self-written plugin to block password
>> bruteforcing and rate-limit SMTP relay submissions - does s/qmail still
>> provide a similar interface or offer solutions for this functionality
>> "inline"
>>
>> 2) Does anybody here provide packages or at least build specs for
>> installing s/qmail on debian? I am a big fan of using packages for
>> staging/testing and not build/install on the boxes.
>>
>> Finally - some time there was an announcement that s/qmail and eQmail
>> want to join forces - are there any news on this?
>>
>> best regards
>>
>> Oliver
>>
>>
>> Protect your environment - close windows and adopt a penguin!
>>
>
>


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