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<g...@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@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
