Christmas spam from RESERVED IANA adressblock ?

Mailman List Mirror (Read Only)
1

hello ladys and getlepersons

just out of curiosity i looked a bit closer into this spammail header, because
this company is really annoying and abusing a lot of internet citizens.

Anfang der weitergeleiteten E-Mail:

Von: mailling@ualadys.com
Datum: 24. Dezember 2008 12:30:18 MEZ
An: marc@let.de
Betreff: E-Mail For You @ ualadys.com
Return-Path: <www-data@web1.iispp.com>
Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Wed, 24 Dec 2008 12:30:25 +0100
Received: from mx2.iispp.com ([76.74.250.247]) by mx2.mail.vrmd.de with esmtp (Exim 4.69) (envelope-from <www-data@web1.iispp.com>) id 1LFRwW-00011o-DY for marc@let.de; Wed, 24 Dec 2008 12:30:25 +0100
Received: from web1.iispp.com (w1 [172.16.21.244]) by mx2.iispp.com (Postfix) with ESMTP id B71CF3504DB for <marc@let.de>; Wed, 24 Dec 2008 11:30:18 +0000 (UTC)
Received: by web1.iispp.com (Postfix, from userid 33) id A5C7917A405C; Wed, 24 Dec 2008 06:30:18 -0500 (EST)

„Whois“ wurde gestartet …

OrgName: Internet Assigned Numbers Authority
OrgID: IANA
Address: 4676 Admiralty Way, Suite 330
City: Marina del Rey
StateProv: CA
PostalCode: 90292-6695
Country: US

NetRange: 172.16.0.0 - 172.31.255.255
CIDR: 172.16.0.0/12
NetName: IANA-BBLK-RESERVED
NetHandle: NET-172-16-0-0-1
Parent: NET-172-0-0-0-0
NetType: IANA Special Use
NameServer: BLACKHOLE-1.IANA.ORG
NameServer: BLACKHOLE-2.IANA.ORG
Comment: This block is reserved for special purposes.
Comment: Please see RFC 1918 for additional information.
Comment: RFC 1918 - Address Allocation for Private Internets
RegDate: 1994-03-15
Updated: 2007-11-27

OrgAbuseHandle: IANA-IP-ARIN
OrgAbuseName: Internet Corporation for Assigned Names and Number
OrgAbusePhone: +1-310-301-5820
OrgAbuseEmail: abuse@iana.org

OrgTechHandle: IANA-IP-ARIN
OrgTechName: Internet Corporation for Assigned Names and Number
OrgTechPhone: +1-310-301-5820
OrgTechEmail: abuse@iana.org

# ARIN WHOIS database, last updated 2008-12-23 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

so how is this possible ?

merry christmas anyway

Marc

2

Hi,

It is private address space, like 10.0.0.0/8, completely valid for
internal communication which it appears to be.

Regards,
Steve

3

Lots of networks use RFC1918 space _internally_, as iispp.com obviously does between their webmail server and their SMTP relay. It's no more suspicious than your own ISP's use of 10.0.1 between their MX and the mailstore to which your message was delivered. Recognizing this is pretty basic to reading SMTP headers.

4

Do you put public IP addresses on every single device of yours? Or are some
devices configured with private ranges for internal movement (public
bridghead e-mail vs. internal databases?)

Or is everything internal private, and you simply NAT for public accessible
parts.

Seeing those addresses in the the e-mail header of an application is not an
indication of what is seen out on the 'Net. Just an indication of what that
specific device saw.

I would guess (hope?) that most, if not all, providers filter the RFC1918
space addresses from entering or leaving their networks unchecked. But just
my two cents there...

Scott

5

Asked and answered.

Regards,
Bill Herrin

6

All sites (not just providers) should, but many just don't do what they should.
In some cases it may not even be practical for people to do what they should
(due to poor software/hardware, or the poor availability of IPv4 addresses)

RFC1918 addresses should also never be found in mail headers of any
messages being exchanged over the internet.. For the very reason that it
creates this confusion. Another case of many implementations not doing
anything close to what they should.

RFC1918 says on page 4:
" Indirect references to such addresses should be contained within the
   enterprise. Prominent examples of such references are DNS Resource
   Records and other information referring to internal private
   addresses. In particular, Internet service providers should take
   measures to prevent such leakage.
