HOWTO: Spam control for POSTFIX

[Turbanator]

Still major problems, I may need to setup the spamsnake gateway and/or sign up for gmail for business.

but before I do....I setup the spamtrap and tested it using 1 email from my yahoo.com email address. I sent a test email to a valid address and the spamtrap address in the same email (not cc. The email still got through to the valid address.

Can you explain how the trap is supposed to work? And I assume that if spam goes to valid addresses first and the spamtrap last, the trap won't catch anything, yes?

[crypted]

It worked on my old setup. But I see on newer stuff it doesn't work now, as you stated. I will research that.

Are most of these emails you have problems with also used on websites, forums, facebook (publicly viewable), and the like? Is there some way that multiple harvesters keep hitting them?

You could almost ban anything with an image in the body with a body_check.

[Turbanator]

it seems many aren't even image spam anymore. just simple spam that spamassassin thinks are negative value (so valid emails). I think the spamsnake gateway is my next try.

[crypted]

When I had negative values, they were still caught by the RBLs. Are you using those too?

[Turbanator]

yep, I have the same setup as you and same block lists. the spamtrap idea for sure isn't working though.

[crypted]

Make sure your main.cf has the RBL's I have:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination, check_policy_service inet:127.0.0.1:60000, reject_rbl_client zen.spamhaus.org, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client bl.spamcop.net, reject_rbl_client combined.rbl.msrbl.net, check_recipient_access regexp:/etc/postfix/spamtrap, permit

One RBL from the original HOWTO is defunct and might cause issues, so if you have an extra, remove it.

About the spam trap, it seems defunct now. Try http://blog.matws.net/post/2008/09/0...-1%3A-Spamtrap steps to do it their way. I'll play with that later today on if I get a chance.

[crypted]

Also, I wonder if there's some limitation where you cannot have more than one check_receipient_address in the main.cf string. I'm inclined to say no, or this ought to be working fine.

ISPC3 using mysql, so it has to have its check_recipient_address field. No way around that.

[Turbanator]

I had to take out reject_rbl_client dnsbl.sorbs.net due to it causing issues with some valid senders from aol. I added it back in just now. I'll review the other link you sent, thanx.

[Turbanator]

What about adding an SPF checker? Any downside?
http://www.webstershome.co.uk/conten...-spf-filtering

and Falko has a howto as well.
http://www.howtoforge.net/postfix_spf

[crypted]

Definitely not a downside. The only question will be whether SPF is utilized by domains where spam originates from. As the links discussion suggests, the spoofed email's "host" has to support SPF for it to be viable.

I read some Wikis a while back about SPF not being widely disseminated. That was the only reason I skipped it. If it helps, let me know so I can add it to the HOWTO?...