bl.spamcop.net blocks facebook.

Hi all,

I configured postfix to use this two "spam filter"

zen.spamhaus.org

bl.spamcop.net

this two servers are well know to work well togheter and they are famous to report really few false positive.

recently I noticed that they are catching more false positive,

spamcop now blocks facebook for example.

do you know some better server to block spam with false positive near to zero?

7 Replies

@sblantipodi:

this two servers are well know to work well togheter and they are famous to report really few false positive.
~~@www.spamcop.net:~~

The SCBL is aggressive and often errs on the side of blocking mail.
Spamcop is hardly famous for few false positives. zen.spamhaus.org is the only list I would recommend for low false positives.

If you want to lose legitimate emails at some point in time then you've done the right thing - adding an RBL to your mail server to immediately reject email.

Don't do this. You're relying on the owner/organisation of each RBL to be fairly cautious when blocking IPs. Maybe Facebook was a bit too spammy for spamcop and they legitimately blocked them for a reason - however you obviously don't consider Facebook to be an evil spammer (neither do I). However if your mail server is set to blindly trust those RBLs, you'll always get false positives.

Use a spam scanning filter which uses RBLs to filter email accordingly and remove them from Postfix. Try using amavisd-new with SpamAssassin enabled - by default it should come up with a list of RBLs it checks, you can always edit these if you want a different set with alternative scores if you trust a specific RBL more.

This way an email will get a higher spam score if the source of the message is from a blacklisted IP, but won't be immediately rejected. It gives SpamAssassin a chance to evaluate a message and see if the message is genuine spam if other RBLs say so, if all the other various rules make it look like spam - or if it's just a single RBL which is being overzealous in blocking certain IPs.

Don't use RBLs directly in your mail server unless you absolutely trust them.

@-Alex-:

If you want to lose legitimate emails at some point in time then you've done the right thing - adding an RBL to your mail server to immediately reject email.

Don't do this. You're relying on the owner/organisation of each RBL to be fairly cautious when blocking IPs. Maybe Facebook was a bit too spammy for spamcop and they legitimately blocked them for a reason - however you obviously don't consider Facebook to be an evil spammer (neither do I). However if your mail server is set to blindly trust those RBLs, you'll always get false positives.

Use a spam scanning filter which uses RBLs to filter email accordingly and remove them from Postfix. Try using amavisd-new with SpamAssassin enabled - by default it should come up with a list of RBLs it checks, you can always edit these if you want a different set with alternative scores if you trust a specific RBL more.

This way an email will get a higher spam score if the source of the message is from a blacklisted IP, but won't be immediately rejected. It gives SpamAssassin a chance to evaluate a message and see if the message is genuine spam if other RBLs say so, if all the other various rules make it look like spam - or if it's just a single RBL which is being overzealous in blocking certain IPs.

Don't use RBLs directly in your mail server unless you absolutely trust them.

yes yes, you are right, I always used amavisd-new with spamassassin but I tryed adding an RBL to block some more positive so I'm asking for a trusty RBL :)

@sblantipodi:

… so I'm asking for a trusty RBL …
If you must RBL directly, just use zen.spamhaus.org – it's conservative enough to not cause too many problems.

Before you add any postfix restriction to try and reduce spam, I highly recommend that you test it for a few weeks/months with the "warnifreject" feature of postfix.
~~@www.postfix.org:~~

warnifreject

Change the meaning of the next restriction, so that it logs a warning instead of rejecting a request (look for logfile records that contain "reject_warning"). This is useful for testing new restrictions in a "live" environment without risking unnecessary loss of mail.
Then you can review your logs and decide for yourself if the proposed restriction is useful and/or harmful in your own judgement.

@pclissold:

@sblantipodi:

… so I'm asking for a trusty RBL …
If you must RBL directly, just use zen.spamhaus.org – it's conservative enough to not cause too many problems.
I do this, and it works very well for my low-volume e-mail accounts. Checking for a lot of definitely-suspicious stuff before you ask Zen is a good thing, too. I think I stole this from a mailing list, and there's probably more and better ways to do some of this:

smtpd_recipient_restrictions = 
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_invalid_hostname,
    reject_non_fqdn_hostname,
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    reject_unknown_sender_domain,
    reject_unknown_recipient_domain,
    reject_rbl_client zen.spamhaus.org,
    reject_unauth_destination

thanks for all your replys.

I will follow your suggestion.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct