On Thu, Mar 18, 1999 at 01:27:09PM +0100, Harald Hanche-Olsen wrote:
> - torben fjerdingstad <[EMAIL PROTECTED]>:
>
> | The problem.
> | I have, too many times, seen mail.isp.dk reject mail to
> | my customers domains with the following error:
> |
> | "Sorry. Although I'm listed as a best-preference MX or A for that host, "
> | "it isn't in my control/locals file, so I don't treat it as local. (#5.4.6)"
> |
> | The error message above contains two statements:
> | My customers domain names are not in control/locals. That is true.
> | Our mail relay is listed as the best-preference MX. That is wrong.
>
> Have you tried running dnsmxip (in the qmail source directory) against
> the customer's domain?
No. I had not noticed that utility. I used nslookup -q=mx <domain>
which appears to be equivalent.
> | I cannot imagine that DNS can claim our mail server to be the best
> | MX for our costomer's domain, which it is not, and never has been.
>
> Do you control the authoritative DNS server for the customer's domain
> yourself? Could it be that someone occasionally screws up the name
> server, actually rendering your server the best MX? Apart from that,
> and the possibility that you have a buggy name server around, I see no
> reason why you should get the behaviour you describe.
No. In the cases I remember DNS was delegated to the customer's
name server. I run the ISP's nameserver so I am used to check DNS.
I could not find any error in DNS for the customer's domains.
> | DNS says (made up names):
> |
> | customer.dk. <--- customer's zone
> | IN MX 10 mail.customer.dk. <-- customer's server
> | IN MX 20 mail.isp.dk. <--- Our server
>
> As it should be.
>
> | Testing is difficult because I can only send mail from our networks,
> | so rcpthosts is never consulted. Testing from outside is possible
> | using telnet, but I don't have a shell account on the outside.
>
> Like I indicated, there is always dnsmxip. And you can telnet
> directly to your server's SMTP port and try a few mail from: and rcpt
> to: commands.
Hmmm.. you are right. Right now it seems to work as it should
without a rule in smtproutes.
I think I will try to remove some more of those smtproutes and wait
to see what happens. Strange. I have seen my problem for at least
3 quite differens receipient domains, where DNS looked fine.
There might have been a transient DNS error, but that should not
give a hard error, I think.
Thanks.
--
Med venlig hilsen / Regards
Netdriftgruppen / Network Management Group
UNI-C
Tlf./Phone +45 35 87 89 41 Mail: UNI-C
Fax. +45 35 87 89 90 Bygning 304
E-mail: [EMAIL PROTECTED] DK-2800 Lyngby
