We’re a PA partner and have clustered Qmail with 4 servers + NFS storage. We’ve seen an issue where Qmail throws the following error:
failure: Sorry,_I_could_not_find_a_mail_exchanger_or_IP_address._(#5.4.4)/
This is a permanent error and means Qmail will not retry, the sender will receive an NDR (Non delivery reply / bounce back).
I’ve seen 3 causes so far that cause this error to appear with Qmail. Other MTAs like Postfix and Exim don’t have this issue.
1) CNAMEs as MX records and or there being no A record for the $domain.tld in the absence of an MX record.
2) smtp fixup is enabled on the cisco pix/asa firewall where the MX record resides.
3) The size of the returned DNS packet from the nameservers of the domain causes Qmail issues.
Our experience isn’t limited to these scenarios but they are the most common that we’ve seen.
As we manage quite a number of Cisco ASA firewalls and we have mixed MTAs behind them (qmail, exchange, postfix, exim etc) we always disable Ciscos smtp fixup. I’ve seen too many problems caused by it and it serves no use.
Parallels should take a leaf out of Postfix’s book as it actually detects this and performs a work around on the fly:
Jul 8 09:46:00 bk1-relay relay16/smtp[8773]: 21EDC39803E: enabling PIX workarounds: disable_esmtp delay_dotcrlf for hostname.domain.tld[74.xxx.xxx.xxx]:25
How do you detect if smtp fixup is enabled?
Easy telnet to the MX record on port 25 and if the 220 banner returned looks like:
Escape character is ‘^]’.
220 ***********************
then it is enabled. I’d advise the end user in question to disable this setting on their firewall(s).
We’re using the smtproutes fix for domains that refuse to fix their end and it works fine. This is normally located in:
/var/qmail/control/
or
/usr/local/qmail/shared/control/ (typically in clustered configurations)
If the file “smtproutes” doesn’t exist simply create it and you add the route like this:
$domain.tld:relay.domain.tld where relay.domain.tld is your non qmail relay server.
Recent Comments