What's your anti-spam stack?

I use only Spamassassin (as before-queue Postfix filter).

With proper configuration works great.

my stack? google-apps

@chesty:

my stack? google-apps

A popular choice but I'm not keen on giving my personal data to a company that got rich by data mining other peoples' personal data.

This is my mail stack:
* Postfix

• Dovecot

• SpamAssassin (via spamass-milter, which I consider essential because it ensures spam is rejected early)

• SPF

• DKIM (using dkim-milter, soon to replaced with OpenDKIM)

• Postgrey (but only on some servers; my informal observation is that most spam which grey-listing stops would have been caught by SpamAssassin anyways; YMMV)

• BATV
  I don't check any DNSBLs from Postfix because SpamAssassin checks a bunch by default anyways.

Unfortunately, checking DKIM signatures doesn't stop any spam (it's more of an anti-forgery/anti-phishing solution). Since many legitimate senders don't use DKIM, you can't assume that mail without DKIM is spam. And since spammers can use DKIM, you can't assume that mail with DKIM isn't spam. That said, I do recommend you sign your outgoing mail with DKIM, since it helps with email delivery at places like gmail and Yahoo. You'd also be doing your part to help move the Internet forward towards a world where email forgery is impossible :-D. I recommend using OpenDKIM, which is a fork of the now-defunct dkim-milter (documentation for one should apply to the other).

100MB of RAM is about what my SpamAssassin stack is using too (and one of my 64 bit servers is using almost double that). It sucks but there's no alternative that's as comprehensive as SpamAssassin. Spamprobe is more efficient and I know people who speak very highly of it, but it only does Bayesian filtering. You could use Spamprobe for Bayesian filtering and check DNSBLs from Postfix, but you'd still miss out on many of SpamAssassin's other rules. The rumor is that Linode will be doubling all RAM soon, which would make 100MB much less painful.

I recently started using BATV to block backscatter. Unfortunately BATV is somewhat abandoned (despite some big players using it, like Amazon, UPS, and USPS) and I had to write my own implementation to get it to work decently (which I plan to open source very soon). BATV works wonderfully, but you might not want to bother unless backscatter is a problem. I only cared when I started getting dozens of backscatters a day.

Regarding Google Apps: My SpamAssassin setup blocks most spam from reaching my INBOX. I'm on the same group email aliases as some gmail users, and gmail regularly fails to block spam sent to these aliases, whereas SpamAssassin does fine. And I don't have a problem with false positives. My SpamAssassin config is not very customized, but I do train the Bayesian filter regularly. I drag false negatives into an IMAP folder called "Learn_Spam" and an hourly cron job feeds it to sa-learn. I think this is a large part of why SpamAssassin works so well for me. Although it takes a long time for the Bayesian database to train, in the long run it gives you an unparalleled spam filter.

I'm using only greylisting plus some of the built-in Postfix sanity checks. Also mail is only accepted for delivery to names that are specifically set up as aliases (no catch-all addresses or mail to accounts that aren't associated with real people).

local_recipient_maps = $alias_maps                                              

smtpd_client_restrictions =
    permit_mynetworks,
    permit

smtpd_helo_required = yes

smtpd_helo_restrictions =
    permit_mynetworks,
    reject_non_fqdn_helo_hostname,
    reject_invalid_helo_hostname,
    permit

smtpd_sender_restrictions =
    permit_mynetworks,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    permit

smtpd_recipient_restrictions =
   reject_unauth_pipelining,
   reject_non_fqdn_recipient,
   reject_unknown_recipient_domain,
   permit_mynetworks,
   reject_unauth_destination,
   reject_unlisted_recipient,
   check_policy_service unix:postgrey/socket,
   permit

IMO, the goal is to reject spam during the SMTP transaction. Once you've accepted a message for delivery, your options are to deliver it to the user (bad if it's spam), throw it away (bad if it's not spam), or generate a bounce message (possibly generating backscatter spam).

If I were to add anything, first would be a DNSBL, probably Spamhaus. SpamAssassin would be one of my last choices because of memory consumption (with 8 cores now, CPU is probably less of an issue than it once was). SpamAssassin can do your SPF and DKIM checks, so if you're running that I wouldn't use a separate utility for those.

Spam is a bit out of control even though I have the following implemented, some from this post, anything I can do to have to deal with less in my inbox?

# Client restrictions: #
smtpd_client_restrictions = 
    permit_sasl_authenticated,
    reject_non_fqdn_helo_hostname

# HELO restrictions: #
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
#    reject_non_fqdn_helo_hostname,
    reject_invalid_helo_hostname,
    permit

# Sender restrictions: #
smtpd_sender_restrictions =
    permit_mynetworks,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    permit

# Recipient restrictions: #
smtpd_recipient_restrictions =
   permit_sasl_authenticated,
   reject_unauth_pipelining,
   reject_non_fqdn_recipient,
   reject_unknown_recipient_domain,
   permit_mynetworks,
   reject_unauth_destination,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client bl.spamcop.net,
   permit

Also have Spamassassin running, it tags things as spam, but I still have to deal with deleting each one manually. So far it has marked no legit email as spam. I feel spamassassin is kinda pointless at this point as I can determine my self from the subject if it is spam without spamassassin placing SPAM in subject. Should spamassassin be automatically deleting emails past a certain score?

Looking for more ways to reduce spam if possible…

@jgjh151:

Also have Spamassassin running, it tags things as spam, but I still have to deal with deleting each one manually. So far it has marked no legit email as spam. I feel spamassassin is kinda pointless at this point as I can determine my self from the subject if it is spam without spamassassin placing SPAM in subject. Should spamassassin be automatically deleting emails past a certain score?

Most people setup some kind of filter rule to put messages tagged as spam in a different mail folder to be checked when they are really bored.

You can delete mails with a high spam score if you wish but it's better to just filter them off somewhere for future checking.

You can do filtering on your imap server or in your mail client depending on what software you use.

Spamassassin (via spamd/spamc) and ClamAV work well here. I also have Postfix's helo checking active (no friends with mal-configured servers – I'd yell at them to fix it anyways). Fairly minimal, but caught some Craig's List spam that Gmail missed :wink:

I don't do any fancy stuff beyond that.

To elaborate slightly on "some kind of filter rule," how this is done depends on what mail delivery agent you're using. If it's Dovecot's LDA or LMTP, you can use its Pigeonhole Sieve interpreter and filter based on the X-Spam-Flag or X-Spam-Level headers added by Spamassassin. Another common delivery agent is procmail, where you could match on X-Spam-Status as described or on X-Spam-Level with the number of asterisks representing the message's spam score (note that the match is a regular expression so you'll need to escape asterisks).