Mailing List Archive

* Paul Freeman (Core Internet) <paul@coreinternet.co.uk> [2014-12-18 15:52]:
> Agreed, we have an internal fork which we have been using since ~2003.
> several people have hinted about putting up on GitHub, we thought about
> GPLv2 but unsure how that would work given the "public domain" status of the
> original code base now. comments?

Legally entirely possible, but a bit against the spirit. I'd recommend
public domain or an open license like 2-clause BSD.

--
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/PVS, Application Hosting

* Erwin Hoffmann <feh@fehcom.de> [2014-12-17 16:17]:
> Am 17.12.2014 um 15:18 schrieb Michael Brunnbauer <brunni@netestate.de>:
> > -I had to install ucspi-ssl, which uses esoteric packaging, building and
> > installation processes requiring additional effort.
> ucspi-ssl uses the slashpackage format.

As Michael said: esoteric.

Forget about it. Packaging is done by the respective OS package crews.
Software authors should make THEIR lives easier (no, that does NOT mean
autohell), not the statistically irrelevant few that start from source.
slashpackage is in the way, not helping. Like it or not, technical
merits or not, that is raising the barrier, not lowering it.

--
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/PVS, Application Hosting

Hi Henning,

Am 19.12.2014 um 14:18 schrieb Henning Brauer <hb-qmail@ml.bsws.de>:
>> I would have wished, if Russ (and perhaps together with Charles and
>> Henning) would have taken the opportunity to formulate the ‚best of
>> breed‘; unlike the situation today, where we have scattered,
>> incompatible patches.
>
> err...
> http://www.qmail.org/netqmail/
> More or less surprisingly, the 3 names you mentioned are in the README.
>

Does it compile on current systems ?

>> Actually, I am a victim of this: The qmail/spamcontrol FreeBSD port
>> includes the External-Todo patch (in a version/state I can’t control)
>> of Rene Oppermann glued together. It simply does not work.
>
> Andre, not Rene.

Yes, I was mistaken.

>
>> Anyway. I will carry on with my s/qmail project. IPv6 + TLS for QMTP
>> comes next. I will keep compatibility with vanilla qmail, thus ‚the
>> tiny patches‘ still can be applied.
>
> Two things that really need to happen for those continuing to run
> qmail:
> -djb's DNS code has to be replaced. With the ever growing DNS answers,
> its shortcomings impose real operational damage.
> -a proper TLS implementation, with PFS. Afaik none of the SSL/TLS
> patches have it right (no surprise given the horrible OpenSSL API, and
> given that the other TLS libs are even worse)

djb’s DNS: Yes I agree, in particular regarding EDNS0. But this is a larger project, I already committed to do.

TLS: The OpenSSL API is horrible; I agree. Regarding TLS implementations for qmail, there is just Ferderic Vermeulen’s (which went into Shupp’s Qmail Toaster + some jumbo patches and Andre Oppermann’s extension) and the one I use based on ucspi-ssl + Scott Giffords approach and my contribution for qmail-remote.

Some (german) explanations can be found here:

https://www.heinlein-support.de/mk/2014/vortrag/tls-verschluesselung-bei-qmailspamcontrol


And you are missing:

IPv6: I’ve updated Felix von Leitner’s approach to support CIDR/netprefix notations (among others).


It would be really helpful to stick our wisdom together and provide a solid qmail-based mailing solution for the community.


Best regards.
—eh.


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

* Erwin Hoffmann <feh@fehcom.de> [2014-12-22 20:25]:
> Am 19.12.2014 um 14:18 schrieb Henning Brauer <hb-qmail@ml.bsws.de>:
> >> I would have wished, if Russ (and perhaps together with Charles and
> >> Henning) would have taken the opportunity to formulate the ‚best of
> >> breed‘; unlike the situation today, where we have scattered,
> >> incompatible patches.
> > err...
> > http://www.qmail.org/netqmail/
> > More or less surprisingly, the 3 names you mentioned are in the README.
> Does it compile on current systems ?

sure.

I'm not at all concerned about the linux errno fuckup, so I dunno
about that, but I think that has been worked around.

