Re: Unknown senders and spam
Alex: Hi, $ postfix check postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net DO NOT USE warn_if_reject AT THE BEGINNING OF A RULE. Wietse
Re: Unknown senders and spam
On 4/20/2010 10:47 PM, Alex wrote: Hi, $ postfix check postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net Duh. read the error message again and tell me what it has to do with reject_rbl_client. Yes, sorry, I meant to use reject_rbl_client, but it doesn't work there either: Apr 20 23:43:02 smtp01 postfix[30380]: fatal: /etc/postfix/main.cf, line 609: missing '=' after attribute name: warn_if_reject reject_rbl_client backscatter.spameatingmonkey.net It appears that it's not supported in my version (postfix-20020613). As an interim solution, do you think I could get a later postfix working, say, postfix-1.1.13 without much difficulty, and benefit from some of these features to ease testing and migration to postfix-2.7 later? Thanks, Alex You're still using warn_if_reject wrong; that's why you're getting an error. If you post your postconf -n we can show you exactly what to change to use warn_if_reject.
Re: Unknown senders and spam
Hi, You're still using warn_if_reject wrong; that's why you're getting an error. If you post your postconf -n we can show you exactly what to change to use warn_if_reject. Thanks so much for your help. I've included it below. Ideally I'd like to have support for smtpd_restriction_classes and reject_unknown_reverse_client_hostname or related lesser strict restrictions. You'll notice I have two instances set up, for use with amavisd. alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases alternate_config_directories = /etc/postfix_f always_bcc = biff = no body_checks = regexp:/etc/postfix/body_checks.pcre command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix default_process_limit = 120 delay_warning_time = 0 disable_mime_input_processing = yes disable_vrfy_command = yes enabled = yes fallback_relay = header_checks = pcre:/etc/postfix/header_checks.pcre, pcre:/etc/postfix/header_checks-jimsun.pcre mail_owner = postfix mailbox_command = /usr/bin/procmail mailbox_size_limit = 25600 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man maps_rbl_domains = zen.spamhaus.org maximal_queue_lifetime = 5d message_size_limit = 13312000 mime_header_checks = minimal_backoff_time = 800s mydestination = $myhostname, localhost.$mydomain myhostname = smtp01.mydomain.com mynetworks = 127.0.0.0/8, 2XX.201.XXX.45/32 newaliases_path = /usr/bin/newaliases parent_domain_matches_subdomains = smtpd_access_maps queue_directory = /var/spool/postfix readme_directory = /etc/postfix/README_FILES relay_domains = $mydestination, mydomain.com, mkt.mydomain.com, sales.mydomain.com relayhost = sample_directory = /etc/postfix/samples sender_canonical_maps = sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_client_access hash:/etc/postfix/client_checks, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unauth_destination, check_helo_access hash:/etc/postfix/helo_checks, check_recipient_access pcre:/etc/postfix/recipient_checks, check_recipient_access pcre:/etc/postfix/main_relay_recip_checks, check_recipient_access pcre:/etc/postfix/sales_recip_map, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, reject_maps_rbl transport_maps = hash:/etc/postfix/transport unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 virtual_maps = hash:/etc/postfix/virtual
Re: Unknown senders and spam
On 4/21/2010 9:31 AM, Alex wrote: Hi, You're still using warn_if_reject wrong; that's why you're getting an error. If you post your postconf -n we can show you exactly what to change to use warn_if_reject. Thanks so much for your help. I've included it below. Ideally I'd like to have support for smtpd_restriction_classes and reject_unknown_reverse_client_hostname or related lesser strict restrictions. You'll notice I have two instances set up, for use with amavisd. For new features you'll need to upgrade. As a general rule, upgrading postfix is pretty easy if you read the RELEASE_NOTES. That said, smtpd_restriction_classes is a fairly old feature, and likely supported by your version. For the others, you'll need to upgrade. relay_domains = $mydestination, mydomain.com, mkt.mydomain.com, sales.mydomain.com Unless these are really relay_domains (relayed to a different server for final delivery) they shouldn't be listed here. relay_domains = smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_client_access hash:/etc/postfix/client_checks, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unauth_destination, check_helo_access hash:/etc/postfix/helo_checks, check_recipient_access pcre:/etc/postfix/recipient_checks, check_recipient_access pcre:/etc/postfix/main_relay_recip_checks, check_recipient_access pcre:/etc/postfix/sales_recip_map, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, reject_maps_rbl Change the above line to warn_if_reject reject_maps_rbl -- Noel Jones
Re: Unknown senders and spam
Hi, $ postfix check postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net Duh. read the error message again and tell me what it has to do with reject_rbl_client. Yes, sorry, I meant to use reject_rbl_client, but it doesn't work there either: Apr 20 23:43:02 smtp01 postfix[30380]: fatal: /etc/postfix/main.cf, line 609: missing '=' after attribute name: warn_if_reject reject_rbl_client backscatter.spameatingmonkey.net It appears that it's not supported in my version (postfix-20020613). As an interim solution, do you think I could get a later postfix working, say, postfix-1.1.13 without much difficulty, and benefit from some of these features to ease testing and migration to postfix-2.7 later? Thanks, Alex
Re: Unknown senders and spam
Hi, I'm trying to do: warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net wrong syntax. it's warn_if_reject reject_rbl_client $yourlist There's no 'equal' sign. $ postfix check postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net But it appears that's only available in later versions, so I've tried this, and it also doesn't work: warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net doubly wrong syntax. besides the '=' sign, reject_rbl_maps doesn't take an argument. Looks like I'm SOL for now? :-) Thanks again, Alex
Re: Unknown senders and spam
Noel Jones put forth on 4/18/2010 10:55 PM: Yes, reject_unknown_client_hostname is still too strict for us. And we're very strict! I ran with this for a short while. Had problems with it rejecting Hotmail connections. And these weren't Hotmail user mails beings delivered, but responses to my spam reports coming from the Hotmail abuse dept. Had too many other legit mails refused as well. It didn't stop any more spam here than reject_unknown_reverse_client_hostname so I reverted back to the latter. -- Stan
Re: Unknown senders and spam
Alex put forth on 4/19/2010 12:11 AM: It looks like I have a big project ahead of me to upgrade. What kind of process is involved with going from such an old version to the current, independent of all the other software? Not much. Just create/modify the new main.cf and any other config files you need, possibly using data from the old files but with current parameter syntax. As always, and as stated in the list welcome message, pasting postconf -n output for us to look at would be very helpful to both the list, and thus, more importantly, to you. I'm assuming Postfix 1.x has postconf. I didn't use it back then. I was still in diapers. ;) -- Stan
Re: Unknown senders and spam
On 4/19/2010 12:11 AM, Alex wrote: The warn_if_reject feature predates reject_unauth_pipelining, which you seem to be using successfully. I strongly suspect there was some other error -- probably a simple typo in your config -- that kept warn_if_reject from working for you. I'm trying to do: warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net But it appears that's only available in later versions, so I've tried this, and it also doesn't work: warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net warn_if_reject should proceed a restriction in your smtpd_recipient_restrictions. smtpd_recipient_restrictions = permit_mynetworks ... warn_if_reject reject_msps_rbl I misquoted HISTORY about when reject_unauth_pipelining was introduced, actually should have been: 19990905 ... Feature: reject_unauth_pipelining SMTP restriction that rejects mail from clients that improperly use SMTP command pipelining. The part I quoted was about adding the smtpd_data_restrictions feature. So it's possible that your postfix doesn't support warn_if_reject, which was added in Nov 2001. You can check your postfix version and release date with postconf mail_version mail_release_date Will reject_rhsbl_sender and reject_rhsbl_client work in old versions? Don't know... HISTORY says those features were added in Sept 2002. Check your mail_release_date and mail_version, and if they look promising, give it a try. The reason you don't get flamed for running ancient postfix is that even ancient postfix is fairly secure. You're just missing new features and bug fixes. But I would worry about the OS and the other software that may be running on a box with such an old postfix. -- Noel Jones
Re: Unknown senders and spam
On Sun, Apr 18, 2010 at 10:38:46PM -0500, Noel Jones wrote: On 4/18/2010 9:56 PM, /dev/rob0 wrote: reject_unauth_pipelining, Might catch some zombies. Note that with older postfix (postfix 2.6 IIRC) reject_unauth_pipelining must be used in smtpd_data_restrictions to be effective. It won't break anything in smtpd_recipient_restrictions, but it won't block anything either. Oops. You caught me on that once before, telling someone it would *not* work in smtpd_recipient_restrictions, and now here, forgetting to mention that in this case, it won't. :) reject_maps_rbl, Old syntax, could be good or could be disastrous. Switch to the new syntax (new since Postfix 2.0 IIRC) of reject_rbl_client zone.name. Using the old syntax is harmless[1] and still works; the new syntax was introduced for more flexibility. [1] harmless until some undefined point in the future when it's removed and no longer recognized. The possible disaster to which I was referring was the case in which one of the listed DNSBL operators decides to list the whole Internet, some time after having retired the DNSBL. The point being, we don't have any way to know from reading his post. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Unknown senders and spam
Alex a écrit : Hi, I'm trying to do: warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net wrong syntax. it's warn_if_reject reject_rbl_client $yourlist There's no 'equal' sign. $ postfix check postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net Duh. read the error message again and tell me what it has to do with reject_rbl_client.
Re: Unknown senders and spam
Alex: Hi, I'm wondering about some messages with Received headers such as this: Received: from zaphod.chipchaps.com (unknown [65.182.186.13]) It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a spam site), which resolves back to 65.182.186.12. Is this where the problem is? The definition of an unknown client hostname is given in http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname which, as the name suggests, rejects mail from a client with a hostname that Postfix considers unknown. Wietse I'm not sure if I'm having a DNS problem with my resolver not being able to find the answer in time (or at all), or I'm possibly not understanding how to do this properly. I'd like to determine if I can add additional restrictions in postfix to limit connections from hosts that don't resolve properly, but before I can do that I need to make sure my DNS is working properly. Maybe I'm able to resolve it now but wasn't able to when the email arrived? Maybe the DNS info has changed since the email was received? What are the risks or implications of denying messages of this type? Thanks, Alex
Re: Unknown senders and spam
Hi, Received: from zaphod.chipchaps.com (unknown [65.182.186.13]) It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a spam site), which resolves back to 65.182.186.12. Is this where the problem is? The definition of an unknown client hostname is given in http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname which, as the name suggests, rejects mail from a client with a hostname that Postfix considers unknown. Is it common practice to have that restriction in a production environment? It appears to be the third case here, that the name-address mapping does not match the client IP address. Could this be from a legitimate cause, or typically intentionally to be evasive? Could it be found in a legitimate dynamic environment, such as at an ISP? Is there a way to log these specific failures so I can get a better idea of under what circumstances they occur in my environment? I'm currently rejecting the following, in this order: reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unauth_destination, reject_maps_rbl, Thanks, Alex
Re: Unknown senders and spam
Alex: Hi, ? ? Received: from zaphod.chipchaps.com (unknown [65.182.186.13]) It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a spam site), which resolves back to 65.182.186.12. Is this where the problem is? The definition of an unknown client hostname is given in http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname which, as the name suggests, rejects mail from a client with a hostname that Postfix considers unknown. Is it common practice to have that restriction in a production environment? Yes, if the tolerance for spam is worse than the tolerance for mail not received. [speculation deleted] Is there a way to log these specific failures so I can get a better idea of under what circumstances they occur in my environment? Postfix logs a warning when the reverse name does not resolve, or when the reverse name resolves to the wrong address: warning: 1.2.3.4: hostname example.com verification failed: Host not found, try again warning: 1.2.3.4: address not listed for hostname example.com When you report a problem, it is a good idea to look at the warning messages in the Postfix logfile. Wietse
Re: Unknown senders and spam
Alex a écrit : Hi, Received: from zaphod.chipchaps.com (unknown [65.182.186.13]) It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a spam site), which resolves back to 65.182.186.12. Is this where the problem is? The definition of an unknown client hostname is given in http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname which, as the name suggests, rejects mail from a client with a hostname that Postfix considers unknown. Is it common practice to have that restriction in a production environment? It appears to be the third case here, that the name-address mapping does not match the client IP address. Could this be from a legitimate cause, or typically intentionally to be evasive? since they put their domain name in their HELO (zaphod.chipchaps.com), they're not trying to evade anything. you could try check_client_access hash:/etc/postfix/access_unknown smtpd_restriction_classes = ... policy_strong policy_strong = reject_rbl_client bb.barracudacentral.org ... == access_unknown unknown policy_strong as usual, use at your own risk! you can try it with warn_if_reject for some time if that makes you feel more confident (and no, I don't use such a check). Could it be found in a legitimate dynamic environment, such as at an ISP? no, these are spammers (illegal work from home). the domain probably belongs to Global Innovative Marketing as you can find by visiting their web page (www.chipchaps...) then clicking on the link at the bottom, which leads you to a privacy page, and if you scroll down, you get br...@myvemmaoffice.com. whois of the latter gives Global Innovative Marketing (both chipchaps and bvconsulting.org have hidden whois). anyway, - www.chipchaps... sis enough to convince you they are spammers. - they have two IPs (.12 and .13) inside a range of IPs with generic names belonging to pugmarks.com, who provide hosting... Also look at Senderbase: http://www.senderbase.org/senderbase_queries/detailip?search_string=65.182.186.0%2F24 you can probably block the whole range... Is there a way to log these specific failures so I can get a better idea of under what circumstances they occur in my environment? I'm currently rejecting the following, in this order: reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unauth_destination, reject_maps_rbl, Thanks, Alex
Re: Unknown senders and spam
Hi, Is it common practice to have that restriction in a production environment? It appears to be the third case here, that the name-address mapping does not match the client IP address. Could this be from a legitimate cause, or typically intentionally to be evasive? since they put their domain name in their HELO (zaphod.chipchaps.com), they're not trying to evade anything. Yes, I guess they would have been rejected as a result of my helo checks. you could try check_client_access hash:/etc/postfix/access_unknown smtpd_restriction_classes = ... policy_strong policy_strong = reject_rbl_client bb.barracudacentral.org Is it possible to use maps_rbl_domains instead of reject_rbl_client here? It appears this machine has a version of postfix that doesn't understand reject_rbl_client. Thanks again! Best regards, Alex
Re: Unknown senders and spam
Alex put forth on 4/18/2010 4:45 PM: Is it possible to use maps_rbl_domains instead of reject_rbl_client here? It appears this machine has a version of postfix that doesn't understand reject_rbl_client. maps_rbl_domains (default: empty) Obsolete feature: use the reject_rbl_client feature instead. reject_rbl_client rbl_domain=d.d.d.d ... *** This feature is available in Postfix 2.0 and later. *** (emphasis mine) Your statement leads me to believe you're using a Postfix version less than 2.0. IIRC, versions less than 2.3 are no longer supported. It appears you _really_ need to upgrade Postfix on that host. And given that it's likely a distribution package, you probably really need to update the OS on that host as well. -- Stan
Re: Unknown senders and spam
Hi, maps_rbl_domains (default: empty) Obsolete feature: use the reject_rbl_client feature instead. Yes, that was why I was asking. It's a really old version of postfix I'm still using on this host for now, until I can migrate to an entirely new server and at the same time keep this one running. I just wanted to confirm that this feature, or an equivalent, isn't available in old versions of postfix? Thanks, Alex
Re: Unknown senders and spam
Alex: Hi, maps_rbl_domains (default: empty) ? ?Obsolete feature: use the reject_rbl_client feature instead. Yes, that was why I was asking. It's a really old version of postfix I'm still using on this host for now, until I can migrate to an entirely new server and at the same time keep this one running. I just wanted to confirm that this feature, or an equivalent, isn't available in old versions of postfix? If in doubt read the documentation. man 5 postconf ... reject_rbl_client rbl_domain=d.d.d.d ... This feature is available in Postfix 2.0 and later.
Re: Unknown senders and spam
Note: just before sending this I went back to read the rest of the thread, wherein I see that you're using a pre-2.0 Postfix. Some of my advice below is thereby not relevant to this host, namely, the suggestion to use newer syntax and the newer restriction, reject_unknown_reverse_client_hostname. IMO that would be worth an upgrade. On Sun, Apr 18, 2010 at 02:19:15PM -0400, Alex wrote re: reject_unknown_client_hostname : Is it common practice to have that restriction in a production environment? Recently I had a failure of reverse DNS at my colo provider. It went some days before I was aware of the issue (it's a small site and I don't monitor the logs.) When I discovered the issue, I found a lot of mail in the queue, but few outright 5xx rejections had been done. Temporary rejections were occurring from numerous large providers, including Gmail, AOL, Yahoo, and Comcast. I temporarily shut down outbound mail and set up a relayhost while the provider fixed the rDNS issues (my PTR query was returning NXDOMAIN during this time.) Note, from the documentation suggested for you, that there are different conditions which trigger reject_unknown_client_hostname. Mine was lack of PTR, which also triggers the less aggressive reject_unknown_reverse_client_hostname restriction. This is fairly common, and IMO, a pretty likely spam sign. Given my experience, I think it is time to use reject_unknown_reverse_client_hostname. At least you know you're not alone in enforcing that policy. Another condition is when there is a PTR, but the name given does not resolve. This, too, is not unusual. But IMO it's probably less likely a spam sign. You might block a few sites where the understanding of DNS and mail issues is not so strong. A third condition is when the PTR name resolves to a different IP address. This is arguably the worst case, because it could mean that a spammer or scammer/spammer is trying to spoof a legitimate domain. IRL this is not usually the case; more likely just another poorly managed site. Most spam is going to come from malware-infected Windows machines or other compromised hosts being used as a zombie. There are many useful strategies in dealing with those, including Spamhaus Zen and reject_non_fqdn_helo_hostname. reject_unknown_reverse_client_hostname is also very effective, as I think some ISPs might deliberately not provide reverse DNS for their dynamic ranges. Most of the rest of it is going to come from large snowshoe ranges. These networks will typically have perfect FCrDNS for every IP address. It appears to be the third case here, that the name-address mapping does not match the client IP address. Could this be from a legitimate cause, or typically intentionally to be evasive? Could it be found in a legitimate dynamic environment, such as at an ISP? Is there a way to log these specific failures so I can get a better idea of under what circumstances they occur in my environment? I'm currently rejecting the following, in this order: reject_non_fqdn_sender, Reasonable, not going to block much; not likely to block any spam, but the mail it blocks is mail you should not accept anyway. reject_non_fqdn_recipient, Harmless but useless. reject_unknown_sender_domain, ditto reject_non_fqdn_sender reject_unknown_recipient_domain, Harmless but useless. Who is giving you invalid recipients at this point? reject_unauth_pipelining, Might catch some zombies. reject_invalid_hostname, Old syntax, ditto reject_non_fqdn_sender except might also catch a zombie here and there. reject_non_fqdn_hostname, Old syntax, very effective against zombies, safe and reasonable. reject_unauth_destination, (Necessary, no comment needed.) reject_maps_rbl, Old syntax, could be good or could be disastrous. Switch to the new syntax (new since Postfix 2.0 IIRC) of reject_rbl_client zone.name. At this point I'm only using zen.spamhaus.org, but I might be adding spameatingmonkey. Most important advice regarding DNSBLs is to be familiar with their policies and aware of their status. Given the dominance of ancient syntax in your restrictions, I wouldn't be surprised to see some dead lists among your maps_rbl_domains. :) -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Unknown senders and spam
Hi, reject_unknown_client_hostname : Is it common practice to have that restriction in a production environment? [...] Note, from the documentation suggested for you, that there are different conditions which trigger reject_unknown_client_hostname. Mine was lack of PTR, which also triggers the less aggressive reject_unknown_reverse_client_hostname restriction. This is fairly common, and IMO, a pretty likely spam sign. Given my experience, I think it is time to use reject_unknown_reverse_client_hostname. At least you know you're not alone in enforcing that policy. In this thread from just last June, the consensus was that it still rejected too much mail: http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html It was only from a few users, but wonder what their experience is almost a year later. In any case, I can't even test it, because apparently my postfix doesn't even understand warn_if_reject. It silently ignored it, and silently stopped accepting mail until I realized there were two hundred messages in the queue after five minutes on a Sunday :-) Most of it was spam anyway :-) Most spam is going to come from malware-infected Windows machines or other compromised hosts being used as a zombie. There are many useful strategies in dealing with those, including Spamhaus Zen and reject_non_fqdn_helo_hostname. reject_unknown_reverse_client_hostname is also very effective, as I think some ISPs might deliberately not provide reverse DNS for their dynamic ranges. Most of the rest of it is going to come from large snowshoe ranges. These networks will typically have perfect FCrDNS for every IP address. and you're saying the reject_unknown_reverse_client_hostname wouldn't help here, if I understand correctly? reject_maps_rbl, Old syntax, could be good or could be disastrous. Switch to the new syntax (new since Postfix 2.0 IIRC) of reject_rbl_client zone.name. Do you have any (postfix v2) restrictions that we haven't yet seen here that would be worth sharing for this topic? At this point I'm only using zen.spamhaus.org, but I might be adding spameatingmonkey. Most important advice regarding DNSBLs is to be I'm also using just those, and also considering bb.barracudanetworks.org to reject at SMTP time. How do you think it compares? familiar with their policies and aware of their status. Given the dominance of ancient syntax in your restrictions, I wouldn't be surprised to see some dead lists among your maps_rbl_domains. :) I'm somewhat familiar with those, but do you know of a location that describes the policies of the top five URI and DNS blocklists in one place? That would sure be useful. Thanks again for helping me to understand. Certainly upgrading is a top priority. Best regards, Alex
Re: Unknown senders and spam
On 4/18/2010 9:56 PM, /dev/rob0 wrote: reject_unauth_pipelining, Might catch some zombies. Note that with older postfix (postfix 2.6 IIRC) reject_unauth_pipelining must be used in smtpd_data_restrictions to be effective. It won't break anything in smtpd_recipient_restrictions, but it won't block anything either. reject_maps_rbl, Old syntax, could be good or could be disastrous. Switch to the new syntax (new since Postfix 2.0 IIRC) of reject_rbl_client zone.name. Using the old syntax is harmless[1] and still works; the new syntax was introduced for more flexibility. [1] harmless until some undefined point in the future when it's removed and no longer recognized. -- Noel Jones
Re: Unknown senders and spam
Hi, Note that with older postfix (postfix 2.6 IIRC) reject_unauth_pipelining must be used in smtpd_data_restrictions to be effective. It won't break anything in smtpd_recipient_restrictions, but it won't block anything either. Ah, great. I've moved it and it appears to be working (at least not complaining). Old syntax, could be good or could be disastrous. Switch to the new syntax (new since Postfix 2.0 IIRC) of reject_rbl_client zone.name. Using the old syntax is harmless[1] and still works; the new syntax was introduced for more flexibility. Will reject_rhsbl_sender and reject_rhsbl_client work in old versions? Thanks for being helpful and tolerant when I should be flamed for using such an old version. Thanks, Alex
Re: Unknown senders and spam
Hi, http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html It was only from a few users, but wonder what their experience is almost a year later. Yes, reject_unknown_client_hostname is still too strict for us. And we're very strict! Good to know. I also don't think I can easily make such a change in my environment. The warn_if_reject feature predates reject_unauth_pipelining, which you seem to be using successfully. I strongly suspect there was some other error -- probably a simple typo in your config -- that kept warn_if_reject from working for you. I'm trying to do: warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net But it appears that's only available in later versions, so I've tried this, and it also doesn't work: warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net 20020905 Feature: smtpd_data_restrictions = reject_unauth_pipelining It looks like I have a big project ahead of me to upgrade. What kind of process is involved with going from such an old version to the current, independent of all the other software? Thanks, Alex
Re: Unknown senders and spam
Alex(mysqlstud...@gmail.com)@Mon, Apr 19, 2010 at 01:11:01AM -0400: Hi, http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html It was only from a few users, but wonder what their experience is almost a year later. Yes, reject_unknown_client_hostname is still too strict for us. And we're very strict! Good to know. I also don't think I can easily make such a change in my environment. The warn_if_reject feature predates reject_unauth_pipelining, which you seem to be using successfully. I strongly suspect there was some other error -- probably a simple typo in your config -- that kept warn_if_reject from working for you. I'm trying to do: warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net But it appears that's only available in later versions, so I've tried this, and it also doesn't work: warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net You probably want: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net without the =. -- Bill Weiss We will not prove this by intimidation and excessive fist waving. [while screaming these lines and frantically waving arms] -- Dr. Max Mintx, Math. Foundations of CS University of Pennsylvania
Re: Unknown senders and spam
Alex a écrit : Hi, Is it common practice to have that restriction in a production environment? It appears to be the third case here, that the name-address mapping does not match the client IP address. Could this be from a legitimate cause, or typically intentionally to be evasive? since they put their domain name in their HELO (zaphod.chipchaps.com), they're not trying to evade anything. Yes, I guess they would have been rejected as a result of my helo checks. you could try check_client_access hash:/etc/postfix/access_unknown smtpd_restriction_classes = ... policy_strong policy_strong = reject_rbl_client bb.barracudacentral.org Is it possible to use maps_rbl_domains instead of reject_rbl_client here? with maps_rbl_domains, you can't specify which list to check in different places. since you're already using it in the general case, if you add barracuda list, it will apply unconditionally, which is different from my suggestion to call it when the clien is unknown. but if you think barracuda list is safe for you (it's not for me. the corresponding score in spamassassin confirms this for me), you can use it. It appears this machine has a version of postfix that doesn't understand reject_rbl_client. Thanks again! Best regards, Alex
Re: Unknown senders and spam
Alex a écrit : Hi, http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html It was only from a few users, but wonder what their experience is almost a year later. Yes, reject_unknown_client_hostname is still too strict for us. And we're very strict! Good to know. I also don't think I can easily make such a change in my environment. The warn_if_reject feature predates reject_unauth_pipelining, which you seem to be using successfully. I strongly suspect there was some other error -- probably a simple typo in your config -- that kept warn_if_reject from working for you. I'm trying to do: warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net wrong syntax. it's warn_if_reject reject_rbl_client $yourlist There's no 'equal' sign. But it appears that's only available in later versions, so I've tried this, and it also doesn't work: warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net doubly wrong syntax. besides the '=' sign, reject_rbl_maps doesn't take an argument. 20020905 Feature: smtpd_data_restrictions = reject_unauth_pipelining It looks like I have a big project ahead of me to upgrade. What kind of process is involved with going from such an old version to the current, independent of all the other software? Thanks, Alex
