MX records and spam reduction

[LCPSWolf]

Hey all,

 

After searching the forums, I can't find anything that addresses this. I have a mail gateway set up that's running Ubuntu/Spamassassin/Amavis/ClamAV and it's great. My MX records are something like:

1 - mail gateway

2 - Exchange mail server

50 - bogus mail server

 

I'm attempting to prevent some spam from accessing our Exchange box by working its way back up the MX records in reverse order.

 

Can I just as easily relist my mail gateway at a lower priority as well, like this?

1- mail gateway

2- Exchange

5 - mail gateway

 

This way my SpamAssassin box will filter messages even from SMTP clients (spammers) that are going against the RFC and working up the MX list.

 

...and at this point I don't have the OK to take our Exchange server off the MX list totally - our SA install is too new to be trusted completely.

 

Thanks!

Damian

[LukeC64]

Hi Dude,

I am new to the forum but seen your message.

 

So you want all your mail to go though you ubuntu box first then on to your exchange?

 

The way we do it at the college is have two MX records to the spam filter box's then then get the spam box's to forward the emails to our exchange server which don't have any external MX just internal MX for internal app's.

 

Hope this helps.

[LCPSWolf]

LukeC64,

 

That's what I assumed would work. Once I am able to test our SA box well enough (and convince my boss) I hope to do just that. Thanks.

[LukeC64]

Cool, if you get stuck, give us a shout.

[LCPSWolf]

LukeC64,

No problems, just wanted to follow up. We did like you suggested, run to MX records for our 2 SA boxes, but left our Exchange box in DNS. We can change our external DNS records at any time, but there can be a 24 hour delay...so just in case we've left the Exchange MX, but blocked SMTP via our firewall. If for some reason we lost both SA boxes, we can unblock SMTP on our firewall and mail still gets in - without the 24 hour delay.

 

Thanks again!

[GrumbleDook]

If you are filtering then you should not have an MX record pointing directly at your exchange box at all. If you need give temp access to SMTP to point at your exchange box int eh case of failure of your SA boxes then use your firewall to NAT to the Exchange box instead of the SA boxes. This does rely on you using non-public address ranges internally though and NATing at your firewall ...

[LCPSWolf]

Tony,

 

That's simply brilliant I want to double check that it would work in our situation. Our DNS has our MX records listed by server name, as shown:

 

Should we instead be listing our external IP addresses here, to allow for the NAT to work how you describe?

 

It would provide additional options with fault tolerance, etc...

 

Thanks!

Damian

[GrumbleDook]

Ok ... fictional IP ranges coming up, please do not attempt to use them. Please take the following as examples. My public IP range would be 194.168.0.0/28 (194.168.0.0-194.168.0.15) with my firewall accepting connections on all IPs and doing NAT to internal IPs. My internal IP range is 172.16.0.0/22.

 

For the domain grumbledook.com I would have the following entries in the DNS

 

; zone fragment grumbledook.com

; mail servers in the same zone

; will support email with addresses of the format

; [email protected]

$TTL 2d ; zone default = 2 days or 172800 seconds

$ORIGIN grumbledook.com.

grumbledook.com. IN SOA ns1.grumbledook.com. root.grumbledook.com. (

2003080800 ; serial number

3h ; refresh = 3 hours

15M ; update retry = 15 minutes

3W12h ; expiry = 3 weeks + 12 hours

2h20M ; minimum = 2 hours + 20 minutes

)

IN MX 10 mail ; short form

; the line above is functionally the same as the line below

grumbledook.com. IN MX 10 ubuntu-spam.grumbledook.com.

; any number of mail servers may be defined

IN MX 20 ubuntu-spam2.grumbledook.com.

; use an external back-up

IN MX 30 mail.uunet.net.

; the local mail relay(s) need an A record

ubuntu-spam IN A 194.168.0.3

ubuntu-spam2 IN A 194.168.0.4

owa IN A 194.168.0.5

 

You firewall will the have a rule akin to

194.168.0.3 Port 25 > 172.16.0.3 Port 25 (which is your ubuntu-spam box)

194.168.0.4 Port 25 > 172.16.0.4 Port 25 (which is your ubuntu-spam2 box)

 

You SA boxes will receive all mail traffic and forward to the specified mail host within your local network, eg 172.16.0.5 ... the only public DNS record you are likely to need is the A record I included above for OWA ... and this would be locked down at your firewall as 194.168.0.5 port 443 > 172.16.0.5 port 443.

 

If your SA boxes fail then you change your firewall rule

from

194.168.0.3 Port 25 > 172.16.0.3 Port 25 (which is your ubuntu-spam box)

to

194.168.0.3 Port 25 > 172.16.0.5 Port 25 (which is your exchange box)

 

No DNS records need to be changed, one firewall rune is changed and you may have to edit your exchange config for where it can accept incoming mail from and where outgoing mail is routed to (presuming that you have outgoing mail going via your SA boxes too ... if these are offline then you set your exchange to route to you external mailhost or directly out via your gateway depending on your upstream ISP)

 

To be honest, the above applies to many email filtering setups and not just SA.

 

HTH

[GrumbleDook]

Apologies for some of the formatting above ... my DNS writing is a tad rusty ... MIT do have a good guide on this as do the NSA ... I will try and dig them out again.

[LCPSWolf]

Tony,

 

No problem for the formatting - I followed it. Let me see if I'm getting this OK. You're showing MX records for both SA boxes by name - makes sense to me.

 

Then you have A records that associate the SA box names to IP address. This will work regardless of whether the SA boxes are actually online, because that communication is being routed via our internal firewall.

 

Hence, even if a SA box (or both) fail, we simply reroute the external SA IP addresses to our Exchange's internal IP, and our mail is back on?

 

Sorry - I'm pretty new to DNS records - basically figuring this out as I go.

Damian

[GrumbleDook]

Yep, exactly what it is doing ...

 

If you want to look into DNS a bit more then I would seriously recommend DNS and BIND, Fifth Edition - O'Reilly Media as a brilliant resource.

 

Don't forget to check (and document) the changes that may be required on Exchange to receive / send mail too ... I am not an Exchange person but there are plenty on here who are.