I see, you are busy with Notqmail .... > Am 03.04.2021 um 19:04 schrieb Manvendra Bhangui <email@example.com>:
> On Sat, 3 Apr 2021 at 18:52, Erwin Hoffmann <firstname.lastname@example.org> wrote:
>> Hi qmailer,
>> I finished and published s/qmail 4.1. In case you are interested in a modern Qmail system, you might wont to consider it.
>> Here, you find the new enhancements documented and the downloadable package(s) - fehQlibs-17 are required prior of installation.
>> Greylisting for qmail-smtpd and TLSA/DANE lookup and automatic X.509 certificate validation for qmail-remote is now included.
>> DKIM is still on my todo list, but scheduled for the forthcoming release.
> TLSA/DANE lookup is a welcome feature. Another feature caught my attention.
> - Distributed queueing: n:1, 1:n n:m with qualified authentication and
> authorization (enhanced 'QMQ').
> What exactly is distributed queuing and qmail multiple queues?
When I was in charge for a Germany's federal state central email service (as consultant and developer; not admin), we faced the following situation:
a) A central email hub (based on qmail + spamcontrol).
b) Inbound and outbound mail service including (of course spam and virus scanning).
c) Maybe it was 4 core CPU (Pentium) with 32 bit CentOS (and gcc 4.7.2 driving my crazy; see remarks on my web site).
d) Recipient extension was working while using my qmail-smtpam + ldapam.pl script against the ministries (mostly Exchange) servers.
Back now 14 year or so, spam storms were daily business, the MTA had to deal > 100 000 mails/day (could be 500 000).
Inband bandwidth was plenty, but outband was restricted; many bounces as well (sitting in the queue and can't be delivered).
Thus, my idea was to decouple the entire thing, since the bottleneck was pre-processing and a huge number of messages in the queue (even with bigtodo; ext-todo was not implemented yet).
This gave rise to the following:
a) Developing the idea of a 'bounce queue' and let qmail recognize bounces (part of standard s/qmail now and since Spamcontrol 2.4).
b) Setting up several 'mini-qmail' systems (on the same host) taking individually care about delivery to the ministries (with a different rule set).
c) Transmissions between the different qmail MTA instances is given by the QMQP.
d) Rather using QMTP instead of QMQP, TLS encryption and authentication is possible (you can see it in the header of this email; mailing lists may however filter it).
I've called that 'QMQ'. Since these days, Spamcontrol and later s/qmail includes a script to deploy additional instances easy and on the fly.
Given today's approach, it is like a provisioning customized Docker images and starting those; though without any 'jail-ing' and VMs.
This actually worked extraordinary well: Mailstorms could be managed while parking mails on (in-active) instances and keeping the standard delivery channels free, while sweeping away the unwanted malls.
In short: QMQ is not a 'technique' but rather an administrative tool.
Well, there exists a patch for Qmail to provide additional 'delivery channels'. Right now Qmail and s/qmail has two: remote and local (not considering bounces). In the forthcoming releases of s/qmail, I will use this concept in a smarter way to cope better with today's privacy concerns.
Yeah, I know, i need to provide a full description of QMQ; the documentation web site is still empty. Probably, I will use this explanation for a first start. https://www.fehcom.de/sqmail/sqmaildoc.html
Anybody is free to use these ideas even for let's say Notqmail. However, trying to port DANE/TLSA to standard qmail would be a challenge. It took me some time to adjust DJB's DNS routines to be working with s/qmail and to benefit from the solution.
My next project is to finish djbdnscurve6-37 and then go for CurveDNS support in tinydns. tinydns right now provides already support for TLSA records.
> Regards Manvendra - http://www.indimail.org
> GPG Pub Key
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de
| PGP Key-Id 7E4034BE