The Internet Assigned Numbers Authority (IANA) has reserved the
   following three blocks of the IP address space for private internets:
     10.0.0.0 - 10.255.255.255 (10/8 prefix)
     172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
     192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Someone has done an Apnic registration for rfc1918 private IP space.
What this has to do with solving spam problems is still a mystery to
me...unless someone is suggesting spammers (or perhaps all of Korea)
should be assigned non-routable IP space.
...unless someone is suggesting spammers (or perhaps all of Korea)
should be assigned non-routable IP space.
Funny you should mention that. I got so fed up with both the US spam
bouncing off Korean relays and the parallel flood of spam originating
in Korea (in Korean, with URLs advertising Korean stuff ranging from
appliances to dating services to bionic shoe inserts), combined with
the fact that I'd never gotten any response to the buckets of abuse
reports I'd sent off to Korean ISPs, that I stopped accepting any mail
from Korea at all.
I know it's indefensible in principle, but even though I have books in
Korean translation, I get no real mail from Korea so the collateral
damage is for me is imperceptible. The rejection message includes a
URL which explains why I don't receive mail from Korea, with an
unblocked address to which one can write to get their network off the
list. Needless to say, nobody's written. The list contains all APNIC
space assigned to Korea, plus any Korean ARIN space that's come to my
attention due to getting spammed from it.
If you'd like to experiment with a Korea-free mail system, you're
welcome to use my blocking list called korea.services.net. I announced
it on a few anti-spam lists last week and it's now getting about three
hits per second. You can't do zone transfers, it's running rbldns, not
bind, but if you use it a lot, we can figure out a way for you to
get your own copy of the data.
In case it's not obvious, I have nothing against Korea or Koreans
except that their enthusiasm for wiring the country for Internet
connections has so far severely outstripped their ability to manage
what they've built.
I know it's indefensible in principle, but even though I have books in
Korean translation, I get no real mail from Korea so the collateral
damage is for me is imperceptible. The rejection message includes a
It's not indefensible (I assume this policy applies to you personally, and is
not being applied to your customers). I arrived at the same conclusion some
time back, and just modified my procmail setup so that any mail originating
from .kr that hadn't already been caught by one of my list filters got sent
to /dev/null. No defense is really necessary - it's your mail, and you don't
have to accept anything from anybody you don't want to. And you certainly
don't have to justify it to anybody. (regardless of fumings from the pro-open
relay crowd out there ...)
URL which explains why I don't receive mail from Korea, with an
unblocked address to which one can write to get their network off the
list. Needless to say, nobody's written. The list contains all APNIC
I like that feature; I'll have to incorporate it into my own setup. That
takes a bit of the B out of my (admittedly) BOFH setup.
space assigned to Korea, plus any Korean ARIN space that's come to my
attention due to getting spammed from it.
I like this too - filtering on IP as opposed to domains listed in mail
headers would be much more effective.
If you'd like to experiment with a Korea-free mail system, you're
welcome to use my blocking list called korea.services.net. I announced
it on a few anti-spam lists last week and it's now getting about three
hits per second. You can't do zone transfers, it's running rbldns, not
bind, but if you use it a lot, we can figure out a way for you to
get your own copy of the data.
Since it's just for me personally, I probably will just look and learn.
In case it's not obvious, I have nothing against Korea or Koreans
except that their enthusiasm for wiring the country for Internet
connections has so far severely outstripped their ability to manage
what they've built.
Close - the object in question appears to be in the KRNIC database, which
is one of the databases that you can search through the APNIC Whois
server; it is not an object in the APNIC database.
As it doesn't seem to be in the KRNIC database (as served by KRNIC) any
longer, the object should vanish from whois.APNIC.net with the next mirror
update. Much ado over nothing, IMHO.