[OpenIndiana-discuss] OT postfix v.s Qmail

Tue Apr 24 15:35:25 UTC 2012

Låzaro,

Thanks for the pointer.  Policy-light is much closer to spamdyke's 
capabilities than postfix is.  The big difference is that qmail uses 
process chaning and passes information via environment variables where 
postfix uses a database to provide the information and proxies to the 
modules.  As it hasn't reached version 1 yet, the system is still in flux.

The advantage of qmail's approach is that the work is partitioned by 
executing functionality as needed and the chain is completely segregated 
from other sessions.  Postfix requires executing auxiliary services 
which requires either a proliferation of smaller databases or one large 
database with access locks.

The advantage of postfix's approach is the single arbitrator of what is 
going on so the modules are stateless.  Qmail relies on the handoff 
continue where the previous one left off.  If they read from the socket 
(which is connected to stdin), then they must convey this information 
(using stdout) to the next in the sequence. Thus it must store this 
information if required.  This becomes an issue when dealing with a 
module like SpamAssassin.  In this case, the interface, saves the 
necessary information into a file, let's spamassassin process it, and 
then replay the file to the next item in the chain.  On the other hand, 
postfix's modules rely on postfix to collect all the information they 
need to do their job apriori.

This is been a very useful side discussion for me.  We all have our 
biases, mine is based upon familiarity but I can see the writing on the 
wall so this is just an intellectual discussion.

Gary

On 4/24/12 10:52 AM, låzaro wrote:
> due my response, the subject will by a OT
>
> Thread name: "Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?"
> Mail number: 20
> Date: Tue, Apr 24, 2012
> In reply to: Gary Gendel<gary at genashor.com>
>> With all this discussion about Postfix vs. Qmail, I started looking
>> at what it would take to replace my Qmail installation with Postfix.
>> I started looking at what it would take to replace spamdyke with
>> postfix functionality.  Most things have a direct correlation.  One
>> case so far, greylisting, requires running an independent email
>> proxy for postfix where it is incorporated in spamdyke.  I'm still
>> working through the list but many of the configuration options need
>> more detailed documentation or I'll have to work through the code to
>> see exactly what it's trying to accomplish.  For example, it took me
>> quite awhile to dig out how postfix handles CIDR notation.
>>
>> The pipeline architecture of qmail has been instrumental at making
>> third-party additions incredibly simple. You can easily plug in
>> special debugging modules, and even tee off things so you can test
>> new modules in parallel with real operations.  Before spamdyke was
>> available, I had developed a number of homebrew modules for spam
>> analysis and control.  That said, qmail isn't 100% sendmail
>> compatible, so occasionally I ran into issues with unhandled
>> sendmail options (until patched).  I don't know whether postfix
>> suffers from the same issue yet.
> Fight with the spam is easy and part of the system to
>
> I paste my full defense here:
>
> smtpd_recipient_restrictions =
>      reject_unlisted_sender,
>      reject_unlisted_recipient,
>      reject_non_fqdn_sender,
>      reject_non_fqdn_recipient,
>      reject_unknown_recipient_domain,
>      reject_unverified_recipient,
>      reject_invalid_hostname,
>      reject_unauth_pipelining,
>      reject_rbl_client bl.spamcop.net,
>      reject_rbl_client sbl.spamhaus.org,
>      #check_policy_service inet:127.0.0.1:12525,
>      reject_unauth_destination
>
> the line reject_rbl_client consult directly the DNS black list
>
> Also the comented line "#check_policy_service" is a super simply Balck
> lis consultating app. At my blog (sorry: in spanish) you can see how to
> make it work. Just look at the commands, not see the explaniation, is
> not so necesary if follow the step.
>
> http://otherlinuxblog.blogspot.com/2012/01/policyd-light-y-posftix.html
>
>
> Note:
>
> The reject_rbl_client reject the conection in the moment when the
> spammer say MAIL FROM: only with reject_rbl_client you can be quite sure.
>
>
>
>> Since my Qmail based system does not inherently support IPV6 and
>> would require significant patching I'm committed to move to Postfix
>> before this becomes necessary.  However, Postfix configuration is
>> far more complex if you are someone that likes to understand the
>> purpose of each option and it's impact to other options.
> hard to understand is Exim, postfix is just "diferent" but is full
> docuemnted. If you wanna "shot yourself in the foot" just put in google
> "postfix shoot myself in the foot" The configuration is "simple" (not
> easy) but simple and logic (as Qmail)
>
> As you can see, if read carefully the reject_ lines, it form at the name
> explicity good.
>
>>   I will
>> also miss the simplicity of making a split-horizon caching DNS
>> service via dnscache/tinydns when I need to go to IPV6 which is an
>> important piece of any email system in a private networked LAN.
> well, you killme at this point. DNS is not under my control here
>
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss