Mailing List Archive

> IMHO quite complicated for a mortal like me :)
You shouldn't say so. I didn't say that you are wrong, just pointed out
that it "could" led into missunderstandings -⁠ IMHO.

>
> # Files are edited in the installation directory, then copied.
> # There are 40 arguments to idedit after the filename,
> # showing the positions of each byte in the following ten ints:
> # uida, uidd, uidl, uido, uidp, uidq, uidr, uids, gidq, gidn.
> # Normal little-endian positions are n n+1 n+2 ... n+39 for some n.
> # Normal big-endian positions are n+3 n+2 n+1 n n+7 ... n+36 for some
> n.
>
> setup:
> mkdir /var/qmail
> ./idedit install-big XXX
> ./idedit qmail-lspawn XXX
> ./idedit qmail-queue XXX
> ./idedit qmail-rspawn XXX
> ./idedit qmail-showctl XXX
> ./idedit qmail-start XXX
> ./install-big
> cp /var/qmail/boot/binm1+df /var/qmail/rc
> chmod 755 /var/qmail/rc
> echo '|fastforward -d /etc/aliases.cdb' >
> /var/qmail/alias/.qmail-default
> chmod 644 /var/qmail/alias/.qmail-default
> hostname | grep -q '\.'
> ./config-fast `hostname`
Well known. Beside others, I did replace the whole install routine from
my current development version. Instead of thousand lines of C code I
have now hundred left -⁠ round about.

I know I was not accurate enough. What I meant was if a distro does
reserve the UID/⁠GID's and does use the same qmail usernames and groups
always, it will work. This doesn't mean that binaries will be portable
between different distros nor updates of a distro.

----
Sent with eQmail-1.10-dev

Op 17-05-16 om 17:52 schreef Henning Brauer:
> * Erwin Hoffmann <feh@fehcom.de> [2016-05-15 11:13]:
>> Still there is a substantial user base out there
>
> yes.
>
> Let's face it: new qmail installs are a rare exception.

As so with postfix, exim, sendmail or whatever.
User just use the package available in their OS.
If p.e. qmail would be a mailer in Cpanel, the user-base would grow
exponential.


> TLS is a nightmare.
> openssl has APIs designed to drive the consumers insane (they provoke
> bad bugs)
> gnutls is a bad joke
> libressl's libtls API is much better, but very young and probably not
> widepread enough yet

I'm afraid whe're stuck with openssl for a long time, just because every
other package assumes you have openssl. Ever looked at the docs when
requesting for a certificate?


>> c) Integration into different OS is still a battle. At least we need to consider *BSD, Debian,
>> perhaps Ubuntu and the Rad Hat based (rpm) systems like SuSE (in Germany).
>
> no. POSIX. period.
>
> and things like file system locations are up to the packagers anyway.

That's right but if the guys at Redhat/Debian don't make a package for
Qmail, then there is no RPM/deb.
And to my knowledge the talk was there to make the source available at
these packages themself.

Personally I would like to add slackware-packages.
But if there's a cut/paste for source-packages then that's also OK for me.
cd /usr/local/src
wget http://...
cd ...
./configure
make
make install


> to be honest, I consider that wasted effort. the world moved on. qmail
> was extremely important at its time, but isn't worth the effort since
> it is a) way too different which makes it way too hard to audit and b)
> its architecture was sane in '98 - but plain doesn't cut it 15 years
> later. This is fundamental and basically unfixable without turning
> qmail upside down.
>
> qmail's place is largely in the history books now. qmail brought the
> concept of privilege seperation - even if it wasn't labeled so - to
> us. Not just MTAs, qmail was one of the first visible bits ever, with
> great influence to everything after. Again, not just MTAs.

as expected: I don't agree.
If you take a look to for example Cpanel: well it's just the same as 20
years ago, only there's a fronted for the commands you make on your shell.
It's even so that when you want to fine-tune the documentation says:
login to the server by ssh...

Postfix/Sendmail etc didn't change, mails are still going in out with
the same SMTP and POP-commands as in the 90's.
Yes, we moved to 64bit and now have IPv6, but all the rest is just
add-ons. The base of all the MTA's is not changed.


> Today, who's still using qmail? Two groups, imho:
> 1) large deployments effectively using their own fork
> 2) a couple of freaks that can't let go :)
>
> the first group doesn't need a nicely packaged MTA; they have forked
> anyway.

Well they do!
If you read my original mail what started this thread that was exactly
what we needed.
Because all of the forks was installing Qmail a nightmare. I counted 7
patches for qmail-smtpd which had to be done in the right order.
After so many years we had lots of qmail-installations all with
different patches. (for a backup-MX you don't need TLS-patches for
outgoing mail, for mailing-listservers we needed separate queues, for
outgoing mail you don't need RBL's, etc)


> the second will probably never agree on direction.

