[OpenIndiana-discuss] OT postfix v.s Qmail

[låzaro]

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