qmail problems - "Sorry, I couldn't find a mail exchanger or IP address. (#5.4.4)"

[IgorG]

As possible workaround, you may try to use qmail-remote from Plesk 10.1.1 - it does not have IPv6 support, but it is not affected by this bug.

 

[bradz]

New info?

Hi, I just upgraded a server to 10.2 with cento OS, I am now having the same issue.
I am not also not able to email my gmail address. Do we have a fix?
Brad

 

[bradz]

use qmail-remote from Plesk 10.1.1

How would I do this? Would I need to install version 10.1.1 by using the
# /usr/local/psa/admin/sbin/autoinstaller
thanks for any help!
Brad

 

[bradz]

DNS issue question

Hi now see that the server is not sending to gmail nor yahoo, so it seem to be a major issue, not just an issue with a few incorrect domains.

The one domain it will not send to is on a server I did not upgrade (still running 9.5)

For that domain, I have the following dns.

208.109.205.104 / 24 PTR snowridge.com.
ftp.snowridge.com. CNAME snowridge.com.
mail.snowridge.com. A 208.109.205.104
ns.snowridge.com. A 208.109.205.104
snowridge.com. NS ns5.zehrwoodartistry.com.
snowridge.com. NS ns6.zehrwoodartistry.com.
snowridge.com. NS ns.snowridge.com.
snowridge.com. A 208.109.205.104
snowridge.com. MX (10) mail.snowridge.com.
webmail.snowridge.com. A 208.109.205.104
www.snowridge.com. CNAME snowridge.com.

Do you see an issue with the above settings, do I need a change?
This would not help with yahoo or gmail, but I would still like to know if the dns setting are related.
thanks, Brad

 

[bradz]

IP solution

Hi, me again, server support suggested that I
change to use the relay server's Ip instead of it's host name.
I did this by using vi /var/qmail/control/smtproutes
The relay server's Ip was in my server control area under SMTP Service
I am now sending to gmail and hopefully others. Brad

 

[IgorG]

This issue will be completely fixed in Plesk 10.3 version.

 

[jola]

IgorG, thanks for looking into this. I think it is related to the new version of qmail used in plesk refusing to send emails to domains that have a DNS MX record that points to a CNAME. That is not standard compliant. However, many domains, including a few of my customer companies, do have this setup. You can solve it for a domain that you have already identified as broken by adding the problematic MX domain to /var/qmail/control/smtproutes. Then qmail avoids doing a real DNS lookup of this MX record, and thereby does not see the problem. This is not a solution though, just a fix for one problematic domain. In an ideal world you should ask everyone with a problematic domain to change their DNS MX setup. However, only sys-admins can do this and the problem affects many domains out there.

 

[darealhamsta]

All of that's already been stated in the thread, except for that fact that it /is/ standards-compliant -- MX records shouldn't point to CNAMEs, see RFCs 1034 and 1902. Unfortunately in the real world **** admins have set it up that way, including in large mail hosts, so well done to Parallels for recognising this and reimplementing the kludge.

 

[shortword]

We're a PA partner and have clustered Qmail with 4 servers + NFS storage. We've seen this from time to time and there are generally three causes.

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 ASA boxes 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.

Regards,

Paul

 

[henryweismann]

The temp fix by neoweo worked for me but this seems to be a hack rather then a fix. Also if the server changes the ip it will fail. The difference for us was this was happening for all emails being sent out. Does anyone know the correct fix for this? This thread has not been updaed in a while so I assume there is a fix? We are on 11.0.9. Thanks!