> >> Anyway. I will carry on with my s/qmail project. IPv6 + TLS for QMTP
> >> comes next. I will keep compatibility with vanilla qmail, thus ‚the
> >> tiny patches‘ still can be applied.
> >
> > Two things that really need to happen for those continuing to run
> > qmail:
> > -djb's DNS code has to be replaced. With the ever growing DNS answers,
> > its shortcomings impose real operational damage.
> > -a proper TLS implementation, with PFS. Afaik none of the SSL/TLS
> > patches have it right (no surprise given the horrible OpenSSL API, and
> > given that the other TLS libs are even worse)
> djb’s DNS: Yes I agree, in particular regarding EDNS0. But this is
> a larger project, I already committed to do.

hmm, should be in the "half a day including testing, max" ballpark figure.

The TLS dilemma... oh how much i wish I could just throw the existing
TLS code away and code against libtls. It's just that the API isn't
stable yet and certainly not widespread. I think we didn't even
include it in the portable LibreSSL versions yet.

> And you are missing:
> IPv6: I’ve updated Felix von Leitner’s approach to support
> CIDR/netprefix notations (among others).

no, not missing. zero relevance.

that said, i wouldn't object to IPvShit support, I just won't waste a
single second on it.

> It would be really helpful to stick our wisdom together and provide a
> solid qmail-based mailing solution for the community.

as you might have noticed I'm very sceptic about that.

--
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/PVS, Application Hosting

>> It would be really helpful to stick our wisdom together and provide a
>> solid qmail-based mailing solution for the community.
>
> as you might have noticed I'm very sceptic about that.

I've been considering writing my own MTA in the qmail-style of operations
for several years, and recently have been doing some more focused research
on what all the pieces that I'd need to consider are (at least from an
RFC/spec standpoint, as well as a few language options). My problem with
the existing qmail code is that DJB went out of his way to a) avoid using
system libraries (substdio anyone?) and b) write code that is difficult to
understand at a glance (e.g., lots of single-letter variables). Add to
that the fact that different peoples' patches are all in different styles,
plus the need to keep using DJBs idiosyncrasies and I think what qmail
needs to move forward is a complete rewrite. Whether or not I'm going to
do it is another question entirely :)

One of the things that I am seriously considering is having a plugin
architecture (as someone earlier had asked about) to allow additional
functionality to be added without having to patch and recompile the whole
system, possibly without even having to touch the existing code. Some of
the ESMTP extensions lend themselves to this easily, some not so easily,
and a couple of them not at all, but the latter are probably worth
incorporating into the base anyway (like Enhanced Status Codes). I'd be
happy to share my findings either with the list or individuals if there's
interest, and if I do start coding I'd also be happy to collaborate with
others to make things happen, but I'll cross that bridge if I get there.

I've used qmail for almost 20 years, and patched/maintained my working
codebase for 10+, but like others have said it's getting long in the
tooth. The fact that it's public domain hasn't done it any favors - DJB
didn't so much "release" qmail as he abandoned it, and while those of us
who use and like qmail aren't bothered by that, most mainstream
distributors aren't going to want to touch something that has no developer
support and no apparent future...

Josh

Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
josh@honorablemenschen.com

Joshua Megerman <josh@honorablemenschen.com> wrote:
> My problem with the existing qmail code is that DJB went out of his way to
> a) avoid using system libraries (substdio anyone?) and b) write code that is
> difficult to understand at a glance (e.g., lots of single-letter variables).

It is perhaps unfair to judge djb's qmail code by modern standards; the code
is a product of its time. Lack of comments/documentation is a timeless
problem (and one certainly not limited to djb), but much of the unreadability
of the code comes from djb's relentless focus on first maximizing security,
and then secondly maximizing performance. Hand-unrolling loops, odd semantics
that are hard to read but easier for compilers of the time to optimize, etc --
they all take their toll. Avoiding system libraries was not (just) his
objecting to them on taste grounds; system libraries of the time were
historically garbage when it came to security, so he avoided them out of
necessity.

Times have changed. qmail, of course, has not.

