Sandy Drobic wrote:

That is exactly what I am wondering about. Wouldn't it be better to be a bit more selective which IPs to block?

If you are using such aggressive blocks you might better use some restrictions that will block a lot of spam:

And should you just want to try out some these more aggressive restrictions, prepend 'warn_if_reject' to have a warning logged, but still accept the email.

If that is not sufficient to cut down spam to a comfortable level, then use a policy service and greylisting.

greylisting is probably by far the most efficient if you just want to get rid of spam. /Per Jessen, Zürich -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

On Thu, 2006-07-13 at 08:23 +0200, Per Jessen wrote:

David Rankin wrote:

...

217.0.0.0/8 REJECT You are unwelcome here...

You won't be getting much email from me then - we're on 217.8.216.8/29.

/Per Jessen, Zürich

But your mail, as far as the list is concerned, comes from the list server not you directly. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

On Thu, 2006-07-13 at 14:59 +0200, Per Jessen wrote:

Ken Schneider wrote:

...

On Thu, 2006-07-13 at 08:23 +0200, Per Jessen wrote:

...

David Rankin wrote:

...

217.0.0.0/8 REJECT You are unwelcome here...

You won't be getting much email from me then - we're on 217.8.216.8/29.

But your mail, as far as the list is concerned, comes from the list server not you directly.

So David will be getting mail from the SUSE mail/list-server, but still none directly from me :-)

Yes, mail you send to the list goes through the list server and is therefore seen as coming from the list server IP address even though the return address is yours. If you mail him off list (directly) then that is a different story. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

From: "Per Jessen" Ken Schneider wrote:

...

Yes, mail you send to the list goes through the list server and is therefore seen as coming from the list server IP address even though the return address is yours. If you mail him off list (directly) then that is a different story.

Thanks Ken - all I wanted to point out was that Davids restrictions are a little too restrictive IMO.

Thanks to all that weighed in. Yes, I know the restrictions are way-way-way too restrictive. I have a separate domain with a fixed IP and stand-by mail server attached to it that I am experimenting with to find out how best to control UCE. The only mail that goes to that domain is spam so if I did rcpostfix stop, it wouldn't make any difference. But I wanted to figure out a good approach to controlling UCE before implementing what works on the production machine. It has been quite fun, really, to learn what can be done with Postfix to address the UCE problem. But my time to devote to it is limited so my progress is slow. The smtpd_client_restrictions = check_client_access hash:/etc/postfix/client_check parameter is a very good tool for blocking the ranges of IPs that produce most of the spam and the restriction can be controlled to allow acces from within the excluded block. Take Per's example:

217.0.0.0/8 REJECT You are unwelcome here...

"You won't be getting much email from me then - we're on 217.8.216.8/29." In /etc/postfix/client_check, that can be addressed by: [root@bonza postfix]# cat client_check 217.8.216.0/24 OK 217.0.0.0/8 REJECT You are unwelcome here... So Per's part of the IP range would get through, but the rest would not. I'm still working on this. I'll conduct a test without the hash:/etc/postfix/client_check just using the reject_rbl_client relays.ordb.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org, reject_unknown_client and see how it works. Theoretically, the rbl lists should catch much of what I have rejected with the hash of client_check anyway. Thanks for your thoughts and advise. I'll keep you posted.... -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com -- -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

jfweber@gilweber.com wrote:

On July Thursday 13 2006 1:05 pm, david rankin wrote in an electronic and somewhat quixotic manner:

...

The smtpd_client_restrictions = check_client_access hash:/etc/postfix/client_check parameter is a very good tool for blocking the ranges of IPs that produce most of the spam and the restriction can be controlled to allow acces from within the excluded block.

Take Per's example:

...

217.0.0.0/8 REJECT You are unwelcome here... "You won't be getting much email from me then - we're on 217.8.216.8/29."

In /etc/postfix/client_check, that can be addressed by:

[root@bonza postfix]# cat client_check 217.8.216.0/24 OK 217.0.0.0/8 REJECT You are unwelcome here...

So Per's part of the IP range would get through, but the rest would not. I'm still working on this. I'll conduct a test without the

This will catch too many false positives on a production system and will require too much whitelist care to be effective unless your priority is on spam reduction.

...

hash:/etc/postfix/client_check just using the reject_rbl_client relays.ordb.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org, reject_unknown_client and see how it works. Theoretically, the rbl lists should catch much of what I have rejected with the hash of client_check anyway.