Agreed with that, also after reading this thread, both eQmail s/sqmail
and Indimail have not quit exactly the same direction,
BUT: I've seen the discussions and we are all learning from eachother.
I really don't mind if there is more than 1 Qmail-successor, it's just
like ice-cream. In the old-days there was only vanille, now you have
chocolat, mokka, lemon, and so on.

I've been working for qmail since 1997, and when there was a problem it
was always with a patch and quickly found. Just spend more then 1 hour
of searching in the exim-config to adjust one setting, only 2122 lines
to read!
So I hope the qmail's are there for another 20 years (until my
retirement:-))

So thanks to Daniel for rock-solid base, and also for Erwin, Kai and
Manvendra (alphabetic order) for picking up the work, without these guys
I would have probably already eaten both of my shoes!

I'm not a guru, but I don't see email vanishing for the coming 20 years,
there's even a chance that the totaly-outdated SMTP-protocol will survive.

P.S.
eQmail s/qmail is missing in the wiki-page of qmail....


Best regards,
Pascal

On 2016-05-17 17:52, Henning Brauer wrote:

> gnutls is a bad joke

Henning,

I would appreciate to know the reasons why you said so. Just your
points, short.

Thanks
Kai

----
Sent with eQmail-1.10-dev

People,


On 2016-05-15 04:11, Manvendra Bhangui wrote:
> On 13 May 2016 at 22:05, Pascal Nobus <pascal@nobus.be> wrote:
>> Just a post to give my findings about replacement of a running
>> qmail-1.03 system.
>>
>>
>> First I tried to install eQmail, however I bumped into ipv6 and
>> SSL-support for tcp-server, and insteadoff patching it myself, I
>> downloaded it from fehcom.
>> And when I was there I took a short look at the doc's about s/Qmail.
>> After reading this I thought: just give it a try.
>>
>> And well, I had a deamontool/tcpserver/qmail with IPv6 SSL running in
>> 10
>> minutes!
>> I copied over my users,virtualdomains,rcpthosts, and the base was
>> fine.
>>
>
> I have myself taken a look at s/qmail. Dr Erwin writes code well and
> in the same style as DJB. I have shamelessly integrated his code in
> indimail. QHPSI was his first work that I really liked. Unlike other
> virus scanning interfaces, QHPSI does the scanning inline. i.e. It
> scans the email while qmail-queue is reading the data from
> qmail-smtpd. There is no additional disk I/O it incurs.
>
>> After that I had to install some other tools I needed:
>> - qtools + patch (to make filter_to which I use in .qmail-files)
>> - bglibs, qmail-autoresponder
>> - unbound (new caching dns-server insteadoff djbdns)
>> - qmail-control-script (to stop/start/view queue, purge queue)
>
> qtools, qmail-autoresponder are already packaged with indimail-mta and
> indimai. indimail-mta/indimail has a modified qmail-qread to list
> queues like qmHandle and qmail-rm to purge the queue.
>
>> Because s/qmail did went so fine, I didn't try indimail (so I can't
>> tell
>> if it's good or bad). Nor smtp-auth is installed (will give it a try
>> later on).
>> I'll maybe take a look at eQmail indimail again on some other servers,
>> but I really liked the smooth s/qmail-setup.
>> I've been running now for 1 week in test mode, and 1 day in normal
>> load.
>> Had no crashes and TLS is working fine.
>>
>> Erwin: thx for the great job you already did.
>> Kai/Manvendra: I'll have to test your products further.
>>
>
> If you want to try indimail, you should be trying indimail-mta instead
> of indimail. indimail-mta includes qmail + all patches, daemontools +
> ucspi-tcp, tls, ipv6, dkim, srs, spf, etc. indimail is a huge package
> which includes courier-imap, virtual domain using MySQL as backend and
> many other tools
>
> To be honest, I have not been good at documentation and users may find
> it difficult to build it from source. But the git repo is there and
> all it requires is make; make install (not make setup check like
> qmail). An easy way to try out indimail-mta is to use the docker
> images at (assuming you know about docker and have the docker-engine
> installed on your machine)
>
> http://indimail.blogspot.in/2016/04/using-docker-engine-to-run-indimail.html


A docker container is a great idea! I had been rolling my own qmail for
a long time but finally felt the pressure to reduce the effort of
re-installing after a clean Fedora install to the latest version - which
I do after every two or three versions or so - and changed to eQmail
about a year ago which went very nicely! I would prefer a qmail Docker
image that has EVERYTHING in it but also has a nice I/F to turn options
on or off as desired.


>> Why not bundle your works eQmail s/Qmail and Indimail in one project?
>> If you bundle your strength you could be the leader in MTA, replace
>> the
>> awfull (my personal opinion) exim/postfix.
>
> This is a good suggestion. Willing to give it a try but not sure how
> to take this forward. Maybe it requires someone to play the role of a
> facilitator bring us all together and drive it as a project with
> concrete goals.


I am not likely to ever change from qmail so a resurgence of life for it
by a new, multi-developer version would be great for me . . if it were
possible . .

Thanks for the support over the years people!

Regards,

Phil.
--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au