Stopping backscatter with before-queue
Hey All, I'm having an issue with backscatter emails and implementing a before-queue spam and virus scanner. My current mail server uses a after-queue amavisd-new scanner with spamassassin and clamav. In the last two weeks, my system has started *sending* a significant number of backscatter messages. I need to silence these messages in a safe and reliable way. Here are my criteria: 1) Reject the message before the end of the smtp transaction. 2) Scan for both spam and viruses. 3) Never discard. MTA must deliver-and-tag or reject-and-notify. 4) Scan both incoming and outgoing messages. 5) Scanner is fast, runs as a daemon, and is preferably written in a faster language like C. Despite my best research, I have not yet found a way to do all five of these. Can anyone recommend a way to run amavis as before-queue scanner, or to recommend a different scanner better than amavisd-new. I'm hoping to get some recommendations from the folks here. -Chris
Re: Stopping backscatter with before-queue
Chris Turan wrote: Hey All, I'm having an issue with backscatter emails and implementing a before-queue spam and virus scanner. My current mail server uses a after-queue amavisd-new scanner with spamassassin and clamav. In the last two weeks, my system has started *sending* a significant number of backscatter messages. I need to silence these messages in a safe and reliable way. Here are my criteria: 1) Reject the message before the end of the smtp transaction. 2) Scan for both spam and viruses. 3) Never discard. MTA must deliver-and-tag or reject-and-notify. 4) Scan both incoming and outgoing messages. 5) Scanner is fast, runs as a daemon, and is preferably written in a faster language like C. Despite my best research, I have not yet found a way to do all five of these. Can anyone recommend a way to run amavis as before-queue scanner, or to recommend a different scanner better than amavisd-new. I'm hoping to get some recommendations from the folks here. -Chris You need to configure postfix to reject unknown recipients during SMTP. Switching to something other than amavisd-new and/or switching to a before-queue filter won't help that. amavisd-new meets all your criteria, providing you configure it to tag+deliver mail rather than bounce. You can configure amavisd-new as a before-queue postfix smtpd_proxy_filter. Note this mode is not "officially" supported by the amavisd-new author, but it should work well for small volume sites. The "small volume sites" is a before-queue limitation, not an amavisd-new limitation. If you describe your problem in more detail, you will likely get more specific recommendations in solving it. -- Noel Jones
Re: Stopping backscatter with before-queue
Chris Turan wrote: Hey All, I'm having an issue with backscatter emails and implementing a before-queue spam and virus scanner. My current mail server uses a after-queue amavisd-new scanner with spamassassin and clamav. In the last two weeks, my system has started *sending* a significant number of backscatter messages. I need to silence these messages in a safe and reliable way. Here are my criteria: 1) Reject the message before the end of the smtp transaction. 2) Scan for both spam and viruses. 3) Never discard. MTA must deliver-and-tag or reject-and-notify. 4) Scan both incoming and outgoing messages. 5) Scanner is fast, runs as a daemon, and is preferably written in a faster language like C. Despite my best research, I have not yet found a way to do all five of these. Can anyone recommend a way to run amavis as before-queue scanner, or to recommend a different scanner better than amavisd-new. To eliminate *sending* backscatter, all you need to do is not accept mail you won't be able to deliver: http://www.postfix.org/BACKSCATTER_README.html amavisd-new with spamassassin and clamav will handle #2 #3 and #4 and maybe #5 depending on what you think "fast" is. Unfortunately, there's still no such thing as a "free lunch" and both the virus and spam scanning are not exactly speedy, regardless of how fast amavis is. The trick is to reject everything possible using other means (blacklists, regular expressions, other tests) before finally sending the message to the scanners. That said, it depends very much on your mail volume and how much is spam and how much is ham. I have a small (2 processor, 512M/RAM) mail server that runs anywhere from 30K-60K connections/day, rejects way over 90% of the attempts and still only runs at less than 2% utilization until the spam/AV scanners are started, at which point it runs around 50% for a few seconds, then goes back to 0. Unless you're running a really big site or a really old server, it's unlikely that the performance issues you're worried about will actually be a problem. Postfix is extremely efficient, and the cost of rejecting unwanted connections is really low. Back to your actual problem, if you can post the output from postconf -n, someone can probably tell you what's wrong. Terry
Re: Stopping backscatter with before-queue
Noel Jones wrote: You need to configure postfix to reject unknown recipients during SMTP. Switching to something other than amavisd-new and/or switching to a before-queue filter won't help that. Hey Noel. I actually am rejecting unknown recipients. I wrote some software to refresh the recipients map every five minutes on my system. amavisd-new meets all your criteria, providing you configure it to tag+deliver mail rather than bounce. Well, I also have it set to bounce messages with a spamassassin score above 12. Turning that off and just delivering everything with tagging *could* work. It would be highly annoying for my end users, however. If you describe your problem in more detail, you will likely get more specific recommendations in solving it. Not sure what more I can add, but I'll give it a shot. The backscatter is mostly messages with a spam score above 12. They're being sent off to all sorts of off-site addresses. In addition, there are some messages that has the sender address being set the same as the recipient. -Chris
Re: Stopping backscatter with before-queue
Terry Carmen wrote: To eliminate *sending* backscatter, all you need to do is not accept mail you won't be able to deliver: I am rejecting unknown recipients but the bounces are coming from messages with a spamassassin score above 12. Unfortunately, there's still no such thing as a "free lunch" and both the virus and spam scanning are not exactly speedy, regardless of how fast amavis is. The trick is to reject everything possible using other means (blacklists, regular expressions, other tests) before finally sending the message to the scanners. Hmmm. I did get a suggestion about checking the headers against RBL's using builtin postfix content filters. After that, it can be passed onto the real scanners. That said, it depends very much on your mail volume and how much is spam and how much is ham. I have a small (2 processor, 512M/RAM) mail server that runs anywhere from 30K-60K connections/day, rejects way over 90% of the attempts and still only runs at less than 2% utilization until the spam/AV scanners are started, at which point it runs around 50% for a few seconds, then goes back to 0. I get 10K emails per day, so its still fairly small. Do you have a before-queue scanner installed? There are warnings all over amavisd-new's documentation saying not to use it as a before queue scanner and rightly so. Back to your actual problem, if you can post the output from postconf -n, someone can probably tell you what's wrong. [EMAIL PROTECTED] /]# postconf -n alias_maps = hash:/etc/aliases bounce_queue_lifetime = 4h command_directory = /usr/sbin config_directory = /etc/postfix content_filter = amavis:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix debug_peer_level = 2 home_mailbox = Maildir/ html_directory = no inet_interfaces = all local_recipient_maps = mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man maximal_queue_lifetime = 1d message_size_limit = 20971520 mynetworks = a.a.a.a/32, b.b.b.b/32, c.c.c.c/32, d.d.d.d/32, e.e.e.e/32 newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.5/README_FILES receive_override_options = no_address_mappings relay_domains = hash:/etc/postfix/relay_domains relay_recipient_maps = hash:/etc/postfix/relay_recipient_maps sample_directory = /usr/share/doc/postfix-2.4.5/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_tls_CAfile = /etc/postfix/certs/gd_intermediate_bundle.crt smtpd_tls_CApath = /etc/postfix/certs smtpd_tls_cert_file = /etc/postfix/certs/.crt smtpd_tls_key_file = /etc/postfix/certs/.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_use_tls = yes transport_maps = hash:/etc/postfix/transport_maps unknown_local_recipient_reject_code = 550 [EMAIL PROTECTED] /]#
Re: Stopping backscatter with before-queue
Chris Turan wrote: Noel Jones wrote: You need to configure postfix to reject unknown recipients during SMTP. Switching to something other than amavisd-new and/or switching to a before-queue filter won't help that. Hey Noel. I actually am rejecting unknown recipients. I wrote some software to refresh the recipients map every five minutes on my system. amavisd-new meets all your criteria, providing you configure it to tag+deliver mail rather than bounce. Well, I also have it set to bounce messages with a spamassassin score above 12. Turning that off and just delivering everything with tagging *could* work. It would be highly annoying for my end users, however. If you describe your problem in more detail, you will likely get more specific recommendations in solving it. Not sure what more I can add, but I'll give it a shot. The backscatter is mostly messages with a spam score above 12. They're being sent off to all sorts of off-site addresses. In addition, there are some messages that has the sender address being set the same as the recipient. -Chris Setting amavisd-new to tag+deliver with D_PASS will solve your backscatter problem. Use zen.spamhaus.org to reduce the number of spams entering your system. Add clamav to amavisd-new if you don't have it already, and use the Sanesecurity add-on signatures (in addition to the official clamav signatures, of course). If you want to investigate setting up amavisd-new as a pre-queue filter, general instructions are here: http://www.postfix.org/SMTPD_PROXY_README.html More specific instructions can likely be found in the archives of the amavis-users mail list. -- Noel Jones
Re: Stopping backscatter with before-queue
On Mon, Dec 08, 2008 at 03:13:57PM -0600, Noel Jones wrote: > > If you want to investigate setting up amavisd-new as a pre-queue filter, > general instructions are here: > http://www.postfix.org/SMTPD_PROXY_README.html > More specific instructions can likely be found in the archives of the > amavis-users mail list. This is fine read, but have a look at amavisd-milter, which is much better solution for before-queue amavisd.
Re: Stopping backscatter with before-queue
Chris Turan wrote: Terry Carmen wrote: To eliminate *sending* backscatter, all you need to do is not accept mail you won't be able to deliver: I am rejecting unknown recipients but the bounces are coming from messages with a spamassassin score above 12. Don't do that. Once you've accepted a message, it's yours. Aside from anything else, it makes you look bad when someone sends a legitimate email that happens to "look" spammy and you bounce it back as spam. One of my clients HOLDs spammy messages for manual inspection by the postmaster, then releases or deletes it. Another one lets the users email application deal with the messages based on the spamassassin header. Unfortunately, there's still no such thing as a "free lunch" and both the virus and spam scanning are not exactly speedy, regardless of how fast amavis is. The trick is to reject everything possible using other means (blacklists, regular expressions, other tests) before finally sending the message to the scanners. Hmmm. I did get a suggestion about checking the headers against RBL's using builtin postfix content filters. After that, it can be passed onto the real scanners. You just about have to use an RBL or you'll get creamed. However before sending it to the RBL, reject everything possible using less (processor/network) expensive methods like rdns verification and regular expressions. See "Re:RBL" on this list for more information. That said, it depends very much on your mail volume and how much is spam and how much is ham. I have a small (2 processor, 512M/RAM) mail server that runs anywhere from 30K-60K connections/day, rejects way over 90% of the attempts and still only runs at less than 2% utilization until the spam/AV scanners are started, at which point it runs around 50% for a few seconds, then goes back to 0. I get 10K emails per day, so its still fairly small. Do you have a before-queue scanner installed? There are warnings all over amavisd-new's documentation saying not to use it as a before queue scanner and rightly so. I have no before-queue scanner. I reject everything possible based on the senders IP, existence of an rdns entry and some regular expressions (see Re:RBL"). Anything that makes it past there is never rejected or bounced, no matter what. It either goes to the final recipient or is deleted based on corporate policy (chain letters, porn, etc.) Back to your actual problem, if you can post the output from postconf -n, someone can probably tell you what's wrong. Terry
Re: Stopping backscatter with before-queue
Chris Turan wrote: Noel Jones wrote: amavisd-new meets all your criteria, providing you configure it to tag+deliver mail rather than bounce. Well, I also have it set to bounce messages with a spamassassin score above 12. Turning that off and just delivering everything with tagging *could* work. It would be highly annoying for my end users, however. Tough-- you're really creating your own misery here. You MUST either reject at the gateway, or accept the traffic without sending a bounce. You can delete silently if you trust your filters, but given that the vast majority of spam has a forged From: header, you're inflicting YOUR spam problem on innocent third parties. Failure to do this will get your server blacklisted at some sites.
RE: Stopping backscatter with before-queue
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Turan > Sent: Tuesday, 9 December 2008 7:39 AM > To: Terry Carmen > Cc: postfix-users@postfix.org > Subject: Re: Stopping backscatter with before-queue > > Terry Carmen wrote: > > To eliminate *sending* backscatter, all you need to do is not accept > > mail you won't be able to deliver: > > I am rejecting unknown recipients but the bounces are coming from > messages with a spamassassin score above 12. > > > Hmmm. I did get a suggestion about checking the headers against RBL's > using builtin postfix content filters. After that, it can be passed > onto the real scanners. > > I get 10K emails per day, so its still fairly small. Do you have a > before-queue scanner installed? There are warnings all over > amavisd-new's documentation saying not to use it as a before queue > scanner and rightly so. > > > Back to your actual problem, if you can post the output > from postconf > > -n, someone can probably tell you what's wrong. > > [EMAIL PROTECTED] /]# postconf -n > alias_maps = hash:/etc/aliases > bounce_queue_lifetime = 4h > command_directory = /usr/sbin > config_directory = /etc/postfix > content_filter = amavis:[127.0.0.1]:10024 > daemon_directory = /usr/libexec/postfix > debug_peer_level = 2 > home_mailbox = Maildir/ > html_directory = no > inet_interfaces = all > local_recipient_maps = > mail_owner = postfix > mailq_path = /usr/bin/mailq.postfix > manpage_directory = /usr/share/man > maximal_queue_lifetime = 1d > message_size_limit = 20971520 > mynetworks = a.a.a.a/32, b.b.b.b/32, c.c.c.c/32, d.d.d.d/32, > e.e.e.e/32 > newaliases_path = /usr/bin/newaliases.postfix > queue_directory = /var/spool/postfix > readme_directory = /usr/share/doc/postfix-2.4.5/README_FILES > receive_override_options = no_address_mappings > relay_domains = hash:/etc/postfix/relay_domains > relay_recipient_maps = hash:/etc/postfix/relay_recipient_maps > sample_directory = /usr/share/doc/postfix-2.4.5/samples > sendmail_path = /usr/sbin/sendmail.postfix > setgid_group = postdrop > smtpd_tls_CAfile = /etc/postfix/certs/gd_intermediate_bundle.crt > smtpd_tls_CApath = /etc/postfix/certs > smtpd_tls_cert_file = /etc/postfix/certs/.crt > smtpd_tls_key_file = /etc/postfix/certs/.key > smtpd_tls_loglevel = 1 > smtpd_tls_received_header = yes > smtpd_tls_security_level = may > smtpd_use_tls = yes > transport_maps = hash:/etc/postfix/transport_maps > unknown_local_recipient_reject_code = 550 I don't see the smtpd_*_restrictions. Sensible ones there cut down on acres of spam and take load off the content scanner, without much in the way of false positives (in fact, I have none). I suggest (after permit_mynetworks, for each set): smtpd_helo_restrictions = reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, (this one traps the most from bots) smtpd_client_restrictions = reject_non_fqdn_hostname, reject_unknown_reverse_client_hostname OR reject_unknown_client_hostname (this one tends to cause more false positives, due to idiots configuring their DNS) smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain smtpd_recipient_restrictions = reject_unauth_destination reject_non_fqdn_recipient, reject_rbl_client zen.spamhaus.org, smtpd_data_restrictions = reject_unauth_pipelining Also set strict_rfc821_envelopes = yes (unless you have ancient mail clients you need to support) All my senders are in mynetworks (or I'd be using auth, in any case), so I can have a sender access map (after permit_mynetworks) that basically consists of "@mydomain.com REJECT". You can have helo access maps that reject servers purporting to be your own.
Re: Stopping backscatter with before-queue
Terry Carmen wrote: Don't do that. Once you've accepted a message, it's yours. Aside from anything else, it makes you look bad when someone sends a legitimate email that happens to "look" spammy and you bounce it back as spam. Right, I'm trying to correct that problem. This wasn't much of an issue when I first set up this server. None of my addresses or domains were known to the spammers and as a result, I sent very very little backscatter. That's changed now and I need to rethink things. One of my clients HOLDs spammy messages for manual inspection by the postmaster, then releases or deletes it. This is a great idea! I didn't think of this at all but this idea will definitely solve the problem for the interim until I can design and QA a new server. I've just set it to forward spammy messages to a mailbox where I'll review and release messages. You just about have to use an RBL or you'll get creamed. However before sending it to the RBL, reject everything possible using less (processor/network) expensive methods like rdns verification and regular expressions. See "Re:RBL" on this list for more information. I'm reading the postfix pages on this now. I didn't know postfix had this many knobs for RBL stuff. I will try it! I have no before-queue scanner. I reject everything possible based on the senders IP, existence of an rdns entry and some regular expressions (see Re:RBL"). Anything that makes it past there is never rejected or bounced, no matter what. It either goes to the final recipient or is deleted based on corporate policy (chain letters, porn, etc.) Nice! I've been relying on bayesian scanning for the most part. Althought, passing everything concerns me a bit but if the RBL's work, then I think I should be in the clear. This one really underlines the fact that I'm the one that's creating my own problem. -Chris
Re: Stopping backscatter with before-queue
Corey Chandler wrote: Tough-- you're really creating your own misery here. You MUST either reject at the gateway, or accept the traffic without sending a bounce. You can delete silently if you trust your filters, but given that the vast majority of spam has a forged From: header, you're inflicting YOUR spam problem on innocent third parties. Failure to do this will get your server blacklisted at some sites. Ouch, but you're right. I am creating my own misery. It wasn't a problem before when I was unknown to the spammers. Its only been a problem for a few weeks and I haven't yet been put on any blacklists. -Chris
Re: Stopping backscatter with before-queue
Chris Turan wrote: > > Ouch, but you're right. I am creating my own misery. It wasn't a > problem before when I was unknown to the spammers. Its only been a > problem for a few weeks and I haven't yet been put on any blacklists. Keep sending out backscatter spam, and you will most certainly end up on blacklists. Joe
Re: Stopping backscatter with before-queue
J Sloan wrote: Keep sending out backscatter spam, and you will most certainly end up on blacklists. I think you might have misread my intention. I definitely don't want to continue sending backscatter. Per another suggestion on the list, I made a change that stopped all of my backscatter spam. So I'm officially not sending backscatter as of an hour ago. -Chris
Re: Stopping backscatter with before-queue
Chris Turan wrote: Terry Carmen wrote: Don't do that. Once you've accepted a message, it's yours. Aside from anything else, it makes you look bad when someone sends a legitimate email that happens to "look" spammy and you bounce it back as spam. Right, I'm trying to correct that problem. This wasn't much of an issue when I first set up this server. None of my addresses or domains were known to the spammers and as a result, I sent very very little backscatter. That's changed now and I need to rethink things. One of my clients HOLDs spammy messages for manual inspection by the postmaster, then releases or deletes it. This is a great idea! I didn't think of this at all but this idea will definitely solve the problem for the interim until I can design and QA a new server. I've just set it to forward spammy messages to a mailbox where I'll review and release messages. If you don't' want to corrupt the destination addresses, you can just tag them as "HOLD" with /^X-Spam-Level.*\*\*\*\*/ HOLD in /etc/postfix/header_checks which will leave the suspect messages in the Postfix HOLD queue, where you can inspect them with postcat and release or delete them with postsuper. just make sure you have: header_checks=regexp:/etc/postfix/header_checks in your main.cf file. I have no before-queue scanner. I reject everything possible based on the senders IP, existence of an rdns entry and some regular expressions (see Re:RBL"). Anything that makes it past there is never rejected or bounced, no matter what. It either goes to the final recipient or is deleted based on corporate policy (chain letters, porn, etc.) Nice! I've been relying on bayesian scanning for the most part. Althought, passing everything concerns me a bit but if the RBL's work, then I think I should be in the clear. This one really underlines the fact that I'm the one that's creating my own problem. The RBLs help a lot, as do the regular expressions in the other referenced thread. Good luck! Terry -- Terry Carmen CNY Support, LLC 315.382.3939 http://cnysupport.com
Re: Stopping backscatter with before-queue
Thank you to everyone. I'm getting some great suggestions. I didn't know about several of the features postfix provides and have been relying mostly on spamassassin to do the work for me. I don't see the smtpd_*_restrictions. Sensible ones there cut down on acres of spam and take load off the content scanner, without much in the way of false positives (in fact, I have none). Well, my smtpd_*_restrictions aren't really used on my exterior mx routers. My users do not talk to those servers ever. Mine are exceedingly simple. For the ports the mx gateways connect to: smtpd_recipient_restrictions = permit_mynetworks, reject For ports the users connect to: smtpd_recipient_restrictions = permit_sasl_authenticated, reject I suggest (after permit_mynetworks, for each set): reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_hostname, reject_unknown_reverse_client_hostname, reject_unknown_client_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_destination, reject_non_fqdn_recipient, reject_rbl_client zen.spamhaus.org, reject_unauth_pipelining I do have a concern for some of these. I pretty much have to support tons of mail clients from roaming users around the states. I have the whole run of microsoft mail clients, plus apple, and a significant linux user base as well. In addition, I have no control over the networks they're coming from, trust me their dns is severely messed up over there. I'll have to be relatively conservative in which ones I use here. I definitely can't use reject_unknown_reverse_client_hostname and reject_unknown_client_hostname. reject_unauth_destination is superfluous for my servers since there is a clean divide on the ports that users and regular incoming mail uses. reject_unknown_sender_domain also looks like a no-go since some users have non-resolvable internal domains. They do stuff like my-company-name.local instead of my-company-name.com. Here's a list of the ones that look ok for my setup. reject_invalid_helo_hostname reject_non_fqdn_helo_hostname, reject_non_fqdn_hostname reject_non_fqdn_sender, reject_non_fqdn_recipient reject_unauth_pipelining I can't use the PBL, so I'll probably have to use this instead. reject_rbl_client sbl-xbl.spamhaus.org Has anyone seen any weird issues when using the ones I've listed above. I'd rather pass the mail than risk a false positive. Any non-compliant microsoft products? :-) Thanks for all the help again!
Re: Stopping backscatter with before-queue
Chris Turan wrote: Thank you to everyone. I'm getting some great suggestions. I didn't know about several of the features postfix provides and have been relying mostly on spamassassin to do the work for me. I don't see the smtpd_*_restrictions. Sensible ones there cut down on acres of spam and take load off the content scanner, without much in the way of false positives (in fact, I have none). Well, my smtpd_*_restrictions aren't really used on my exterior mx routers. My users do not talk to those servers ever. Mine are exceedingly simple. For the ports the mx gateways connect to: smtpd_recipient_restrictions = permit_mynetworks, reject For ports the users connect to: smtpd_recipient_restrictions = permit_sasl_authenticated, reject I suggest (after permit_mynetworks, for each set): reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_hostname, reject_unknown_reverse_client_hostname, reject_unknown_client_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_destination, reject_non_fqdn_recipient, reject_rbl_client zen.spamhaus.org, reject_unauth_pipelining I do have a concern for some of these. I pretty much have to support tons of mail clients from roaming users around the states. I have the whole run of microsoft mail clients, plus apple, and a significant linux user base as well. In addition, I have no control over the networks they're coming from, trust me their dns is severely messed up over there. I'll have to be relatively conservative in which ones I use here. I definitely can't use reject_unknown_reverse_client_hostname and reject_unknown_client_hostname. reject_unauth_destination is superfluous for my servers since there is a clean divide on the ports that users and regular incoming mail uses. reject_unknown_sender_domain also looks like a no-go since some users have non-resolvable internal domains. They do stuff like my-company-name.local instead of my-company-name.com. Here's a list of the ones that look ok for my setup. reject_invalid_helo_hostname reject_non_fqdn_helo_hostname, reject_non_fqdn_hostname reject_non_fqdn_sender, reject_non_fqdn_recipient reject_unauth_pipelining I can't use the PBL, so I'll probably have to use this instead. reject_rbl_client sbl-xbl.spamhaus.org Has anyone seen any weird issues when using the ones I've listed above. I'd rather pass the mail than risk a false positive. Any non-compliant microsoft products? :-) Thanks for all the help again! You misunderstand -- You don't subject your authenticated users to those suggested checks, only outsiders. These checks go on the MX gateway. Any port that an authenticated user might connect to should have permit_sasl_authenticated as one of the first restrictions listed. This will exempt them from any further checks. -- Noel Jones
Re: Stopping backscatter with before-queue
Chris Turan a écrit : > Thank you to everyone. I'm getting some great suggestions. I didn't > know about several of the features postfix provides and have been > relying mostly on spamassassin to do the work for me. > >> I don't see the smtpd_*_restrictions. Sensible ones there cut down on >> acres of spam and take load off the content scanner, without much in >> the way of false positives (in fact, I have none). > > Well, my smtpd_*_restrictions aren't really used on my exterior mx > routers. My users do not talk to those servers ever. Mine are > exceedingly simple. > > For the ports the mx gateways connect to: > smtpd_recipient_restrictions = permit_mynetworks, reject > > For ports the users connect to: > smtpd_recipient_restrictions = permit_sasl_authenticated, reject > > >> I suggest (after permit_mynetworks, for each set): >> reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, >> reject_non_fqdn_hostname, reject_unknown_reverse_client_hostname, >> reject_unknown_client_hostname, reject_non_fqdn_sender, >> reject_unknown_sender_domain, reject_unauth_destination, >> reject_non_fqdn_recipient, reject_rbl_client zen.spamhaus.org, >> reject_unauth_pipelining > > I do have a concern for some of these. I pretty much have to support > tons of mail clients from roaming users around the states. I have the > whole run of microsoft mail clients, plus apple, and a significant linux > user base as well. In addition, I have no control over the networks > they're coming from, trust me their dns is severely messed up over > there. I'll have to be relatively conservative in which ones I use here. > > I definitely can't use reject_unknown_reverse_client_hostname and > reject_unknown_client_hostname. reject_unauth_destination is > superfluous for my servers since there is a clean divide on the ports > that users and regular incoming mail uses. reject_unknown_sender_domain > also looks like a no-go since some users have non-resolvable internal > domains. They do stuff like my-company-name.local instead of > my-company-name.com. > > Here's a list of the ones that look ok for my setup. >reject_invalid_helo_hostname >reject_non_fqdn_helo_hostname, >reject_non_fqdn_hostname reject_non_fqdn_helo_hostname is the new name for reject_non_fqdn_hostname >reject_non_fqdn_sender, >reject_non_fqdn_recipient >reject_unauth_pipelining > > I can't use the PBL, so I'll probably have to use this instead. >reject_rbl_client sbl-xbl.spamhaus.org > when you use smtpd_recipient_restrictions = reject_non_fqdn_sender reject_non_fqdn_recipient permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_sender_domain reject_rbl_client zen.spamhaus.org on your MX, the last reject checks (starting from reject_unauth_destination) are not applied to authenticated transactions nor to clients listed in mynetworks (that's the goal of the permit_* checks). Order does matter;-p > > Has anyone seen any weird issues when using the ones I've listed above. > I'd rather pass the mail than risk a false positive. > if you are afraid, add warn_if_reject before each check. for example warn_if_reject reject_invalid_helo_hostname warn_if_reject reject_non_fqdn_helo_hostname you can also get more logs using: smtpd_client_restrictions = check_reverse_client_hostname_access pcre:/etc/postfix/log_transaction ... == log_transaction: /./ WARN Transaction logged: PTR=$1 This way, you will have the PTR and the HELO of each transaction, even if the transaction is just a probe. > Any non-compliant microsoft products? :-) some MTAs used to send a non fqdn helo. I'm not sure if there are still many. (If there are still, I'd be interested to hear about it). > > Thanks for all the help again! >
