Unknown senders and spam
in [Postfix]
|
Prev: Question about bounce related spam
Next: Wanting incoming and outgoing e-mail montiroed for spam andvirii
From: Alex on 18 Apr 2010 23:24 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(a)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
From: Noel Jones on 18 Apr 2010 23:38 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
From: Noel Jones on 18 Apr 2010 23:55 On 4/18/2010 10:24 PM, Alex wrote: >> 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(a)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! But the cool thing about local email policy is that you get to decide for yourself what's too strict. Some people do use reject_unknown_client_hostname, but my impression it that they are mostly home/hobbyist/very small business. Rule of thumb: the more people you have to answer to, the less strict you must be. > > 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 :-) 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. From the (ancient) HISTORY file: 20011105 .... Feature: put "warn_if_reject" before an smtpd restriction, and that restriction logs warnings without rejecting mail. [...] 20020905 Feature: "smtpd_data_restrictions = reject_unauth_pipelining" blocks mail from SMTP clients that send message content before Postfix has replied to the DATA command. File: -- Noel Jones
From: Alex on 19 Apr 2010 01:03 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
From: Alex on 19 Apr 2010 01:11
Hi, >> http://www.mail-archive.com/postfix-users(a)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 |