> I think what qmail needs to move forward is a complete rewrite. Whether or
> not I'm going to do it is another question entirely :)

I've been thinking something similar for some years, and of course whether I
ever get to work on it is an open question, but a few notes:

Much of qmail's security comes from its modularity and closely-specified
interfaces between those modules. Part of the difficulty in extending some of
qmail's functionality comes from those interfaces being specified for minimal
resource use, etc. You could redefine these interfaces to use an extensible
data format of some sort and make it easier to add new functionality, without
necessarily sacrificing security.

Hardware has advanced by so many orders of magnitude since qmail was first
conceived that CPU and memory usage is normally not much of a limiting factor
for an MTA these days. You could rewrite some or all of the modules in qmail
in an easier-to-extend higher-level language (or even just more readable
modern C) without breaking anything, while making things more maintainable.

If the interfaces are specified, then there's no reason not to have multiple
conforming implementations of any given module (smtpd, smtpc, queue manager,
message injection, etc) that suit different purposes. Different people could
write different modules to agreed-upon interfaces.

I think the most difficult part of creating a new qmail-philosophy-inspired
MTA would be avoiding second-system syndrome.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------

On Wed, Dec 24, 2014 at 11:32 AM, Charles Cazabon <
search-web-for-address@pyropus.ca> wrote:

> Joshua Megerman <josh@honorablemenschen.com> wrote:
> > My problem with the existing qmail code is that DJB went out of his way
> to
> > a) avoid using system libraries (substdio anyone?) and b) write code
> that is
> > difficult to understand at a glance (e.g., lots of single-letter
> variables).
>
> It is perhaps unfair to judge djb's qmail code by modern standards; the
> code
> is a product of its time. Lack of comments/documentation is a timeless
> problem (and one certainly not limited to djb), but much of the
> unreadability
> of the code comes from djb's relentless focus on first maximizing security,
> and then secondly maximizing performance. Hand-unrolling loops, odd
> semantics
> that are hard to read but easier for compilers of the time to optimize,
> etc --
> they all take their toll. Avoiding system libraries was not (just) his
> objecting to them on taste grounds; system libraries of the time were
> historically garbage when it came to security, so he avoided them out of
> necessity.
>

First, lack of comments isn't a meaningful observation or complaint,
because it is so dependent on the background of the reader.

I've seen comments like:

q++; /* Advance q by 1 */

and these are not helpful for most readers.

Once there is a high-level description of the product and once any
counterintuitive or subtle mechanisms are described ... the desirability of
additional comments is subjective.

Second, DJB's disdain for libraries is still an appropriate design
consideration. Even if a library meets security considerations now, what
prevents it from changing during the life of the product? And how can you
verify the libraries for all development tool chains on which the product
might be built?

Third, hand optimizations (as you pointed out) are possibly outdated.
Compilers are better, and even if they weren't, hardware is faster. The
code legibility problems may be more expensive than the performance hit.
My experience these days is that just about any non-algorithmic performance
tuning is pointless, unless it is in code where the CPU spends a LOT of its
time (timer ISR's, large integer arithmetic, certain IPC or
context-switching mechanisms, etc.).

<SNIP>


> Much of qmail's security comes from its modularity and closely-specified
> interfaces between those modules. Part of the difficulty in extending
> some of
> qmail's functionality comes from those interfaces being specified for
> minimal
> resource use, etc. You could redefine these interfaces to use an
> extensible
> data format of some sort and make it easier to add new functionality,
> without
> necessarily sacrificing security.
>
> Hardware has advanced by so many orders of magnitude since qmail was first
> conceived that CPU and memory usage is normally not much of a limiting
> factor
> for an MTA these days. You could rewrite some or all of the modules in
> qmail
> in an easier-to-extend higher-level language (or even just more readable
> modern C) without breaking anything, while making things more maintainable.
>
> If the interfaces are specified, then there's no reason not to have
> multiple
> conforming implementations of any given module (smtpd, smtpc, queue
> manager,
> message injection, etc) that suit different purposes. Different people
> could
> write different modules to agreed-upon interfaces.
>

