Martyn Drake martyn@drake.org.uk writes:
bjsamuels@beenthere-donethat.org.uk wrote:
After reading my ISP's instructions about running an SMTP mail server, in double-dutch of course ("A" records ???), it all sounds a little daunting. I already run Postfix locally if that has any bearing on the subject and I don't, as far as I know, run a DNS server locally.
What advantages would this give?
Fewer points of failure (i.e. you've eliminated a mail provider's mail server from the equation.).
Fine grained control over what mail you accept. A double-edged sword; you *can* do your own spam filtering, but unless you are very lucky or very tolerant, you will *have* to do your own spam filtering.
If you're going to run a mail server at home, I'd highly recommend an external (preferably on a completely different network to your ISP) secondary MX provider to hold your mail in case your ADSL line dies horribly without warning.
I would recommend against it, based on my experience.
It's not *necessary*, in the that the only mail you might lose because you didn't have a backoff MX you'd be at risk of losing no matter how many backoff MXs you had.
It definitely adds another point of failure: if your backoff MX accepts a message and then falls over you're in a worse position than if it was queued on the sending site's mail server for a while.
It increases the number of things not under your own administration that the reliability of your mail depends upon. (I think it was Martin Keegan who defined an enemy mail system as one you did not control, and I think there is a lot of truth to this.)
Additionally it might prove quite inconvenient if you're doing you're own spam filtering.
For instance, if you want to include the origin IP address as part of the filter, you'd have to fish it out of the Received: field. (Preferentially using backoff MXs is a spammer trick for getting around IP-address-based access control.)
A second spam-related problem is that rejecting at RCPT or DATA means that the backoff MX has to generate a bounce, which (since spam often has a forged return path) may go some innocent third party, who doesn't deserved to have their mail clogged up with it. Without the backoff MX the handling of the error response to RCPT/DATA will be much closer to the sender of the mail who is in a better position to do something sensible with it (and this is a general advantage to avoiding the backoff MX, rather than a spam-specific one, really).