Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: compsos on April 20, 2008, 08:31:59 AM
-
Hi
Logterse reports
2008-04-20 16:20:46.907013500 27954 logging::logterse plugin: ` xxx.xxx.xxx.xxx yyyyyy.lnk.telstra.net yyyyyy.com.au require_resolvable_fromhost 902 Could not resolve yyyyyy.com.au (#4.4.3) msg denied before queued
2008-04-20 16:20:46.909096500 27954 denysoft mail from <root@yyyyyy.com.au> (Could not resolve yyyyyy.com.au (#4.4.3))
2008-04-20 16:20:46.909960500 27954 450 Could not resolve yyyyyy.com.au (#4.4.3)
The domain DNS records report correctly with a dig yyyyyy.com.au A command.
I have disabled spamassassin DNSBL, but that made no difference.
Does anyone know of, or where I can find, a way of testing what logterse is failing to resolve?
Thank you.
-
The domain DNS records report correctly with a dig yyyyyy.com.au A command.
Does the dig command return a A or MX type record?
-
Does anyone know of, or where I can find, a way of testing what logterse is failing to resolve?
Logterse is just a plugin for qpsmtpd, and just "logs" information passed by qpsmtpd, so you really need to ask:
Does anyone know of, or where I can find, a way of testing what qpsmtpd is failing to resolve?
and in particular it is probably another plugin for qpsmtpd (which really only provides a framework) that you need to interrogate.
I suspect (but someone else ought to confirm), that it is a reverse DNS failure we are looking at here.
-
2008-04-20 16:20:46.907013500 27954 logging::logterse plugin: ` xxx.xxx.xxx.xxx yyyyyy.lnk.telstra.net yyyyyy.com.au require_resolvable_fromhost 902 Could not resolve yyyyyy.com.au (#4.4.3) msg denied before queued
2008-04-20 16:20:46.909096500 27954 denysoft mail from <root@yyyyyy.com.au> (Could not resolve yyyyyy.com.au (#4.4.3))
2008-04-20 16:20:46.909960500 27954 450 Could not resolve yyyyyy.com.au (#4.4.3)
...
Does anyone know of, or where I can find, a way of testing what logterse is failing to resolve?
It's not logterse, but require_resolvable_fromhost that does the DNS lookup. It's looking for either an MX record or an A record.
Because you have obfuscated your log snippet, nobody else can can investigate the DNS misconfiguration which is probably causing your problem. 'yyyyyy.com.au' probably has or did have a DNS configuration problem. The admins for that domain will need to fix it.
If you think that SME server software might be at fault, you should be raising the issue in the Bug Tracker, not here.
-
Thanks All
As for DNS records the dig command responds correctly.
A test email sent from the webmail on the system came through OK. It is the emailed log reports from the system that are being deflected. So my question is how to (if possible) understand what is happening to cause the log entry when dig commands work. Is it possible to issue a command from the console to test the domain the same way qpsmtpd seems to be doing it?
Charlie, I would raise a bug but I am inclined to agree that it is a fault elsewhere, so would like to undertake some more tests to confirm the cause of the problem.
-
As for DNS records the dig command responds correctly.
That's not sufficient. *All* DNS servers for the domain must return correct data.
Charlie, I would raise a bug but I am inclined to agree that it is a fault elsewhere, so would like to undertake some more tests to confirm the cause of the problem.
Suit yourself.
-
Thanks All
Seems to be solved.
I rechecked the DNS records for the sending system changed nothing and Saved.
Now all the emails are passing through. No change in the Dig results etc. It is on a Telstra (AU) DNS system where there is no simple reversedns setup. So the log is seeing the external IP of the sending unit and login name as the domain.It would have been good to be able to see the request from the mail servers "eyes" and see what it was rejecting.