Fourth, I believe you correctly identified the tradeoff there. Machine
resources and a design for easy extensibility were at odds. With the
constraints on machine resources effectively removed, designs for easy
extensibility are now more attainable.

Thus said Charles Cazabon on Wed, 24 Dec 2014 10:32:40 -0600:

> Times have changed. qmail, of course, has not.

And qmail still ``just works,'' and it's security still allows me to
sleep at night. It may not have the momentum it once did, but I still
prefer it to anything I've seen and haven't found a reason to change to
something else.

OpenBSD's OpenSMTPD looks like a sensible approach for an initial MTA
with sane defaults, but where I need more than root email I just install
qmail.

Modern doesn't always mean better, as evidence, I submit systemd. :-)

Andy
--
TAI64 timestamp: 40000000549af97b

Thus said "David T. Ashley" on Wed, 24 Dec 2014 12:12:51 -0500:

> Once there is a high-level description of the product and once
> any counterintuitive or subtle mechanisms are described ... the
> desirability of additional comments is subjective.

The desirability of any comment in the code may be subjective:

http://www.anticommentist.org/about.html

Andy
--
TAI64 timestamp: 40000000549afab5

Michael,


On 2014-12-17 05:31, Michael Peppard wrote:
> RPMs have to be maintained. This can be a major pain especially with
> distributions and test beds like fedora that try every new thing known
> to the linux community with few compatibility checks.
>
> In regards to the script mentioned I add the following on machines
> with systemctl
>
> To have qmail/netqmail server run under systemd, one needs to create a
> service configuration file
>
> #vi /lib/systemd/system/qmail.service
> [Unit]
> Description=qmail/netqmail service
> Requires=network.target
> After=local-fs.target network.target
>
> [Service]
> Restart=always
> PIDFile=/var/run/qmail.pid
> ExecStart=/usr/local/bin/svscan /service
> ExecStop=/var/qmail/bin/svc -dx /service/* /service/*/log
> Type=simple
> NonBlocking=yes
>
> [Install]
> WantedBy=multi-user.target
>
> NOTE: You can use your own variation in ExecStart to start svscan
> (using it with readproctitle, etc)
>
> # systemctl enable qmail.service
> The above command will create a link in
> /etc/systemd/system/multi-user.target.wants
>
> (symbolic link created)
> lrwxrwxrwx 1 root root 36 Jul 20 18:18 qmail.service ->
> /lib/systemd/system/qmail.service
>
> Then create/edit /etc/init/svscanboot.conf
> ### start of /etc/init/svscanboot.conf ########
> start on runlevel 2
> start on runlevel 3
> start on runlevel 4
> start on runlevel 5
> stop on runlevel 0
> stop on runlevel 1
> stop on runlevel 6
> respawn
> exec /command/svscanboot
> ### end of /etc/init/svscanboot.conf ########
>
> To start qmail/netqmail do
> # systemctl start qmail.service
> To stop qmail/netqmail do
> # systemctl stop qmail.service
>
> svc -u/-d and qmailctl still work fine


I have been creating:

/lib/systemd/system/com.pricom.com.au.daemontools.svscan.service

ie:

[Unit]
Description=Daemontools svscan
After=syslog.target

[Service]
ExecStart=/usr/local/bin/svscan /service 2>&1 |
/usr/local/bin/readproctitle /service errors:
.................................................. ....
Restart=always

[Install]
WantedBy=multi-user.target
#WantedBy=graphical.target # This is redundant as the graphical.target
is an implicit superset of multi-user.target

and enabling and starting it . .

Regards,

Phil.

--
Philip Rhoades

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au

On 17 December 2014 at 23:44, Michael Brunnbauer <brunni@netestate.de>
wrote:

>
>
> No problem. I am more concerned that Spamcontrol does not come with queue
> management tools, e.G. a tool to convert to bigtodo and a queue-fix patched
> for bigtodo.


What filesystem are you using that you need big-todo? ext-todo I can
understand but there should no longer be a need for big-todo. Unless you
have insane injection rates...do you get more than a few thousand emails
per second?

Hello Christopher,

