6My typical set up — 2 email servers for all of my domains. One primary with local delivery, and another one as a backup MX. Then for all my other servers, MTA is installed but either bound only to localhost, or external access to port 25 firewalled. Emails will be sent out from these servers but they shall never receive any from emails, i.e. they are all null mailer. Just in case I mis-configured the MTA and opened them up for relaying, I firewalled all SMTP access.
Well, it has actually caused more problems than I have originally envisioned.
Maybe not a mistake from my end, but my action of deliberately blocking port 25 has actually prevent some mails to be sent when the aggressive filtering at the receiving MTA cuts in. A few users complained that they have not been able to receive emails from a forum I’ve set up, and this forum was hosted on a server with port 25 blocked. mailq shows there are actually some errors delivering emails to those email accounts, with status code:
451 Could not complete sender verify callout
A bit of analysis shows that all MTA on the failed domains run Exim 4.6x. So searching through the documentation on “callout” reveals a Exim-specific sender verification by making an SMTP connection back to the sender MX. From Exim docs:
40.36 Callout verification
For non-local addresses, routing verifies the domain, but is unable to do any checking of the local part. There are situations where some means of verifying the local part is desirable. One way this can be done is to make an SMTP callback to a delivery host for the sender address or a callforward to a subsequent host for a recipient address, to see if the host accepts the address. We use the term callout to cover both cases. Note that for a sender address, the callback is not to the client host that is trying to deliver the message, but to one of the hosts that accepts incoming mail for the sender’s domain.
Therefore, if the receiving end implements callout verification, MX of the sender’s envelope domain must be able to accept incoming SMTP connection. Note that it is not the From header of the RFC822 message, but the envelope address configured by mail server. Most my servers run Postfix and has $myorigin default to $myhostname — which resolves back to the null sender that does not have SMTP port accessible!
To fix it, I simply need to change $myorigin to $mydomain where there is actually a MX entry pointing to proper SMTP server. Otherwise, unblocking port 25 will always let the stalled emails flow through.
what’s the thinking behind a secondary MX, usually just gets you spammed if you don’t have configs setup identically etc.
Every MTA on the internet acts as a secondary MX and the moment the primary goes back up, the secondary server will hammer the living daylights out of the primary trying to shove mail down it’s throat.
The only way to do mail in this type of configuration is a mini-cluster with all the lovely high availablity/failover stuff.
I don’t get more spams when I brought up my secondary MX. Yes it is on the same greylisting + RBL setting as my primary.
Only if the secondary MX has no spam-prevention mechanism at all. There should be spam filtering far earlier than local delivery, i.e. at SMTP level. Sorry your assumption is flawed.
There is nothing wrong with my assumption, most people running secondary mail servers usually don’t have access to what accounts exists, so the server has to accept mail then reject it later, most secondary mail services usually doesn’t employ identically setup and configured spam/anti-virus solutions.
If you have configured things differently then most people that’s a good thing, however secondary mail servers are still a waste of time except if the primary is going to be offline for more then 5-7 days when remote MTAs will start dropping messages.
I would hope that all the MTA will spool the undelivered messages for 5-7 days! Then I don’t need to implement a secondary MX. Unfortunately it is not always the case :(
What servers have you seriously lost legit emails due to a few hours/days outage?
The only brokeness that most servers that are broken break over s greylisting.
Ref : http://blog.sysadminupdates.com/2007/11/19/sender-verify-call-out/ for more details in this error.