[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: configuration inconsistency. MX usage forbidden..
> Damn..busy ;)
> Ok, behaviour I see, is that after a succesfull smtp connection (ehlo,
> mail from, rcpt to, data, quit) the mail is sent to the errorchannel with
Huh ?? That is, at first it presents a SUCCESS report,
and then it presents a FAILURE report ?
But it has done transmission ?
If all stack frames work ok, that report can happen only
when you have '-x' option in your smtp channel command line.
(That's why I suspect gcc ...)
> 19990412183904 /opt/zmailer/bin/ta/smtp: 77288/89//error2 smtp; 500
> (configuration inconsistency. MX usage forbidden, no address in the DNS:
> The address that is not in the DNS is the part after @ in the rcpt to
> command. It happens always, unless the domain after @ is a hostname and
> accepts mail.
Yes, and because I know that in my own case the emergence of
this report was with previously working CONFIGURATION at a host
which got installed with a new compiler, and I happened to want
to upgrade the version a bit, thus ending up recompiling the beast...
That is, when with unchanged config (without '-x'), I got that
error, became highly suspicuous about GCC-2.8.0 at SPARC (Solaris).
In the mean time the same source was working just fine at my PPro200,
and at my Alpha...
> Switching back to 188.8.131.52 works, but it isn't handy that gcc 2.8.0 doesn't
> do it right....Now how to fix that....
At this I do happen to believe at Bazar approach on the
software development. gcc-2.8.* has practically stopped
from developing in recent times.
> > I think it relates to optimization at SPARCs (or the particular
> > model of SPARC we have), and compiling without "-O" might produce
> > working binary. Could you care to try ?
> Doesn't make any difference.
Huh... (It could be the headers too)
> > Anyway, I use gcc-2.7.2, or egcs-1.1.2, or some vendor specific
> > compiler -- depending the platform...
> 184.108.40.206 works.
Given that egcs-1.1.2 does all kinds of magic flow optimization
things pretty well, I would like to recommend it instead of the
> Mark Visser / Calslaan 26-31 | E-mail: firstname.lastname@example.org
> 7522 MC Enschede / Telephone: 053-4895038 | SNT-mail: email@example.com
/Matti Aarnio <firstname.lastname@example.org>