Hi all,
we are using SIMS as our 2nd backup MX server, primary mailserver is CGP, 3rd backup server is at our ISP:
mail exchanger = 10 mail.tnt.be. (---> CGP server) mail exchanger = 50 backupmx.tnt.be. (---> SIMS server) mail exchanger = 100 relay.mx.skynet.be. (---> ISP server (sendmail))
At our ISP, it is set to deliver all mail to our SIMS server, to get some load of our primary CGP server:
Type static Nexthop backupmx.tnt.be
We see at lot of failed delivery attemts from our ISP's mailserver in the SIMS logs. When asking about this, this is what our ISP tech support replied:
"I looked at the logs of our backup MX server (relay.mx.skynet.be) and
there are lots of connection timeout errors, however when I telnet to your server
(backupmx.tnt.be ) everything works fine,
I think the timeouts must be after initial connect, I noticed e.g. backupmx.tnt.be
waits for 45seconds when it is unable to resolve a hostname (e.g. when I enter
helo skynet.be), this is no problem with mail.tnt.be, so I would check the
timeouts on backupmx.tnt.be and lower them if possible (most timeout on our
side are set at only 20sec, dns timeout is even 5s)."
Any idea why SIMS does this?
SIMS does a number of DNS lookups during the SMTP conversation, and they should only present a timing problem when the client is doing something really dumb like offering a HELO argument that fails by timeout (i.e. no server answers authoritatively about the name) or when the DNS config on the SIMS machine is bad. The latter can include problems like having an implied domain name configured, using a list of upstream resolvers that includes a dead machine or a MacDNS machine, or not having a fast resolver (at least a caching-only thing like the old free version of QuickDNS) on the same LAN (preferably same machine) as SIMS. If you have a lot of DNSBL's configured and some are dead or very slow you can see a slow start as well, but that should be seen on every connection before the initial banner.
What is odd is that the same should apply to the CGP system, but you are not having the same problems with it. The differences between the two machines' DNS setup could tell you the cause.
Can the timeouts be configured?
The advice you received on that is irrational, but the useful answer is 'No.' SIMS does not provide any way to shorten the timeout for DNS queries because the classic MacOS networking API offers no way to tune the timeout values for DNS queries.
On the Belgacom side they could set their timeouts for SMTP to something sane, which would likely solve your problem.
Any other solutions?
Drop that tertiary MX or get one from a competent provider. A 20 second timeout for any stage in SMTP is a bad idea for just about any sort of server, but for one that acts as a backup MX it is insane.
As long as your connection to the net and your own mail servers are reasonably reliable and don't fail in such a way as to leave you with no path inbound for many hours, that tertiary MX does nothing but provide a path for spammers to abuse. Any proper MTA trying to send you mail will try both of your machines before resorting to the Belgacom machine, and if that last resort did not exist they would keep retrying regularly for many hours before the sender would even get a warning back, much less a hard bounce. However, some spammers figured out some years ago that the best way to assure that their mail gets accepted in SMTP is to talk to the machines least likely to be able to confidently reject it, i.e. to play the MX standard rules in reverse.
-- Bill Cole [EMAIL PROTECTED]
############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