On Tue, Jan 06, 2015 at 08:33:19AM +0800, Christopher Chan wrote:
> > No problem. I am more concerned that Spamcontrol does not come with queue
> > management tools, e.G. a tool to convert to bigtodo and a queue-fix patched
> > for bigtodo.
> What filesystem are you using that you need big-todo? ext-todo I can
> understand but there should no longer be a need for big-todo. Unless you
> have insane injection rates...do you get more than a few thousand emails
> per second?

I don't need big-todo. It comes with Spamcontrol and cannot be disabled, IMO.

Regards,

Michael Brunnbauer

--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

Hi Christopher,

thank you for clearing up this item ...

Am 06.01.2015 um 01:33 schrieb Christopher Chan <freetown@gmail.com>:
>
> What filesystem are you using that you need big-todo? ext-todo I can understand but there should no longer be a need for big-todo.


> Unless you have insane injection rates...do you get more than a few thousand emails per second?


That is exactly the reason for big-todo:

In case you run in a spam-attack (or a joe-job with faked return addresses) several thousand email can easily hanging around in queue/todo. This is pain for ‚stating‘ the files (on a spinning drive disk) in one dir and process those further. Rather having a big-todo dir structure file processing still runs smoothly.

Pros’n’cons of big-todo:

- no cost for qmail
- no cost for processing
- (almost) no cost for the filesystem (except for about 23 subdirs more …)

A queue repair routine should take care for this, of course. But when you do need it? Exactly: When is problem did occur in the first place and people trying to clean up the queue. Better to avoid this situation in the first place. For this very reason qmail/spamcontrol allows to set up multiple qmail instances (ie. a bounce and a trash-mail instance) with several independent queues and own schedules.

What I can do in my forthcoming releases:

- Compatibility of big-todo an default todo file handling.
- Mods to qmail-repair to adjust for big-todo.

In my qmail-mrtg add-on, big-todo is already integrated.

Best regards.
—eh.

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

Erwin,

> That is exactly the reason for big-todo:
>
> In case you run in a spam-attack (or a joe-job with faked return
> addresses) several thousand email can easily hanging around in
> queue/todo. This is pain for ‚stating‘ the files (on a spinning drive
> disk) in one dir and process those further. Rather having a big-todo dir
> structure file processing still runs smoothly.

This is part of why I'm curious about your decision to not include
ext-todo. The external todo processing allows qmail to keep up with
higher injection rates without sacrificing the ability to still send mail.
I'm not disagreeing with using big-todo (I've used it by default for a
decade), just suggesting adding ext-todo as well.

Josh

Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
josh@honorablemenschen.com

Hi Johsua,



Am 09.01.2015 um 16:55 schrieb Joshua Megerman <josh@honorablemenschen.com>:

> Erwin,
>
>> That is exactly the reason for big-todo:
>>
>> In case you run in a spam-attack (or a joe-job with faked return
>> addresses) several thousand email can easily hanging around in
>> queue/todo. This is pain for ‚stating‘ the files (on a spinning drive
>> disk) in one dir and process those further. Rather having a big-todo dir
>> structure file processing still runs smoothly.
>
> This is part of why I'm curious about your decision to not include
> ext-todo. The external todo processing allows qmail to keep up with
> higher injection rates without sacrificing the ability to still send mail.
> I'm not disagreeing with using big-todo (I've used it by default for a
> decade), just suggesting adding ext-todo as well.

The very reason is: It never worked for me.

The FreeBSD qmail/spamcontrol includes ext-todo. It is broken as well.

René Oppermann’s ext-do decouples queue processing from DJB’s self-triggering mechanism in order to avoid the ‚Silly qmail syndrome‘. With the mechanisms Spamcontrol provides (Recipient checking, virus-scanning) I never went into the situation even at large qmail sites where this was a potential problem.

However, a problem was to decouple bounce-message sending and trashing none-deliverable mails in the first place. Therefore I’m preferring my multiple queue mechanism (MQM).
If you do a Fault Tree Analysis (FTA) one should eliminate the reasons and not to invent mechanism to deal with the symptoms in the first place.

