Comments on: Greylisting and a backup MX, the start of a problem ? http://switch.richard5.net/2006/11/29/greylisting-and-a-backup-mx-the-start-of-a-problem/ How to build your Mac into a internet server using open source software Tue, 17 Jun 2008 18:25:42 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: James Brown http://switch.richard5.net/2006/11/29/greylisting-and-a-backup-mx-the-start-of-a-problem/comment-page-1/#comment-8506 James Brown Sun, 03 Dec 2006 14:11:30 +0000 http://switch.richard5.net/2006/11/29/greylisting-and-a-backup-mx-the-start-of-a-problem/#comment-8506 Richard, I've had the same problem with my mail setup for ages now. Almost all email goes through the backup MX. We have always used our ISP as the backup MX. Unfortunately they do absolutely not spam filtering. I have now signed up for a backup MX and DNS service at Rollernet.us - http://www.rollernet.us/ From their web site: We offer the following configurable anti-spam options: * DNSBL (with optional custom lists) * Sender Policy Framework (SPF) (optional custom action handling) * Greylisting * Highly configurable blacklist and whitelist features * Inline anti-virus filtering * Configurable valid user list A lot of this is available on a free account, and you can upgrade the full-featured account for US$35/yr. Not bad when you consider that for this price you can have more than one domain. You'll still get some spam of course, but a lot less. Spammers often target the backup MX server directly. And apparently some go after the MX with the lowest priority (ie highest number in the MX record). So some people advocate having your real server as the highest and lowest priority MX - ie the mail server has two MX entries. I don't know how effective this is. Richard, I’ve had the same problem with my mail setup for ages now. Almost all email goes through the backup MX. We have always used our ISP as the backup MX. Unfortunately they do absolutely not spam filtering.

I have now signed up for a backup MX and DNS service at Rollernet.us – http://www.rollernet.us/

From their web site:

We offer the following configurable anti-spam options:

* DNSBL (with optional custom lists)
* Sender Policy Framework (SPF) (optional custom action handling)
* Greylisting
* Highly configurable blacklist and whitelist features
* Inline anti-virus filtering
* Configurable valid user list

A lot of this is available on a free account, and you can upgrade the full-featured account for US$35/yr. Not bad when you consider that for this price you can have more than one domain.

You’ll still get some spam of course, but a lot less.

Spammers often target the backup MX server directly. And apparently some go after the MX with the lowest priority (ie highest number in the MX record). So some people advocate having your real server as the highest and lowest priority MX – ie the mail server has two MX entries. I don’t know how effective this is.

]]> By: Jay http://switch.richard5.net/2006/11/29/greylisting-and-a-backup-mx-the-start-of-a-problem/comment-page-1/#comment-8139 Jay Thu, 30 Nov 2006 02:35:04 +0000 http://switch.richard5.net/2006/11/29/greylisting-and-a-backup-mx-the-start-of-a-problem/#comment-8139 Hey Richard, I've noticed the same problem regarding backup MX's and other situations. For example, I maintain an /etc/postfix/access file which reject's certain addresses within a domain that I have a catch-all assigned to. Of course, once the primary rejects with a 554 Access Denied, the sender sends to the secondary, where it rattles around for a while, eventually notifying the secondary MX's postmaster of its inability to deliver it. Luckily, I admin the secondary and was able to mimic the /etc/postfix/access file, but your point is very valid. Hey Richard,

I’ve noticed the same problem regarding backup MX’s and other situations. For example, I maintain an /etc/postfix/access file which reject’s certain addresses within a domain that I have a catch-all assigned to.

Of course, once the primary rejects with a 554 Access Denied, the sender sends to the secondary, where it rattles around for a while, eventually notifying the secondary MX’s postmaster of its inability to deliver it.

Luckily, I admin the secondary and was able to mimic the /etc/postfix/access file, but your point is very valid.

]]>