Re: [gentoo-user] clamav and spamassassin
Michael, after I configured postscreen, how do I test it? I tried doing out of turn talking but it didn't seem to block me... Rgds,
Re: [gentoo-user] clamav and spamassassin
Michael, after I configured postscreen, how do I test it? I tried doing out of turn talking but it didn't seem to block me... Are you getting lines like this in your mail log: Dec 6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ... - Grant
Re: [gentoo-user] clamav and spamassassin
On 12/06/11 19:57, Grant wrote: That will disable postgrey, but isn't enough to enable postscreen. There are a couple of daemons you have to enable in master.cf (steps 2 through 6): http://www.postfix.org/POSTSCREEN_README.html#enable That README refers to lines that are commented-out in master.cf; of course, if you've upgraded from an earlier of postfix, you won't have them. Don't you let etc-update add them for you? Well, etc-update offers to overwrite the old one with the new, but that would be bad since we have a few custom services. I do try to patch the new comments into my configuration files when possible, but my master.cf is so far away from upstream's that the patch file is basically, - Everything old + Everything new These days I'm almost ready to claim that I actually understand how postfix works, so I'm not afraid to maintain main.cf and master.cf by hand anymore. Working now, thanks a lot. I should only need the tlsproxy line if my users connect to port 25 to send mail, correct? You should enable it anyway: many remote MTAs will use encryption if you let them.
Re: [gentoo-user] clamav and spamassassin
On 12/06/11 20:02, Grant wrote: Aye aye. Should I make the change like this: #smtps inet n - n - - smtpd # -o smtpd_tls_wrappermode=yes submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING And then switch my clients from port 465 to 587? - Grant Yup, but be sure to uncomment the rest of the -o lines. Depending on which mail clients you use, you may have to fiddle with the secure connection setting. Some of them allow you to choose between SSL and TLS (ignoring that the distinction is ambiguous). You'll want to set them to (START)TLS if you have the option.
Re: [gentoo-user] clamav and spamassassin
On Dec 7, 2011 11:05 PM, Grant emailgr...@gmail.com wrote: Michael, after I configured postscreen, how do I test it? I tried doing out of turn talking but it didn't seem to block me... Are you getting lines like this in your mail log: Dec 6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ... No... but then I realize I've been testing from a host that's part of $my_networks . It indeed works now :-) Rgds,
Re: [gentoo-user] clamav and spamassassin
That will disable postgrey, but isn't enough to enable postscreen. There are a couple of daemons you have to enable in master.cf (steps 2 through 6): http://www.postfix.org/POSTSCREEN_README.html#enable That README refers to lines that are commented-out in master.cf; of course, if you've upgraded from an earlier of postfix, you won't have them. Don't you let etc-update add them for you? Well, etc-update offers to overwrite the old one with the new, but that would be bad since we have a few custom services. I do try to patch the new comments into my configuration files when possible, but my master.cf is so far away from upstream's that the patch file is basically, - Everything old + Everything new Yeah, I try to keep mine as close to default as possible (comments and all) so etc-update does an easy interactive merge. - Grant These days I'm almost ready to claim that I actually understand how postfix works, so I'm not afraid to maintain main.cf and master.cf by hand anymore. Working now, thanks a lot. I should only need the tlsproxy line if my users connect to port 25 to send mail, correct? You should enable it anyway: many remote MTAs will use encryption if you let them.
Re: [gentoo-user] clamav and spamassassin
Aye aye. Should I make the change like this: #smtps inet n - n - - smtpd # -o smtpd_tls_wrappermode=yes submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING And then switch my clients from port 465 to 587? - Grant Yup, but be sure to uncomment the rest of the -o lines. Are you sure? I was using smtps like this: smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING but I should switch to the below? submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING - Grant
Re: [gentoo-user] clamav and spamassassin
On 12/07/11 13:16, Grant wrote: Are you sure? I was using smtps like this: smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING but I should switch to the below? Are all of your clients in mynetworks? If so, it doesn't really matter unless you want to prevent your own users from forging the envelope sender or From: address. This would enable SASL: -o smtpd_sasl_auth_enable=yes This would allow authenticated users to relay, and reject everything else: -o smtpd_client_restrictions=permit_sasl_authenticated,reject And this does nothing unless you use a filter and want to distinguish between incoming and outgoing mail: -o milter_macro_daemon_name=ORIGINATING
Re: [gentoo-user] clamav and spamassassin
On 12/07/11 13:56, Michael Orlitzky wrote: Are all of your clients in mynetworks? If so, it doesn't really matter unless you want to prevent your own users from forging the envelope sender or From: address. Whoops, correction: you can still forge the From: header with reject_authenticated_sender_login_mismatch.
Re: [gentoo-user] clamav and spamassassin
Are you sure? I was using smtps like this: smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING but I should switch to the below? Are all of your clients in mynetworks? If so, it doesn't really matter unless you want to prevent your own users from forging the envelope sender or From: address. This would enable SASL: -o smtpd_sasl_auth_enable=yes This would allow authenticated users to relay, and reject everything else: -o smtpd_client_restrictions=permit_sasl_authenticated,reject And this does nothing unless you use a filter and want to distinguish between incoming and outgoing mail: -o milter_macro_daemon_name=ORIGINATING Thanks a lot Michael. Much appreciated. - Grant
Re: [gentoo-user] clamav and spamassassin
What about trouble with the DNSBL lists? I know when I changed my IP address I had to work to get the new one removed from a few blacklists it had previously been placed on. I wasn't sending spam, but my messages would have been blocked under that config if I hadn't done the work to get the IP off the lists. - Grant We do get false positives from the blacklists on rare occasion, but they're the same ones we got before postscreen. Before postscreen, we had, smtpd_recipient_restrictions = permit_mynetworks, ... reject_rbl_client psbl.surriel.com, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client b.barracudacentral.org, permit After postscreen, we have, smtpd_recipient_restrictions = permit_mynetworks, ... permit postscreen_dnsbl_sites = psbl.surriel.com, bl.spamcop.net, zen.spamhaus.org, b.barracudacentral.org The two should be more or less equivalent considering that postscreen_dnsbl_threshold = 1. (I should mention that you have to register with barracuda before using their list.) Got it. Your explanations are positively lucid. I added this to /etc/postifx/main.cf: postscreen_greet_action = enforce postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce and I commented this and restarted postfix: #check_policy_service inet:127.0.0.1:10030 Should this effectively disable postgrey and enable postscreen? - Grant
Re: [gentoo-user] clamav and spamassassin
On 12/06/11 11:32, Grant wrote: Got it. Your explanations are positively lucid. I added this to /etc/postifx/main.cf: postscreen_greet_action = enforce postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce and I commented this and restarted postfix: #check_policy_service inet:127.0.0.1:10030 Should this effectively disable postgrey and enable postscreen? That will disable postgrey, but isn't enough to enable postscreen. There are a couple of daemons you have to enable in master.cf (steps 2 through 6): http://www.postfix.org/POSTSCREEN_README.html#enable That README refers to lines that are commented-out in master.cf; of course, if you've upgraded from an earlier of postfix, you won't have them. What I did was to untar the latest postfix release under my home directory, and find the master.cf that ships with it. Then, I copy/pasted the lines mentioned in the README over to my real master.cf. After a restart, you should see lines like this in your mail log: Dec 6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ... that let you know its' working.
Re: [gentoo-user] clamav and spamassassin
On Tue, Dec 6, 2011 at 11:11 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 12/06/11 11:32, Grant wrote: Got it. Your explanations are positively lucid. I added this to /etc/postifx/main.cf: postscreen_greet_action = enforce postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce and I commented this and restarted postfix: #check_policy_service inet:127.0.0.1:10030 Should this effectively disable postgrey and enable postscreen? That will disable postgrey, but isn't enough to enable postscreen. There are a couple of daemons you have to enable in master.cf (steps 2 through 6): http://www.postfix.org/POSTSCREEN_README.html#enable That README refers to lines that are commented-out in master.cf; of course, if you've upgraded from an earlier of postfix, you won't have them. What I did was to untar the latest postfix release under my home directory, and find the master.cf that ships with it. Then, I copy/pasted the lines mentioned in the README over to my real master.cf. After a restart, you should see lines like this in your mail log: Dec 6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ... that let you know its' working. Thanks for bringing up postscreen and the rest of your responses to Grant in this thread, I wasn't aware of it either. None of the HOWTOs I read ever mentioned it. :) I'm going to give it a try and see how it goes.
Re: [gentoo-user] clamav and spamassassin
Got it. Your explanations are positively lucid. I added this to /etc/postifx/main.cf: postscreen_greet_action = enforce postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce and I commented this and restarted postfix: #check_policy_service inet:127.0.0.1:10030 Should this effectively disable postgrey and enable postscreen? That will disable postgrey, but isn't enough to enable postscreen. There are a couple of daemons you have to enable in master.cf (steps 2 through 6): http://www.postfix.org/POSTSCREEN_README.html#enable That README refers to lines that are commented-out in master.cf; of course, if you've upgraded from an earlier of postfix, you won't have them. What I did was to untar the latest postfix release under my home directory, and find the master.cf that ships with it. Then, I copy/pasted the lines mentioned in the README over to my real master.cf. After a restart, you should see lines like this in your mail log: Dec 6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ... that let you know its' working. Do you know how smtps comes into play? Right now I've got the following uncommented in master.cf: smtp inet n - n - - smtpd smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes Should I write an smtpsd line or does tlsproxy make that unnecessary? - Grant
Re: [gentoo-user] clamav and spamassassin
On 12/06/2011 04:34 PM, Grant wrote: Do you know how smtps comes into play? Right now I've got the following uncommented in master.cf: smtp inet n - n - - smtpd smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes Should I write an smtpsd line or does tlsproxy make that unnecessary? SMTPS is deprecated. You probably don't need it at all, unless you do. Some older (Microsoft...) clients can't use anything else for encryption. These days, the proper way to secure your users' connections is with TLS on the submission port, 587. You should also have a commented-out 'submission' line in your master.cf; that's what it's for. The idea is that you can force encryption on port 587, and have your users connect there instead of port 25. Then, the only restriction you need for those connections is that the username/password be correct. The rest of the mail comes in on port 25, unencrypted, as usual, and is subjected to your anti-spam checks. If you're using either SMTPS or the submission service, you don't need to change them. Your users will continue to connect to port 465 (smtps) or 587 (submission), bypassing postscreen entirely. If you're not using the submission service, i.e. both external and user-submitted mail come in on port 25, then you'll probably want to exempt your users from the postscreen restrictions: http://www.postfix.org/postconf.5.html#postscreen_access_list but you should really be using the submission port!
Re: [gentoo-user] clamav and spamassassin
On Dec 7, 2011 2:22 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Tue, Dec 6, 2011 at 11:11 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 12/06/11 11:32, Grant wrote: Got it. Your explanations are positively lucid. I added this to /etc/postifx/main.cf: postscreen_greet_action = enforce postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce and I commented this and restarted postfix: #check_policy_service inet:127.0.0.1:10030 Should this effectively disable postgrey and enable postscreen? That will disable postgrey, but isn't enough to enable postscreen. There are a couple of daemons you have to enable in master.cf (steps 2 through 6): http://www.postfix.org/POSTSCREEN_README.html#enable That README refers to lines that are commented-out in master.cf; of course, if you've upgraded from an earlier of postfix, you won't have them. What I did was to untar the latest postfix release under my home directory, and find the master.cf that ships with it. Then, I copy/pasted the lines mentioned in the README over to my real master.cf. After a restart, you should see lines like this in your mail log: Dec 6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ... that let you know its' working. Thanks for bringing up postscreen and the rest of your responses to Grant in this thread, I wasn't aware of it either. None of the HOWTOs I read ever mentioned it. :) I'm going to give it a try and see how it goes. Indeed. They are also unclear on how to configure SASL (but that's a different story). Luckily, I'm building my mailfiltering gateway from scratch, and have been logging everything I do. When everything's finished and the mfgw works well, I'll distill my log into yet-another-wiki-article. Rgds,
Re: [gentoo-user] clamav and spamassassin
That will disable postgrey, but isn't enough to enable postscreen. There are a couple of daemons you have to enable in master.cf (steps 2 through 6): http://www.postfix.org/POSTSCREEN_README.html#enable That README refers to lines that are commented-out in master.cf; of course, if you've upgraded from an earlier of postfix, you won't have them. Don't you let etc-update add them for you? What I did was to untar the latest postfix release under my home directory, and find the master.cf that ships with it. Then, I copy/pasted the lines mentioned in the README over to my real master.cf. After a restart, you should see lines like this in your mail log: Dec 6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ... that let you know its' working. Working now, thanks a lot. I should only need the tlsproxy line if my users connect to port 25 to send mail, correct? - Grant
Re: [gentoo-user] clamav and spamassassin
SMTPS is deprecated. You probably don't need it at all, unless you do. Some older (Microsoft...) clients can't use anything else for encryption. These days, the proper way to secure your users' connections is with TLS on the submission port, 587. You should also have a commented-out 'submission' line in your master.cf; that's what it's for. The idea is that you can force encryption on port 587, and have your users connect there instead of port 25. Then, the only restriction you need for those connections is that the username/password be correct. The rest of the mail comes in on port 25, unencrypted, as usual, and is subjected to your anti-spam checks. If you're using either SMTPS or the submission service, you don't need to change them. Your users will continue to connect to port 465 (smtps) or 587 (submission), bypassing postscreen entirely. If you're not using the submission service, i.e. both external and user-submitted mail come in on port 25, then you'll probably want to exempt your users from the postscreen restrictions: http://www.postfix.org/postconf.5.html#postscreen_access_list but you should really be using the submission port! Aye aye. Should I make the change like this: #smtps inet n - n - - smtpd # -o smtpd_tls_wrappermode=yes submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING And then switch my clients from port 465 to 587? - Grant
Re: [gentoo-user] clamav and spamassassin
On Dec 7, 2011 8:01 AM, Grant emailgr...@gmail.com wrote: That will disable postgrey, but isn't enough to enable postscreen. There are a couple of daemons you have to enable in master.cf (steps 2 through 6): http://www.postfix.org/POSTSCREEN_README.html#enable That README refers to lines that are commented-out in master.cf; of course, if you've upgraded from an earlier of postfix, you won't have them. Don't you let etc-update add them for you? What I did was to untar the latest postfix release under my home directory, and find the master.cf that ships with it. Then, I copy/pasted the lines mentioned in the README over to my real master.cf. After a restart, you should see lines like this in your mail log: Dec 6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ... that let you know its' working. Working now, thanks a lot. I should only need the tlsproxy line if my users connect to port 25 to send mail, correct? I've perused the relevant documentation, and to my knowledge you need to enable tlsproxy if you want to use TLS, be it through port 25 or 587. Don't forget to test it using openssl s_client. Rgds,
Re: [gentoo-user] clamav and spamassassin
Here's the entirety of my main.cf postscreen section for reference. I've deemed these safe, but you shouldn't enable them without reading what they do! # # Postscreen settings # postscreen_greet_action = enforce postscreen_dnsbl_sites = psbl.surriel.com, bl.spamcop.net, zen.spamhaus.org, b.barracudacentral.org postscreen_dnsbl_threshold = 1 postscreen_dnsbl_action = enforce ## ## Deep protocol tests ## postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce I've looked up each of those parameters and they sound fine to me. How long have you been running them? Have you been notified of any mistakenly rejected mail? It's very important my server doesn't miss any mail, even if it means dealing with more spam. - Grant
Re: [gentoo-user] clamav and spamassassin
On Dec 6, 2011 7:19 AM, Grant emailgr...@gmail.com wrote: Here's the entirety of my main.cf postscreen section for reference. I've deemed these safe, but you shouldn't enable them without reading what they do! # # Postscreen settings # postscreen_greet_action = enforce postscreen_dnsbl_sites = psbl.surriel.com, bl.spamcop.net, zen.spamhaus.org, b.barracudacentral.org postscreen_dnsbl_threshold = 1 postscreen_dnsbl_action = enforce ## ## Deep protocol tests ## postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce I've looked up each of those parameters and they sound fine to me. How long have you been running them? Have you been notified of any mistakenly rejected mail? It's very important my server doesn't miss any mail, even if it means dealing with more spam. Similar situation with me. Because my company is in the financial sector, false negatives are much more preferred than false positives. (Although I can always weasel my way out of any problems caused by slight configuration mistakes, I prefer not having to put myself into a situation where weasel-ing is needed :-) Rgds,
Re: [gentoo-user] clamav and spamassassin
On 12/05/2011 07:45 PM, Pandu Poluan wrote: I've looked up each of those parameters and they sound fine to me. How long have you been running them? Have you been notified of any mistakenly rejected mail? It's very important my server doesn't miss any mail, even if it means dealing with more spam. Similar situation with me. Because my company is in the financial sector, false negatives are much more preferred than false positives. I have never had a false positive report that I traced back to one of the postscreen deep protocol tests. That being said, they've only been in place for ~4 months.
Re: [gentoo-user] clamav and spamassassin
On Dec 6, 2011 7:58 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 12/05/2011 07:45 PM, Pandu Poluan wrote: I've looked up each of those parameters and they sound fine to me. How long have you been running them? Have you been notified of any mistakenly rejected mail? It's very important my server doesn't miss any mail, even if it means dealing with more spam. Similar situation with me. Because my company is in the financial sector, false negatives are much more preferred than false positives. I have never had a false positive report that I traced back to one of the postscreen deep protocol tests. That being said, they've only been in place for ~4 months. Four months without a false positive? Good enough for me. Where do I sign? :-) Rgds,
Re: [gentoo-user] clamav and spamassassin
On 12/05/2011 08:01 PM, Pandu Poluan wrote: Four months without a false positive? Good enough for me. Where do I sign? :-) main.cf =)
Re: [gentoo-user] clamav and spamassassin
I've looked up each of those parameters and they sound fine to me. How long have you been running them? Have you been notified of any mistakenly rejected mail? It's very important my server doesn't miss any mail, even if it means dealing with more spam. Similar situation with me. Because my company is in the financial sector, false negatives are much more preferred than false positives. I have never had a false positive report that I traced back to one of the postscreen deep protocol tests. That being said, they've only been in place for ~4 months. What about trouble with the DNSBL lists? I know when I changed my IP address I had to work to get the new one removed from a few blacklists it had previously been placed on. I wasn't sending spam, but my messages would have been blocked under that config if I hadn't done the work to get the IP off the lists. - Grant
Re: [gentoo-user] clamav and spamassassin
On 12/05/2011 10:24 PM, Grant wrote: What about trouble with the DNSBL lists? I know when I changed my IP address I had to work to get the new one removed from a few blacklists it had previously been placed on. I wasn't sending spam, but my messages would have been blocked under that config if I hadn't done the work to get the IP off the lists. - Grant We do get false positives from the blacklists on rare occasion, but they're the same ones we got before postscreen. Before postscreen, we had, smtpd_recipient_restrictions = permit_mynetworks, ... reject_rbl_client psbl.surriel.com, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client b.barracudacentral.org, permit After postscreen, we have, smtpd_recipient_restrictions = permit_mynetworks, ... permit postscreen_dnsbl_sites = psbl.surriel.com, bl.spamcop.net, zen.spamhaus.org, b.barracudacentral.org The two should be more or less equivalent considering that postscreen_dnsbl_threshold = 1. (I should mention that you have to register with barracuda before using their list.)
Re: [gentoo-user] clamav and spamassassin
On Dec 4, 2011 10:10 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 12/03/2011 09:48 PM, Pandu Poluan wrote: Thanks! Very helpful resources. You mentioned amavisd-new. What's their relationship? I mean, if I deploy postscreen, how will it affect amavisd-new? Postscreen sits in front of smtpd, and handles all incoming connections. It hands the good connections off to the real smtpd daemon. Amavisd-new (in both before/after-queue configurations) interacts with the real smtpd, so postscreen doesn't directly affect it at all. What was I talking about? With amavisd-new, a before-queue filter is generally nicer, because you can reject spam, notifying the sender, rather than discarding it or backscattering. But, amavisd-new is a hog, and with a before-queue filter, an amavis process gets used every time ANY connection is made. Since 95% of your connections will be crap (that is a technical term), you waste tons of resources creating/killing amavisd-new processes for botnets and other scum that will be rejected quickly. On a busy server, it will kill you. Postscreen only passes the good connections to a real smtpd, so with postscreen running, new amavis processes only get used for those good connections. If postscreen can get reject 90% of the incoming connections, you'll use an order of magnitude less resources doing before-queue filtering than you would without postscreen. So, in essence, postscreen is what allows you to run the before-queue filter with comparable resources to the after-queue filter. Thanks for all the information. You really should write a wiki.g.o article about the new setup :-) Rgds,
[gentoo-user] clamav and spamassassin
I haven't set up any antivirus measures on my Gentoo systems so I think I should. Is clamav run as a scheduled filesystem scanner on each system and as an email scanner on the mail server all that's necessary? I'm currently greylisting email to prevent spam from getting through. It catches a lot, but more and more gets through. I'm not using any mailfilters now and If I set up a clamav mailfilter I think I may as well set up a spamassassin mailfilter to take the place of greylisting. Is this the best guide for clamav and spamassassin: http://www.gentoo.org/doc/en/mailfilter-guide.xml Could I run into any problems with clamav or spamassassin that might make we wish I hadn't implemented them? - Grant
Re: [gentoo-user] clamav and spamassassin
On 12/03/2011 02:52 PM, Grant wrote: I haven't set up any antivirus measures on my Gentoo systems so I think I should. Is clamav run as a scheduled filesystem scanner on each system and as an email scanner on the mail server all that's necessary? Nobody (as far as I know?) scans linux filesystems unless there's a legal requirement or the files might wind up on a Windows box. I'm currently greylisting email to prevent spam from getting through. It catches a lot, but more and more gets through. I'm not using any mailfilters now and If I set up a clamav mailfilter I think I may as well set up a spamassassin mailfilter to take the place of greylisting. Is this the best guide for clamav and spamassassin: SpamAssassin shouldn't take the place of greylisting; they reject different stuff. Keep the greylisting unless the delays bother you, but use postscreen to do it (see below). http://www.gentoo.org/doc/en/mailfilter-guide.xml Could I run into any problems with clamav or spamassassin that might make we wish I hadn't implemented them? Yeah. The first is false positives. The second, related problem is that you'll have to manage a quarantine unless you stick amavisd-new in front of the postfix queue. It's in that respect that the tutorial is outdated; otherwise, it looks good (I just skimmed it). There is great benefit to the before-queue setup: mail will never disappear. Senders either get a rejection, or the mail is delivered. With the after-queue setup, you can no longer reject or else you'll be backscattering. So, you either deliver the spam, or you quarantine it (very bad if it's a false positive). The downside is that you use more resources: one amavisd-new per connection. However, the addition of postscreen to postfix has largely ameliorated this. Since postscreen rejects most of the junk, amavis only gets started for smtpd sessions that are likely to succeed. The easiest way to migrate is through incremental improvement. We used to use a system like the one in that guide. I enabled postscreen over the course of a week, and retired postgrey, which we had been using for greylisting. Once that was working properly, I simply dropped the content_filter in favor of smtpd_proxy_filter to move amavis in front of the queue.
Re: [gentoo-user] clamav and spamassassin
I haven't set up any antivirus measures on my Gentoo systems so I think I should. Is clamav run as a scheduled filesystem scanner on each system and as an email scanner on the mail server all that's necessary? Nobody (as far as I know?) scans linux filesystems unless there's a legal requirement or the files might wind up on a Windows box. Very cool. I found out clamscan and avgfree scan the filesystem so I thought I should set it up, but if it's not necessary I won't bother. All of my mail users are on Gentoo so do I need to bother having clamav scan my incoming mail? I'm currently greylisting email to prevent spam from getting through. It catches a lot, but more and more gets through. I'm not using any mailfilters now and If I set up a clamav mailfilter I think I may as well set up a spamassassin mailfilter to take the place of greylisting. Is this the best guide for clamav and spamassassin: SpamAssassin shouldn't take the place of greylisting; they reject different stuff. Keep the greylisting unless the delays bother you, but use postscreen to do it (see below). I just did some reading on postscreen but it doesn't sound like a greylister. Should I use postscreen in addition to postgrey, or are they substitutes for each other? http://www.gentoo.org/doc/en/mailfilter-guide.xml Could I run into any problems with clamav or spamassassin that might make we wish I hadn't implemented them? Yeah. The first is false positives. The second, related problem is that you'll have to manage a quarantine unless you stick amavisd-new in front of the postfix queue. Now that sounds like a hassle. Greylisting leaves me with about 50/50 spam/legit mail and maybe incorporating postscreen I'll do even better. Deleting spam in my inbox might be easier than dealing with false positives and managing a quarantine. - Grant It's in that respect that the tutorial is outdated; otherwise, it looks good (I just skimmed it). There is great benefit to the before-queue setup: mail will never disappear. Senders either get a rejection, or the mail is delivered. With the after-queue setup, you can no longer reject or else you'll be backscattering. So, you either deliver the spam, or you quarantine it (very bad if it's a false positive). The downside is that you use more resources: one amavisd-new per connection. However, the addition of postscreen to postfix has largely ameliorated this. Since postscreen rejects most of the junk, amavis only gets started for smtpd sessions that are likely to succeed. The easiest way to migrate is through incremental improvement. We used to use a system like the one in that guide. I enabled postscreen over the course of a week, and retired postgrey, which we had been using for greylisting. Once that was working properly, I simply dropped the content_filter in favor of smtpd_proxy_filter to move amavis in front of the queue.
Re: [gentoo-user] clamav and spamassassin
On 12/03/2011 07:59 PM, Grant wrote: I haven't set up any antivirus measures on my Gentoo systems so I think I should. Is clamav run as a scheduled filesystem scanner on each system and as an email scanner on the mail server all that's necessary? Nobody (as far as I know?) scans linux filesystems unless there's a legal requirement or the files might wind up on a Windows box. Very cool. I found out clamscan and avgfree scan the filesystem so I thought I should set it up, but if it's not necessary I won't bother. All of my mail users are on Gentoo so do I need to bother having clamav scan my incoming mail? Well, they aren't going to get infected with anything, but ClamAV could still keep the virus message (which is obviously unwanted) out of their inbox. There are also some third-party signatures[1] for ClamAV that catch scam/phishing mail. I'm currently greylisting email to prevent spam from getting through. It catches a lot, but more and more gets through. I'm not using any mailfilters now and If I set up a clamav mailfilter I think I may as well set up a spamassassin mailfilter to take the place of greylisting. Is this the best guide for clamav and spamassassin: SpamAssassin shouldn't take the place of greylisting; they reject different stuff. Keep the greylisting unless the delays bother you, but use postscreen to do it (see below). I just did some reading on postscreen but it doesn't sound like a greylister. Should I use postscreen in addition to postgrey, or are they substitutes for each other? Postscreen isn't a greylist daemon per se, but it has the same effect if you enable the deep protocol tests. Once it gets past the initial greeting (into the deep stages), postscreen can no longer hand off the session to a real smtpd. So, even if the client passes all of the tests, postscreen will send it a 4xx try again. That's essentially greylisting. Postscreen, like Postgrey, keeps a database of good clients, so you shouldn't lose any functionality there. This is what makes the aforementioned 4xx strategy work: when the client reconnects, it bypasses postscreen entirely and goes to a real smtpd. I would make the switch when you have some free time. Postscreen is part of postfix, so it removes one dependency from your mail system. It also adds a couple of nice anti-spam features for free. And, if you ever decide to implement Amavis, postscreen makes the before-queue setup viable. http://www.gentoo.org/doc/en/mailfilter-guide.xml Could I run into any problems with clamav or spamassassin that might make we wish I hadn't implemented them? Yeah. The first is false positives. The second, related problem is that you'll have to manage a quarantine unless you stick amavisd-new in front of the postfix queue. Now that sounds like a hassle. Greylisting leaves me with about 50/50 spam/legit mail and maybe incorporating postscreen I'll do even better. Deleting spam in my inbox might be easier than dealing with false positives and managing a quarantine. You should be able to do a lot better than that with just postscreen and postfix. If you try to implement postscreen, post your main.cf over on postfix-users for review. The built-in restrictions combined with a few RBLs should get you well below 50/50. Plus, if you still get too much spam, you'll already have postscreen in place and that will make adding amavisd-new that much easier. [1] http://www.sanesecurity.com/
Re: [gentoo-user] clamav and spamassassin
Very cool. I found out clamscan and avgfree scan the filesystem so I thought I should set it up, but if it's not necessary I won't bother. All of my mail users are on Gentoo so do I need to bother having clamav scan my incoming mail? Well, they aren't going to get infected with anything, but ClamAV could still keep the virus message (which is obviously unwanted) out of their inbox. There are also some third-party signatures[1] for ClamAV that catch scam/phishing mail. There is info on Linux viruses here: http://en.wikipedia.org/wiki/Linux_malware I shouldn't be concerned about that? I just did some reading on postscreen but it doesn't sound like a greylister. Should I use postscreen in addition to postgrey, or are they substitutes for each other? Postscreen isn't a greylist daemon per se, but it has the same effect if you enable the deep protocol tests. Once it gets past the initial greeting (into the deep stages), postscreen can no longer hand off the session to a real smtpd. So, even if the client passes all of the tests, postscreen will send it a 4xx try again. That's essentially greylisting. Got it. Sounds like postscreen is the successor to postgrey. I will set that up ASAP. Thanks, Grant
Re: [gentoo-user] clamav and spamassassin
On Dec 4, 2011 5:58 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 12/03/2011 02:52 PM, Grant wrote: I haven't set up any antivirus measures on my Gentoo systems so I think I should. Is clamav run as a scheduled filesystem scanner on each system and as an email scanner on the mail server all that's necessary? Nobody (as far as I know?) scans linux filesystems unless there's a legal requirement or the files might wind up on a Windows box. I'm currently greylisting email to prevent spam from getting through. It catches a lot, but more and more gets through. I'm not using any mailfilters now and If I set up a clamav mailfilter I think I may as well set up a spamassassin mailfilter to take the place of greylisting. Is this the best guide for clamav and spamassassin: SpamAssassin shouldn't take the place of greylisting; they reject different stuff. Keep the greylisting unless the delays bother you, but use postscreen to do it (see below). http://www.gentoo.org/doc/en/mailfilter-guide.xml Could I run into any problems with clamav or spamassassin that might make we wish I hadn't implemented them? Yeah. The first is false positives. The second, related problem is that you'll have to manage a quarantine unless you stick amavisd-new in front of the postfix queue. It's in that respect that the tutorial is outdated; otherwise, it looks good (I just skimmed it). There is great benefit to the before-queue setup: mail will never disappear. Senders either get a rejection, or the mail is delivered. With the after-queue setup, you can no longer reject or else you'll be backscattering. So, you either deliver the spam, or you quarantine it (very bad if it's a false positive). The downside is that you use more resources: one amavisd-new per connection. However, the addition of postscreen to postfix has largely ameliorated this. Since postscreen rejects most of the junk, amavis only gets started for smtpd sessions that are likely to succeed. The easiest way to migrate is through incremental improvement. We used to use a system like the one in that guide. I enabled postscreen over the course of a week, and retired postgrey, which we had been using for greylisting. Once that was working properly, I simply dropped the content_filter in favor of smtpd_proxy_filter to move amavis in front of the queue. This is new information to me. If you're subscribed to Gentoo-server, you'll know that I am in the process of setting up a mailfiltering gateway for my company. Any resources on this postscreen facility? sounds like a very nice thing to implement. Rgds,
Re: [gentoo-user] clamav and spamassassin
On 12/03/2011 08:57 PM, Grant wrote: Very cool. I found out clamscan and avgfree scan the filesystem so I thought I should set it up, but if it's not necessary I won't bother. All of my mail users are on Gentoo so do I need to bother having clamav scan my incoming mail? Well, they aren't going to get infected with anything, but ClamAV could still keep the virus message (which is obviously unwanted) out of their inbox. There are also some third-party signatures[1] for ClamAV that catch scam/phishing mail. There is info on Linux viruses here: http://en.wikipedia.org/wiki/Linux_malware I shouldn't be concerned about that? The big risk (although still negligible) is that someone will mail your users an executable that does something bad. But, you would have to save it under /home, chmod +x it, and then run it manually for it to be dangerous. If you use portage to install packages, you should not ever need to chmod +x anything. It's a big red flag and normal users don't even need to know how to do it. Mount /home noexec for extra safety. Note that antivirus wouldn't help anyway if your users are going to do whatever the email says without question =)
Re: [gentoo-user] clamav and spamassassin
On 12/03/2011 08:59 PM, Pandu Poluan wrote: This is new information to me. If you're subscribed to Gentoo-server, you'll know that I am in the process of setting up a mailfiltering gateway for my company. Any resources on this postscreen facility? sounds like a very nice thing to implement. Rgds, Postscreen is just part of Postfix; it's a separate daemon added in the latest version. This is the official README: http://www.postfix.org/POSTSCREEN_README.html and the configuration parameters are documented in the usual place: http://www.postfix.org/postconf.5.html Here's the entirety of my main.cf postscreen section for reference. I've deemed these safe, but you shouldn't enable them without reading what they do! # # Postscreen settings # postscreen_greet_action = enforce postscreen_dnsbl_sites = psbl.surriel.com, bl.spamcop.net, zen.spamhaus.org, b.barracudacentral.org postscreen_dnsbl_threshold = 1 postscreen_dnsbl_action = enforce ## ## Deep protocol tests ## postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce
Re: [gentoo-user] clamav and spamassassin
On Dec 4, 2011 9:21 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 12/03/2011 08:59 PM, Pandu Poluan wrote: This is new information to me. If you're subscribed to Gentoo-server, you'll know that I am in the process of setting up a mailfiltering gateway for my company. Any resources on this postscreen facility? sounds like a very nice thing to implement. Rgds, Postscreen is just part of Postfix; it's a separate daemon added in the latest version. This is the official README: http://www.postfix.org/POSTSCREEN_README.html and the configuration parameters are documented in the usual place: http://www.postfix.org/postconf.5.html Here's the entirety of my main.cf postscreen section for reference. I've deemed these safe, but you shouldn't enable them without reading what they do! # # Postscreen settings # postscreen_greet_action = enforce postscreen_dnsbl_sites = psbl.surriel.com, bl.spamcop.net, zen.spamhaus.org, b.barracudacentral.org postscreen_dnsbl_threshold = 1 postscreen_dnsbl_action = enforce ## ## Deep protocol tests ## postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce Thanks! Very helpful resources. You mentioned amavisd-new. What's their relationship? I mean, if I deploy postscreen, how will it affect amavisd-new? TIA Rgds,
Re: [gentoo-user] clamav and spamassassin
On 12/03/2011 09:48 PM, Pandu Poluan wrote: Thanks! Very helpful resources. You mentioned amavisd-new. What's their relationship? I mean, if I deploy postscreen, how will it affect amavisd-new? Postscreen sits in front of smtpd, and handles all incoming connections. It hands the good connections off to the real smtpd daemon. Amavisd-new (in both before/after-queue configurations) interacts with the real smtpd, so postscreen doesn't directly affect it at all. What was I talking about? With amavisd-new, a before-queue filter is generally nicer, because you can reject spam, notifying the sender, rather than discarding it or backscattering. But, amavisd-new is a hog, and with a before-queue filter, an amavis process gets used every time ANY connection is made. Since 95% of your connections will be crap (that is a technical term), you waste tons of resources creating/killing amavisd-new processes for botnets and other scum that will be rejected quickly. On a busy server, it will kill you. Postscreen only passes the good connections to a real smtpd, so with postscreen running, new amavis processes only get used for those good connections. If postscreen can get reject 90% of the incoming connections, you'll use an order of magnitude less resources doing before-queue filtering than you would without postscreen. So, in essence, postscreen is what allows you to run the before-queue filter with comparable resources to the after-queue filter.