That is the idea, though the blacklists are much more selective and thus better tuned for the task.

...

Thanks for your thoughts and advise. I'll keep you posted....

Just curious why not drop the message instead of reject it????Once you do that the presence of your box is confirmed at that address, then w/ a bit more work <shrug> it winds up on someone's "todo" list when they may make a series of attacks to see if they can get any more info.. I would think that might be something you most especially wouldn't want to do w/ a box w/ a ( more or less) permanent address

You are mistaking "reject" with "bounce". With a reject during the initial smtp dialogue you only announce that you will reject the client. That does in no way say if the recipient address is valid or not. Most rejections happen because of bad helo/ehlo and the client address. There are more considerations for rejecting emails: - what will happen if you discard an email to a mistyped address? The sending server has logged that your server has accepted the mail, so you are the one who is responsible for losing the mail. - if you reject the mail the sending server has to notify the sender that the email could not be delivered. - Rejecting during smtp will greatly reduce the transfer traffic, since you don't accept the main body. In the worst case the cost is a few kB for a negotiated TLS connection. Definitely, mails you do not want to accept have to be rejected, mails you accept must be delivered, with the possible exception of virii. Everything else will lead to a lot of pain. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

On July Thursday 13 2006 2:46 pm, Per Jessen wrote in an electronic and somewhat quixotic manner:

david rankin wrote:

...

and stand-by mail server attached to it that I am experimenting with to find out how best to control UCE.

postgrey/greylisting. Granted, it does not take care of all of it, but it does stop a very large portion.

True, in the past two months there has been several articles on filtering spam as an "admin" necessity in Linux-Magazine (Pro) CHarly Kuhnast likes greylisting rather a lot.. but his last ( latest ) article seems to suggest the spammers may be trying to find a way round it.. ;( If you can get a copy of the July copy there were several suggestions by others to use sendmail ( for spam and even virii filtering?) in that edition. Perhaps you might find the article on their website by now. ( be certain to use the linux-magazine.com and not linuxmagazine.com they are two different magazines) -- j -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

david rankin wrote:

Do you have any favorite links to documentation on postgrey/greylisting? I'll google it, but if you have a favorite howto, I'd welcome the link... Thanks!

Sure - http://isg.ee.ethz.ch/tools/postgrey/ The basic setup is as follows: you run a postgrey daemon (postgrey is a perl-script) listening on some port, e.g. 10030. In your postfix setup (main.cf) you will have something like this: smtpd_restriction_classes = greylist [, ...] greylist = check_policy_service inet:saturn.local.net:10030 (My postgrey server is running on saturn.local.net) smtpd_client_restrictions = check_policy_server inet:saturn.local.net:10030 Greylisting is derived from blacklisting and works by temporarily rejecting all new clients (450 Please try again later) whilst accepting retries after a certain interval. Most spammers do not retry whereas most nonspammers do. /Per Jessen, Zürich -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

From: "Carlos E. R."

The Thursday 2006-07-13 at 12:05 -0500, david rankin wrote:

...

Take Per's example:

...

217.0.0.0/8 REJECT You are unwelcome here...

...

...

So Per's part of the IP range would get through, but the rest would not. I'm still working on this. I'll conduct a test without the

Yes, but you only know that you have to make that exception because he told you through a mail list. A person trying to contact you directly, without knowing that, would fail. I would be rejected, also.

In the end, you will be rejecting every body, because there are spammers everywhere.

Yes, And, I hate cutting off my nose to spite my face....... I have removed the check_client_access hash all together and the spam reduction is still great! My current setup is: smtpd_client_restrictions = reject_rbl_client relays.ordb.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org, reject_unknown_client smtpd_hard_error_limit = 3 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_access, reject_invalid_hostname, reject_non_fqdn_hostname smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_check.pcre unknown_client_reject_code = 550 unknown_local_recipient_reject_code = 550 The results: out of 218 spam messages that were sent to my server only 8 got through and 210 were rejected. That is a great, great improvement. This was without the hash table blocking entire ranges of IP address. I have only been informed of one false positive and that was due to sender header re-writing that was misconfigured. I like what I see. I'll look into the postgrey/greylisting and see if I can add another bit of protection. But catching 210 out of 218 is awesome. Thanks for all of your help!!!! -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com -- -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com