Heh. You've never used Qpsmtpd or Haraka, I can tell. Haraka and qpsmtpd are basically skeletons where you can insert plugins to do/redefine anything you want pre/during/post any step of SMTP. Want to extend/redefine SMTP? Sure. Parallelize queries to any kind of database? Fine. Regexp subjects and programmatically blackhole, nuke, reject or temp? Fine. Skip steps when you've already decided you don't want it? Fine.
It was so swiss army knife it doesn't even know how to do AUTH, MXing and barely outbound SMTP. The latest version may not even be able to do TLS anymore either. You have to write those bits yourself. Think of qpsmtpd and harakka as postfix's smtp-sink with plugin capability. [I've played a lot with smtp-sink too - makes a great dumb trap if you hack it a bit to save the right bits in a spool directory.] They really shine in making spamtraps that analyse what they receive, communicate with other packages, other systems, generate dataflows of anything you want, trivially implement new filtering methods, all in real time. I once asked one of the postfix gurus - not Wietse, but one of the few secondary ones if I could do something really simple that I'd been doing for years in qpsmtpd. How simple? I wanted to expose the RAW SMTP transactions to a milter or some other plugin. After asking *why* I wanted it, he said "leave me an hour to think and I'll let you know". Came back in an hour, and what did he say? "We'd have to rewrite the core, sorry". Oops. The ONLY "ordinary" MTA I know of that can do this simple task is EXIM. Qpsmtpd lost a lot when its major contributor left to invent Harraka. A lot of code when stale and functionality/performance was lost. The version core I'm using (at one time on 60+ MTAS) is probably over a decade old. The big problem with qpsmtpd is that it was written so "open", and had so much configurability, that there never was a distributed unified set of plugins that could play nicely and do anything much more than stuffing what it didn't rejee into qmail queues. I always had to write my own from scratch. Making it harder is that the documentation was scattered, disconnected, incomplete, and nobody kept it up to date. Nobody was herding the cats. As I understand it, the Haraka community is much the same. Which means *steep* learning curves that can't rely on documentation. I really don't know anybody still running Qpsmtpd other than me. Haraka still has some specialized commercial users too. Don't get me wrong, they both have strong, but small and closed communities, and harakka is more modern. But they're almost all doing extremely specialized things, and don't talk a lot. Never did. qmsmtpd and haraka basically do the same thing, one is in Perl, the other in Java. You'd be surprised how fast they are when configured properly. There's a third called "mailfront" that uses plugin C modules. I know almost nothing more about it, other than its similar in intent/architecture. I think the community surrounding it is even smaller. Still running it John? I would recommend against using *any* of these if you're trying for a high performance fairly normal "modern" MTA and don't want to spend a few years learning their guts and coding custom plugins for almost everything. None of them are full MTAs, they're most used in production environments as front ends to real MTAs. I used them standalone as traps, and production server front ends relaying "clean" inbound email to something else like postfix or sendmail. On 2021-05-01 2:13 a.m., Thomas Walter via mailop wrote: > Hello MRob, > > On 01.05.21 05:18, MRob via mailop wrote: >> I used Postfix along time but my experience is that it is incredible >> difficult to implement custom logic especially across the different >> binaries/processes it uses to fulfil a mail delivery transaction. Its >> designed in the "unix philosophy" and has good performance - great but >> Postfix devs normally react hostile if asked for advanced features that >> require tracking meta-information about messages across Postfix >> processes. Its only the RFC compliant mail message state that persisting >> through the entire transaction, nothing more. Milters can be injected >> but have limitations and I get headaches from the configuration system. >> I shouldn't complain too hard tho, because I'm grateful for how solid >> and secure and bulletproof it has been. Thank you team Postfix. > While I understand your frustration, I wonder what "advanced feature" > you are looking for. In the end you can override each and every single > Postfix element or how they interact. It's that flexibility that gives > me most of my headaches. > > Regards > Thomas Walter > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