Apart from this, I believe qmail’s queue should be reorganized to support GUID instead of inodes and should support a qmail-rspawn pipelining (your point h.). I have already an idea how to realize this. However, I’m dealing still with integration of all the required add-ons. Unlike Henning, I can’t do this in just a few hours.

Additionally, your suggestions for a new MTA sound reasonable. My intention is too, to support a qmail compatible layout and APIs while using DJB’s coding style though supporting ISO-C and Clang.

Further; I’m not interested to follow all gimmicks of current ESMTP understanding but rather heading a solution more close to DJB’s IM2000 concept.

As soon, as I have a working alpha version, I will care about a Github cradle and additional support chains like mailing lists and a ticket system. Progress will be reported on my sqmail site.

Best regards.
—eh.

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

On 2015-01-09 20:10, Erwin Hoffmann wrote:

> Apart from this, I believe qmail’s queue should be reorganized to
> support GUID instead of inodes

yep we have found this to be one of most useful changes we ever made,
both in terms of de-coupling from inodes and the ease of globally unique
id's in logs and other places, I was further considering using
guid-per-delivery to aid further analysis too :)

Hi Paul,


Am 09.01.2015 um 21:36 schrieb Paul Freeman (Core Internet) <paul@coreinternet.co.uk>:

> On 2015-01-09 20:10, Erwin Hoffmann wrote:
>
>> Apart from this, I believe qmail’s queue should be reorganized to
>> support GUID instead of inodes
>
> yep we have found this to be one of most useful changes we ever made, both in terms of de-coupling from inodes and the ease of globally unique id's in logs and other places, I was further considering using guid-per-delivery to aid further analysis too :)

Actually, you triggered my ‚aha‘ ! The GUID I’m thinking of should be something like: Feeding-Node-ID_Node-ID_Instance-ID_Remote-Domain-ID_Random-ID.

By means of this construction, it should be possible to realize a ‚distributed queue‘ and also solve the problem for qmail-rspawn to support pipelining.

Thanks!

Best regards.
—eh.


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

> On 2015-01-09 20:10, Erwin Hoffmann wrote:
>
>> Apart from this, I believe qmail’s queue should be reorganized to
>> support GUID instead of inodes
>
> yep we have found this to be one of most useful changes we ever made,
> both in terms of de-coupling from inodes and the ease of globally unique
> id's in logs and other places, I was further considering using
> guid-per-delivery to aid further analysis too :)

This sounds like something to add to my long-term design goals as well.

Thanks for the suggestion!

Josh

Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
josh@honorablemenschen.com

On 2014-12-18 17:33, Erwin Hoffmann wrote:
> What I identified to be necessary is:
>
> a) AMD64 and Clang support.

agreed :)

> b) IPv6 is a must.

in qmail-lmtp we have used getaddrinfo() to be IPv6 friendly/agnostic,
additionally we determine the lmtp end point using dns/srv lookup of the
form _lmtp._tcp.<deliverydomain.dom>

> However, I’m not a fan of stateful solutions in case they can be
> omitted: Greetdelay vs. Greylisting, use of databases + sql queries.

to avoid bloating the qmail-smtpd footprint we currently hand off to
another long running daemon process the user lookup + user defined
acl/blacklist/whitelist sql queries

> f) qmail-lmtp

its largely a hack of the original qmail-remote code, could probably be
merged back into qmail-remote.c with some kind of runtime switch + the
changes to the queue of course :)

> What I find least important is:
>
> - A qmail package either in .rpm or .deb format.

I'm largely a Gentoo Linux user, although I have colleagues that favour
.deb ditros :)

On Wed, Dec 17, 2014 at 06:44:49PM +0000, ed wrote:
> [...]
> Agreed. I'm currently using JMS's combined patch set, with some of my
> own modifications.
> [...]

I've attached said modifications. Would anyone care to look and comment?

Noticed some spammers were repeating the Delivered-To headers to cause
qmail-local to backscatter.

Noticed that tls method is not optional, so added the option.

This patch is against jms's 7.08 combined set.

Comments/criticism welcome.

--
Best regards,
Ed http://www.s5h.net/