# Postfix SpamAssassin 2ndary MX relay configuration Question

## Philippe23

I've run a small server with postfix and spamassassin for a while.  It's been the only MX record for a long time.  A little while ago, I thought I'd try to set up a separate small server to be a backup MX.  I have it setup to only accept mail for my domains and forward them on to the main server.

The problem I'm running into is that the mail this secondary MX passes along looks more legit to the main server once it runs spamassassin on the incoming mail.

What's the proper way to set this up?

Note: The backup MX doesn't know what accounts/e-mail addresses are good or bad.  (Just what domains it is allowed to accept mail from.)[/u]

----------

## cach0rr0

 *Philippe23 wrote:*   

> 
> 
> The problem I'm running into is that the mail this secondary MX passes along looks more legit to the main server once it runs spamassassin on the incoming mail.

 

Can you expand on/clarify this a bit? 

Is it that spam is more easily slipping through because it's hitting the backup MX? 

I ask, for a handful of reasons:

-spammers will very frequently and very intentionally try MX records with the numerically highest priority *first*, with hopes that it's a backup MTA that has a lesser level of content filtering. If you have a backup MX, spammers will prefer it. 

-when something like spamassassin looks at a message coming from your backup MX, the topmost "Received" header will, instead of having data from a spammer, have data from your perfectly legitimate Postfix server. As far as it's concerned, your backup MX was the original source of the email (which isnt *entirely* true, but from the perspective of how the filters work, that's how it's seen). In addition, any DNS-based IP blacklists that you may have enabled on your primary MX, that are probably doing a very decent job, are going to be neutered, since the connecting IP will be your secondary MX and not that of some spambot in Romania. Basically, no matter what your filter, whether a commercial filter or spamassassin, having mail go through a legitimate hop before it reaches your spam filter WILL affect your catch rate. 

The long and short of how to solve that, if indeed that's your question, is this: if it can be contacted from the outside world, it should have just as much filtering enabled as your primary MX. At the very least put a few reliable low-false-positive RBL's onto your backup MX (cbl.abuseat.org, b.barracudacentral.org, ix.dnsbl.manitu.net, and new.spam.dnsbl.sorbs.net, are all very low risk, and the first three give a very good hit rate).

----------

## Philippe23

 *cach0rr0 wrote:*   

> Is it that spam is more easily slipping through because it's hitting the backup MX?

 

Yes, exactly.  (Or at least that's my belief.)

 *cach0rr0 wrote:*   

> -spammers will very frequently and very intentionally try MX records with the numerically highest priority *first*, with hopes that it's a backup MTA that has a lesser level of content filtering. If you have a backup MX, spammers will prefer it. 

 

I have a 3rd MX record that points at an IP with no mail server in hopes of dealing with this.  (But it's good to hear you say it too.)

 *cach0rr0 wrote:*   

> The long and short of how to solve that, if indeed that's your question, is this: if it can be contacted from the outside world, it should have just as much filtering enabled as your primary MX. At the very least put a few reliable low-false-positive RBL's onto your backup MX (cbl.abuseat.org, b.barracudacentral.org, ix.dnsbl.manitu.net, and new.spam.dnsbl.sorbs.net, are all very low risk, and the first three give a very good hit rate).

 

Sigh.  I think that's what I'm doing (from the backup's config):

```
smtpd_recipient_restrictions =

#       check_client_access hash:/etc/postfix/helo_client_exceptions,

#       check_sender_access hash:/etc/postfix/sender_checks,

        reject_invalid_hostname,

#       permit_sasl_authenticated,

        reject_non_fqdn_hostname,

        reject_non_fqdn_sender,

        reject_non_fqdn_recipient,

        reject_unknown_sender_domain,

        reject_unknown_recipient_domain,

        permit_mynetworks,

        reject_unauth_destination,

#       check_recipient_access hash:/etc/postfix/rcpt_classes,

        check_client_access hash:/etc/postfix/rbl_client_exceptions,

        reject_rbl_client cbl.abuseat.org,

        reject_rbl_client sbl-xbl.spamhaus.org,

        reject_rbl_client bl.spamcop.net,

        reject_rhsbl_sender dns.rfc-ignorant.org

#       permit

```

Although I'm glad you posted the suggested RBL servers.  I was just wondering this morning if these are outdated.

Where do you suggest finding new RBL servers?  I'm pretty sure I just copied this from an example someplace.

P.S.  Thanks for your help!

----------

## cach0rr0

I'm dropping them off at the connection level actually, rather than waiting for RCPT

doing so, this is what I've got

```

smtpd_delay_reject = no

smtpd_client_restrictions =

        permit_mynetworks

        reject_rbl_client ix.dnsbl.manitu.net

        reject_rbl_client cbl.abuseat.org

        reject_rbl_client b.barracudacentral.org

        reject_rbl_client new.spam.dnsbl.sorbs.net

```

far as Spamhaus SBL-XBL - do they still have that up? they were going to do away with it, in favor of (what was then new) zen.spamhaus.org, which included sbl, xbl, and the pbl. 

For my money theyre not as great about false positives. Theyre not as bad as spamcop, but for anything where im not exceptionally confident, i do post-acceptance filtering. 

Using abuseat and sbl-xbls is, theoretically superfluous, since the latter includes the former, but it doesnt always work out that way. Since abuseat has a sane delisting policy, sane inclusion policy, and a low incidence of false positives, i trust them as a pre-queue filter. 

the manitu and barracuda list have done me really well for the stragglers, and that limited sorbs zone every once in a while picks up some the others miss. 

Trick is, if you dont already, id put this in play on both primary and backup node. No weak links!

Anyway, this comparison has been around for a good bit, and while ive not always agreed with it *exactly*, it gets a "close enough" for me - http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html

andddd ill actually re-read what ive written once im not typing it over fried rice - anyone's guess how applicable it is

----------

## cach0rr0

re-read

ok

so how are you deploying spamassassin? is it deployed on the backup MX as well, or is it deployed in such a way on the primary MX that it isnt feasible to do the same way on the backup? 

Trick is, spamassassin suffers greatly when it doesnt have fresh headers to look at - fresh as in, just tacked on. 

For example, SA has rules to check the PTR stamp in a Received header, and see if it matches common patterns for dialup/dynamic residential broadband accounts. Now, if the most recently-added Received header matches this, that would be something that would be a relatively strong indicator of spam. But if it's 3 or 4 down the chain, it's absolutely meaningless, as a residential broadband customer connecting to their ISP's outbound MTA to send mail would have such a header. That's why a good chunk of the RBL's advise against "deep header parsing" as they call it. Well, that's one of the reasons they advise against it. 

In your situation if I had to do something, I'd freshen up my RBL's, and toss SA on in a way that it just junked the "high confidence spam" messages, while relaying anything questionable to your primary MX. 

hmph. this is yet another reminder i need to get off my ass and write a frontend - inclusive of a quarantine system - that handles all of this.

Anyway, start with freshening the RBL's. If still unacceptable, give a shout, plenty of other things to be done.

----------

## Philippe23

Okay, so I've updated the RBLs on both servers.  We'll see if that does better.

SpamAssassin is run via procmail on the main server and has the "learning" enabled per account, along with individual user's configs doing whitelisting.  If the stuff keeps coming though, I'll look into how to hook up SpamAssassin on there.

Thanks for the comparison page link.  I'll keep that around to update my list every once in a while.  I'm pretty sure half the RBLs you mentioned don't exist anymore, but since they're DNS lookups I guess I haven't noticed any errors....

Thanks again.

----------

