[SpamCop-List] Re: several ISPs used by the same spammer (in the mail route)

[John E. Malmberg]

In article <d4aods$ffb$1 at news.spamcop.net>,
"Marinos J. Yannikos" <mjy at geizhals.at> writes:
> Hi,
>
> in this case:

The MX for your domain is mail.geizhals.at [213.229.14.34], which is claiming
to be morework.geizhals.at.  It's real publicname by rDNS is home.geizhals.at.

This means that we can trust the following lines:

>  >>Received: from kylie.netkey.at (unknown [83.64.50.180])
>  >>	by morework.geizhals.at (Postfix) with ESMTP
>  >>	for <webmaster at geizhals.at>; Thu, 21 Apr 2005 18:48:04 +0200 (CEST)

The server at 83.64.50.180 is misconfigured by a missing or bad rDNS according
to the header lines generated by your server.  For real mail, the text next
to the I.P. address should never be "unknown".

A check of the rDNS shows that it is claiming to be ns2.netkey.at.

ns2.netkey.at claims to be 62.218.147.30.

This is a serious misconfiguration on the sender's system.

A missing rDNS indicates an over 90% chance that the incoming e-mail is spam.
A bad rDNS like this indicates an over 80% chance that the incoming e-mail is
spam.


The name kylie.netkey.at can not be trusted because it was supplied by the
sending system and spammers can and do put anything there.

Many networks will not accept e-mail from systems misconfigured that way
because of the high probability of it being spam.  This does cause a bit of
real e-mail to be rejected because there are mail server administrators that
do not have correctly configured networks.

The above means that the parser does not really have a way to know if the next
header line is valid or not unless you are an administrator for
netkey.at or this is one of your mailhosts.

So the assumption would be that the netkey.at server is the source of the spam.

If the mail was really relayed externally from netkey.at, then it would have
to have gone through it's MX xena.netkey.at [83.64.50.179]

However it seems that kylie.netkey.at is also it's own MX.

But unless it is one of your mailhosts, spamcop.net does not have the
information needed to trust it.  And having the DNS records messed up makes
it even less likely to be trusted.

If this is one of your mailhosts you should talk to your ISP about this
configuration problem.

>  >>Received: from nitgofer.netkey.at (unknown [213.185.164.132])
>  >>	by kylie.netkey.at (Postfix) with ESMTP id 339326C299
>  >>	for <webmaster at geizhals.at>; Thu, 21 Apr 2005 18:48:04 +0200 (CEST)

If we take an unwarranted leap of faith that the e-mail actually did get
relayed through kylie.netkey.at:

The server at 213.185.164.132 is misconfigured by a missing or bad rDNS.
There is an rDNS of 132-164-185-213.customer.coltnet.at for it, but that name
does not resolve, so effectively there is no rDNS.

> a spammer sent e-mail from his access ISP (COLT) through one of his
> servers hosted at inode.at and then to us. The reporting web interface
> found only the administrators related to the COLT IP. I'm not sure if
> this applies: http://www.spamcop.net/fom-serve/cache/70.html ,

I do not see anything in the headers you presented to absolutely prove that.

It is just as likely that 83.64.50.180 has some security problem that is
allowing spammers to spam through it and put their fake header lines on it.

In either case though, it is either a severe security hole in the server at
83.64.50.180, or some authorized user of that server, so the administrator of
the domain for 83.64.50.180 is the one that can figure out if it is their
equipment or one of their clients that is the problem.

So based on what you have posted, who ever has responsibilty for 83.64.50.180
is the person that needs to investigate and fix the problem that is allowing
spam to be sent from that I.P. address.

If the server at 83.64.50.180 had it's DNS information properly configured,
then there might be more reason to trust it.  But if they can not get the
DNS right, which is really quite a simple configuration issue, how can someone
be sure that they got the server security correct?

> so I'll
> ask anyway - would it be possible to extend the parsing so that in case
> of matching verified domain names in several hops of the trace all used
> ISPs are notified of the spamming?

Domain verification is not what is needed.  What is needed is a trust of what
wrote the header lines that are being parsed.

Spamcop.net can trust that your mailserver/mailhosts put the right header
lines on, so it knows the I.P. your mail server or if you are using mailhosts,
(recommended) it knows where the spam was injected into your system.

> If this should be done already, what
> could be the reason for it not happening here? The e-mail contacts for
> the IP in the second hop was easy to find using "whois -r" and AFAIK in
> a standard format.

The problem is that the presence of a header line does not actually mean
anything at all.

Spammers routinely put in fake headerlines like that just to cause misdirected
LARTs to innocent ISPs.

Some spammers actually are trying to fool the spamcop.net parser into causing
the spamcop.net reporting server to flood an innocent domain with misdirected
LARTs.

Much of the spam that I have been reporting has fake header lines that are
trying to make it look like the spam came from a server managed by Outblaze.
Apparently the spammers are not happy with the anti-spam attitude of that
domain.

-John
wb8tyw at qsl.network
Personal Opinion Only