Re: [OpenIndiana-discuss] OT postfix v.s Qmail
On 25/04/12 12:43 AM, Gary Gendel wrote: Dan, I've been using qmail since the end of the 80's I take it you are another guy that knows qmail like the back of his hand and messed around with splitting the queue across multiple disks and what the optimum prime number to use and can create the qmail groups and user accounts without looking. Yes, greylisting is a powerful tool. I get that with spamdyke for qmail. Spamdyke and mailfront were the two biggest reasons that I stayed with qmail so long. I saw two greylisting packages for postfix when I was doing my searching. I'm convinced that I want to go to postfix, but it looks like it will be a painful transition. Transition pain might also be in dot-qmail filter recipes and their generator(s) and the local delivery structure. Only qmail-local supports dot-qmail so if you make heavy use of that... ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OT postfix v.s Qmail
On 4/24/2012 12:43 PM, Gary Gendel wrote: Dan, I've been using qmail since the end of the 80's Yes, greylisting is a powerful tool. I get that with spamdyke for qmail. Spamdyke and mailfront were the two biggest reasons that I stayed with qmail so long. I saw two greylisting packages for postfix when I was doing my searching. I'm convinced that I want to go to postfix, but it looks like it will be a painful transition. I've got two chains. One from port 25 that uses spamdyke, and one from port 587 that uses mailfront (to give me SSL/TLS and authorization). Since they both converge at the qmail-queue process that handles the delivery portion, it's a nice clean path to delivery. I may try to use postfix to replace one first so I can really thresh out the issues. Gary, have you visited the postfix site? There are howtos for a bunch of these issues. It really shouldn't need to be painful or tricky. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OT postfix v.s Qmail
Dan, I've been using qmail since the end of the 80's Yes, greylisting is a powerful tool. I get that with spamdyke for qmail. Spamdyke and mailfront were the two biggest reasons that I stayed with qmail so long. I saw two greylisting packages for postfix when I was doing my searching. I'm convinced that I want to go to postfix, but it looks like it will be a painful transition. I've got two chains. One from port 25 that uses spamdyke, and one from port 587 that uses mailfront (to give me SSL/TLS and authorization). Since they both converge at the qmail-queue process that handles the delivery portion, it's a nice clean path to delivery. I may try to use postfix to replace one first so I can really thresh out the issues. Gary On 4/24/12 12:05 PM, Dan Swartzendruber wrote: I am a long-time postfix user. The single biggest winner is greylisting. As I recall, there are a couple of greylist packages you can plug into postfix and it just works. ___ 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
Re: [OpenIndiana-discuss] OT postfix v.s Qmail
I am a long-time postfix user. The single biggest winner is greylisting. As I recall, there are a couple of greylist packages you can plug into postfix and it just works. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OT postfix v.s Qmail
answer in lines... Thread name: "Re: [OpenIndiana-discuss] OT postfix v.s Qmail" Mail number: 22 Date: Tue, Apr 24, 2012 In reply to: Gary Gendel > > 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. I"m not clear just now but I think, when Postfix make querry to BL DNS him don't use database, just make a lookup, repeat "I'm not pretty shure about that". Anyway... I think who use database is more "better" than system variables, their data don't go flying when the come the blackuots. Also: "more services, more separate, more secure". Of corse, in the light-weight balancing load, Qmail have the novell price (use it onle when needed) but I don't change lightness for security. Also repeat: I love Qmail, but is a very good idea with very old implementation(s). > > 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. For fight with spam just reject_rbl is enough. Usage of spam-asassim is very wheigth, heavy (for my old comuter server) the load growht much, much better consult DNS-BL direct, also more updated. Policyd just done that but also use cache and save bandwith (very important here) Policyd also make tarpiting, is an all in one. Very good, but.. if their fail, all the mail will bty rejected, that never happen to me but is a posibility... > > 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 ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OT postfix v.s Qmail
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 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 k
[OpenIndiana-discuss] OT postfix v.s Qmail
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 > > 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