"

Private IPs in mail headers are just fine inside the enterprise, but messages
with headers referencing private IPs should not be exchanged over the
internet.
RC1918 specifically says indirect references should not leave the enterprise.

The only thing that would be worse or more confusing to other sites would be to
not add a mail header at all, or to use a real IP address shared by other hosts
that use 1918 addresses on the LAN.

Mail servers that deal with internet mail should always add headers
that contain a distinct public IP address that belongs to that mail server,
for distinctively showing any abuse or mail server problem,
even if all access to that public IP is actually blocked by a firewall.

Not sharing mail server public IPs isn't part of the RFC1918 though,
it's just the right way(TM).

7

James Hess wrote:

RFC1918 addresses should also never be found in mail headers of any
messages being exchanged over the internet..

One need to understand the Received: headers and their order.

Private address space is perfectly legitimate. Very common in the early
part of transport and often seen in the last delivery in large
organisations that have multiple distributed SMTP servers.

What is important is for a recipient to know which Received: header he
can trust.

The only IP address you can trust are the one inside your own
organisation, and the IP address that sent the message to your
organisation. All other Received: headers below that to be considered
fake unless proven otherwise.

In the above case, it appears that the message arrived within the
organisation from a public IP address, and then was sent to another host
within the organisation via private address space.

It is also important to note that the topmost header was able to reverse
translate the 10.*.*.* IP which implies that it was internal to the
organisation, using an internal DNS server which makes it more
legitimate since it is within that organisation.

8

Maybe I'm showing my newb-ness here....

[snip]

RFC1918 addresses should also never be found in mail headers of any
messages being exchanged over the internet.. For the very reason that it
creates this confusion. Another case of many implementations not doing
anything close to what they should.

RFC1918 says on page 4:
" Indirect references to such addresses should be contained within the
  enterprise. Prominent examples of such references are DNS Resource
  Records and other information referring to internal private
  addresses. In particular, Internet service providers should take
  measures to prevent such leakage.
"

Private IPs in mail headers are just fine inside the enterprise, but messages
with headers referencing private IPs should not be exchanged over the
internet.
RC1918 specifically says indirect references should not leave the enterprise.

The only thing that would be worse or more confusing to other sites would be to
not add a mail header at all, or to use a real IP address shared by other hosts
that use 1918 addresses on the LAN.

So what are you suggesting an admin should do (assuming, for example,
he doesn't have enough IPv4 addresses to go around)? If he shouldn't
strip headers, and he shouldn't use the NAT'd addresses, then he's
running rather low on options.

And no matter what he does, it's going to involve modification of the
headers, which is generally considered A Bad Thing(TM). Especially
since some, not many, but enough, sysadmins are going to do the
modification badly, and either accidentally mangle the rest of the
email or do something to make tracking down problems more difficult.

I think a big difference between the example you quoted about RFC 1918
and Received: headers is that DNS records will be used by various
programs automatically, whereas mail headers are generally not; as JF
Mezei pointed out, all you have to do is learn to read mail headers
properly.

Not sharing mail server public IPs isn't part of the RFC1918 though,
it's just the right way(TM).

I didn't understand what you meant here... Not sharing my mail
server's public IP is going to make it a little difficult for me to
receive mail, I suspect...

9

James,

If you want to be dogmatic about it, the must and must nots in
RFC2821, 3.8.2 supersede the "should" in RFC 1918. The lines with the
1918 addresses must remain.

Pragmatically speaking, when you want to trace a spam, you have to
ignore both irrelevant information and intentionally false
information. For example, I've seen spams which contain Received lines
alleging receipt from a completely innocent network. You have to pay
close attention because the only clue that it's a lie is that the
Received line doesn't connect with any later ones. The system which
allegedly accepted the message doesn't appear in another received line
as having sent it to the next server in the chain.

As for the incident spam, there's probably an abusable web form on
www.iispp.com that some remote spammer has discovered and is using to
relay spam. When you see a message which appears to have originated
from a generic web server, that's often what's going on. This one has
that feel to it. Were it properly programmed, the form would have
appended a Received line of its own indicating the source of the http
request. Then again, if it was properly programmed it wouldn't be
useful for relaying spam in the first place.

Regards,
Bill Herrin