I know this is a sore issue with you - but this is not "a mistake". It is a policy (that you don't agree with).
Without knowing that there *is* a policy, I cannot agree (or disagree!) with it. :)
A) ISO has recognized that strict interpretation of the definitions of ISO 3166 prevent inclusion of "EU". However, being pragmatic, it has RESERVED "EU" so that users of 3166 can use it absence of a formal country code. http://www.iso.ch/iso/en/prods-services/iso3166ma/10faq/frequently-asked-que stions.html#QS05
That's fine. I have no problem with the ISO doing that.
My issue is that RIPE is allowing users to make up codes that aren't allowed. Of course, the fact that the people at RIPE that I've dealt with are quite clueless doesn't exactly help keep my opinion unbiased.
B) Based on the ISO compromise, and recognizing the fact that several multi-national networks and address ranges do NOT stop at arbitrary country borders (think of countries like Luxemburg, Belgium, Netherlands, etc.), RIPE has established the policy of using (and allowing the use of) 'EU' in the country code field to more accurately represent the location.
If they have, they haven't done so in an appropriate way. If the format of the data specifies one thing, and you put something else there, you can't expect people to just start adjusting to the bogus data without question.
(It would be just as silly, if UUNET were forced to define a country code of "Rhode Island" for a cross-continental network - instead of "US".)
But that's how it works! The geolocation data has the country an IP was assigned to, not the city, not the continent, not the organization. ARIN can't just go and publish the country as "US-RI" to indicate the state of Rhode Island within the U.S. That would at least make the data more granular (once programs were "fixed" to accept it), rather than less granular (as RIPE appears to be doing). But once you break a standard it is no longer a standard (RIPE isn't Microsoft yet!).
I think it would be appropriate to bring the all_list.dat in compliance with the policies of RIPE, which after all is authoritative for its database - even if don't agree how they define "country" for the purposes of THEIR database.
It may be their database, but not their database format. They didn't design it. In any case, the all_list.dat file is in compliance (it just stores "EU", which is what RIPE supplies). And the *only* way that it affects Declude JunkMail is in the header that is displayed by organizations that are allocated IPs from RIPE in this unrecognized format.
Again, this has nothing to do with the European Union -- it has to do with RIPE and their lack of compliance with standards.
-Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000.
Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection.
Find out what you've been missing: Ask for a free 30-day evaluation.
---- This outgoing message is guaranteed to be authentic by Message Level users. Guarantee the authenticity of your email @ http://www.messagelevel.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
