TCPIP$GET_MX: getmxrr() failed
Phillip Helbig---remove CLOTHES to reply
TCPIP$SMTP_RECV_RUN.LOG:
getmxrr: name = 87.139.7.213])
getmxrr: res_search() failed
TCPIP$GET_MX: getmxrr() failed
I haven't changed anything in the configuration (in fact, I was on
holiday when it started happening---VMS fan that I am, I logged into my
cluster from an internet café in the south of France!). I've never seen
the error before. The address 87.139.7.213 is always the same. The
error messages are always exactly as quoted above. Everything else
seems to continue to work fine.
Any ideas?
Phillip Helbig---remove CLOTHES to reply
It also seems that EVERY TCPIP$SMTP_RECV_RUN.LOG has these lines.
JF Mezei
> getmxrr: name = 87.139.7.213])
> getmxrr: res_search() failed
> TCPIP$GET_MX: getmxrr() failed
Do you have any idea to whom this IP belongs to ? This part of a
Deutsche Telekom block. But it has no reverse transation. And it would
then become impossible to find the MX record since you can't find the
host name from the IP.
Is this the IP of a sender or your own IP ?
Phillip Helbig---remove CLOTHES to reply
<jfmezei...@vaxination.ca> writes:
> Phillip Helbig---remove CLOTHES to reply wrote:
> > getmxrr: name = 87.139.7.213])
> > getmxrr: res_search() failed
> > TCPIP$GET_MX: getmxrr() failed
>
> Do you have any idea to whom this IP belongs to ?
No.
> This part of a
> Deutsche Telekom block. But it has no reverse transation. And it would
> then become impossible to find the MX record since you can't find the
> host name from the IP.
>
> Is this the IP of a sender or your own IP ?
It's not my own IP nor is it the IP of anything I use (nameserver or
whatever).
P. Sture
Do you use Deutsche Telekom anywhwere? Or perhaps the question should
be, "Does your ISP use 'em?".
--
Paul Sture
Phillip Helbig---remove CLOTHES to reply
Sture" <paul.stu...@hispeed.ch> writes:
Yes. My ISP is 1&1. Legally, my internet connection has nothing to do
with Deutsche Telekom, but behind the scenes the DSL connection from 1&1
is a "resell" connection from Deutsche Telekom.
The question is, what does the error mean? And why the funny format
with "])" at the end? Since everything appears to be working, what
effects does the error have? Has anyone else seen this?
JF Mezei
>> > > Phillip Helbig---remove CLOTHES to reply wrote:
>> > > > getmxrr: name = 87.139.7.213])
> The question is, what does the error mean? And why the funny format
Well, it is pretty obvious: SMTP cannot obtain the mx record (DNS) for
ip 87.139.7.213
Is it alwasy the same IP mentioned ?
Is it always present no matter what the sender is ?
Is your mail routed to some forwarding SMTP server before getting to you
? Would that IP belong to that forwarding SMTP server ?
Phillip Helbig---remove CLOTHES to reply
<jfmezei...@vaxination.ca> writes:
> Phillip Helbig---remove CLOTHES to reply wrote:
> >> > > Phillip Helbig---remove CLOTHES to reply wrote:
> >> > > > getmxrr: name = 87.139.7.213])
>
> > The question is, what does the error mean? And why the funny format
>
> Well, it is pretty obvious: SMTP cannot obtain the mx record (DNS) for
> ip 87.139.7.213
Right. However, why the "])" at the end? Why does SMTP want to obtain
the mx record for this IP?
> Is it alwasy the same IP mentioned ?
Yes.
> Is it always present no matter what the sender is ?
Yes. It is in TCPIP$SMTP_RECV_RUN.LOG which doesn't mention the sender;
I would have to compare timestamps of these log files with entries in
OPERATOR.LOG, but since the error is always present, the answer is
"yes".
> Is your mail routed to some forwarding SMTP server before getting to you
> ? Would that IP belong to that forwarding SMTP server ?
No, mail comes in directly. (If there is a problem at my end, then
there are lower priority MX servers, but they are not neded now.)
Again, this started happening sometime last week and I have never seen
it before.
P. Sture
> > > > getmxrr: name = 87.139.7.213])
> > > > > getmxrr: res_search() failed
> > > > > TCPIP$GET_MX: getmxrr() failed
> > > >
<snip>
>
> Yes. My ISP is 1&1. Legally, my internet connection has nothing to do
> with Deutsche Telekom, but behind the scenes the DSL connection from 1&1
> is a "resell" connection from Deutsche Telekom.
>
> The question is, what does the error mean? And why the funny format
> with "])" at the end? Since everything appears to be working, what
> effects does the error have? Has anyone else seen this?
FWIW getmxrr is documented here:
<http://orange.kame.net/dev/cvsweb.cgi/sendmail/src/Attic/domain.c?cvsroo
t=apps&rev=1.2>
It looks as if garbage is being passed in the name field, but of course
that doesn't give us the why.
Note this bit in the source at the above URL:
----
case HOST_NOT_FOUND:
#if BROKEN_RES_SEARCH
case 0: /* Ultrix resolver retns failure w/ h_errno=0 */
#endif
/* host doesn't exist in DNS; might be in /etc/hosts */
----
Could it be picking up some garbage that has found its way into the
TCPIP SET HOST entries?
--
Paul Sture
Phillip Helbig---remove CLOTHES to reply
Sture" <paul.stu...@hispeed.ch> writes:
> In article <f6aiqf$ddl$1...@online.de>,
> hel...@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
> reply) wrote:
>
> > > > > getmxrr: name = 87.139.7.213])
> > > > > > getmxrr: res_search() failed
> > > > > > TCPIP$GET_MX: getmxrr() failed
> > > > >
> >
> > Yes. My ISP is 1&1. Legally, my internet connection has nothing to do
> > with Deutsche Telekom, but behind the scenes the DSL connection from 1&1
> > is a "resell" connection from Deutsche Telekom.
> >
> > The question is, what does the error mean? And why the funny format
> > with "])" at the end? Since everything appears to be working, what
> > effects does the error have? Has anyone else seen this?
>
> FWIW getmxrr is documented here:
>
> <http://orange.kame.net/dev/cvsweb.cgi/sendmail/src/Attic/domain.c?cvsroo
> t=apps&rev=1.2>
>
> It looks as if garbage is being passed in the name field, but of course
> that doesn't give us the why.
>
> Note this bit in the source at the above URL:
>
> ----
> case HOST_NOT_FOUND:
> #if BROKEN_RES_SEARCH
> case 0: /* Ultrix resolver retns failure w/ h_errno=0 */
> #endif
> /* host doesn't exist in DNS; might be in /etc/hosts */
> ----
>
> Could it be picking up some garbage that has found its way into the
> TCPIP SET HOST entries?
Again, this started happening last week. I hadn't changed anything for
a while before that, in particular, I hadn't change anything in the
local host database (which is small and looks fine). It's also been a
while since the last changed to the TCPIP software.
Phillip Helbig---remove CLOTHES to reply
(Phillip Helbig---remove CLOTHES to reply) writes:
> Again, this started happening last week. I hadn't changed anything for
> a while before that, in particular, I hadn't change anything in the
> local host database (which is small and looks fine). It's also been a
> while since the last changed to the TCPIP software.
Problem solved! It was a typo in SMTP.CONFIG (which I do update
relatively often) in a bad-clients entry!
I normally rely mainly on RBLs, but when I notice (I have the
corresponding console next to my main graphics terminal) repeated
rejections of a certain IP due to being in an RBL, I add the entry to
the bad-clients list to cut down on noise. (I noticed the typo because
I added 88.238.119.197 to the bad-clients list just now; today, there
have been 100 connection attempts from it. I just added 122.167.178.184
as well after several repeated attempts.)
This demonstrates one of the disadvantages of configuration files as
opposed to SET/SHOW commands: syntax errors are not caught early enough.
(In this case, the indication of a syntax error in the log file, instead
of the error indicated, would have at least helped to solve the problem
more quickly.)
By the way, since 1-JUN-2007 there are 28245 RBL rejections mentioned in
the operator log, but only 12 due to bad clients, at least 6 of the
latter being from today.
Phillip Helbig---remove CLOTHES to reply
Up from 12 to 22 now.
I'm assuming that it is more efficient in terms of resources to reject
stuff at the bad-clients stage as opposed to the RBL stage.
Phillip Helbig---remove CLOTHES to reply
typographical error in SMTP.CONFIG, why is STMP doing an MX lookup on
it? If the address is in the bad-clients list, then the connection
should just be dropped. As far as I can tell, the translation is not
reported in OPERATOR.LOG nor in the SMTP log files, so why bother with
the lookup at all?
True, the log files do occasionally say, e.g.,
Client IP address 85.103.243.252 unbacktranslatable (gethostbyaddr returned NULL)
(I'm NOT using this as a rejection criterion at the moment.) However,
if the address is in the bad-clients list, wouldn't it be better to just
drop the connection then and there, without doing further processing?
Especially considering the fact that addresses in the bad-clients list
are probably there because of repeated attempts.
Of course, it would be even better to reject stuff based on addresses
much earlier on. This is possible, but the number of such addresses is
limited. What is needed is something like the bad-clients list in
SMTP.CONFIG, but for TCPIP or even TCP (i.e. including UDP).
P. Sture
> In article <f6d50l$f0s$2...@online.de>, hel...@astro.multiCLOTHESvax.de
> (Phillip Helbig---remove CLOTHES to reply) writes:
>
> > Again, this started happening last week. I hadn't changed anything for
> > a while before that, in particular, I hadn't change anything in the
> > local host database (which is small and looks fine). It's also been a
> > while since the last changed to the TCPIP software.
>
> Problem solved! It was a typo in SMTP.CONFIG (which I do update
> relatively often) in a bad-clients entry!
>
Good.
> I normally rely mainly on RBLs, but when I notice (I have the
> corresponding console next to my main graphics terminal) repeated
> rejections of a certain IP due to being in an RBL, I add the entry to
> the bad-clients list to cut down on noise. (I noticed the typo because
> I added 88.238.119.197 to the bad-clients list just now; today, there
> have been 100 connection attempts from it. I just added 122.167.178.184
> as well after several repeated attempts.)
>
> This demonstrates one of the disadvantages of configuration files as
> opposed to SET/SHOW commands: syntax errors are not caught early enough.
> (In this case, the indication of a syntax error in the log file, instead
> of the error indicated, would have at least helped to solve the problem
> more quickly.)
Syntax checkers for config files seem to be common in the unix world. I
wonder if there's something suitable for the SMTP.CONFIG file.
> By the way, since 1-JUN-2007 there are 28245 RBL rejections mentioned in
> the operator log, but only 12 due to bad clients, at least 6 of the
> latter being from today.
I had 4 hours worth of RBL rejections for the same IP address yesterday.
I have "SPAM-Action: OPCOM, ACCOUNTING" in my SMTP.CONFIG, but no RBL
messages in operator.log (they were being broadcast to the console
though).
Does the ACCOUNTING specification mean that they don't go to
operator.log?
--
Paul Sture
P. Sture
My 4 hour attack yesterday was also doing a header enquiry on port 80.
Both SMTP and HTTP at the rate of 2 per minute.
I eventually did a TCPIP SET COMM/REJECT=NETWORKS=Ip-address
whoops - that defaults to a network mask of 255.0.0.0, so I blocked the
whole of 80.0.0.0. It stopped whatever was having a go in short order
though :-)
The IP concerned actually belongs to my ISP. If it happens again, and
I'm around at the time, I could drop the RBL check just long enough to
get more details and do a full report. With the information on hand
though, I have little to report.
--
Paul Sture
Phillip Helbig---remove CLOTHES to reply
Sture" <paul.stu...@hispeed.ch> writes:
> I had 4 hours worth of RBL rejections for the same IP address yesterday.
> I have "SPAM-Action: OPCOM, ACCOUNTING" in my SMTP.CONFIG, but no RBL
> messages in operator.log (they were being broadcast to the console
> though).
Why not?
> Does the ACCOUNTING specification mean that they don't go to
> operator.log?
I have OPCOM but not ACCOUNTING. They go to the console AND to the log
file.
Are you sure you looked in the OPERATOR.LOG for the node doing the SMTP
receiving?
JF Mezei
I woudln't worry too much about the ] since it could very well be part
of the "printf" statement instead of being part of the IP value. (But
could be either way).
Have you tried to enable the receiver tracing ?
$DEFINE/SYSTEM TCPIP$SMTP_RECV_TRACE 1
This *might* give you a better idea of the situation if the incoming
call goes anywhere with the receiver before that error is issued.
Do you have a router that logs incoming calls ? If you can associate
this error with the actual IP that is calling you, you might have a
better idea.
dav...@alpha2.mdx.ac.uk
>In article <43b64$46893609$cef8887a$14...@TEKSAVVY.COM>, JF Mezei
><jfmezei...@vaxination.ca> writes:
>
>> Phillip Helbig---remove CLOTHES to reply wrote:
>> >> > > Phillip Helbig---remove CLOTHES to reply wrote:
>> >> > > > getmxrr: name = 87.139.7.213])
>>
>> > The question is, what does the error mean? And why the funny format
>>
>> Well, it is pretty obvious: SMTP cannot obtain the mx record (DNS) for
>> ip 87.139.7.213
>
>Right. However, why the "])" at the end? Why does SMTP want to obtain
>the mx record for this IP?
>
connect to.
Could it be that someone is sending mail through your system to an address of
the form
user@[87.139.7.213]
which is a perfectly valid email address using a domain-literal and that
the DEC TCPIP SMTP software is mishandling this case and is trying to lookup
a MX record for [87.139.7.213] instead of just trying to connect to the server
at address 87.139.7.213
David Webb
Security team leader
CCSS
Middlesex University
P. Sture
> In article <paul.sture.nospam-2...@mac.sture.ch>, "P.
> Sture" <paul.stu...@hispeed.ch> writes:
>
> > I had 4 hours worth of RBL rejections for the same IP address yesterday.
> > I have "SPAM-Action: OPCOM, ACCOUNTING" in my SMTP.CONFIG, but no RBL
> > messages in operator.log (they were being broadcast to the console
> > though).
>
> Why not?
I was hoping you could answer that.
> > Does the ACCOUNTING specification mean that they don't go to
> > operator.log?
>
> I have OPCOM but not ACCOUNTING. They go to the console AND to the log
> file.
>
> Are you sure you looked in the OPERATOR.LOG for the node doing the SMTP
> receiving?
Yep. I am going to try with just "SPAM-Action: OPCOM" to see if that
makes a difference.
--
Paul Sture