[The original point was that the proper registry can be difficult to find so that meaningful results can be obtained. One poster lamented that the whois "system" should do the right thing. ARIN may be doing so these days.] "David R. Conrad" writes:
b) someone has dummied up a prefix in a mail header or something (typical) c) there is a bug in the database software (happens)
I doubt B since the IP address queried was that of the TCP peer. Granted it could have been a spoofed session, but that would have required a level of expertise that I've never seen used merely to attempt delivery of a few thousand pieces of e-mail. I suspect either C, flaky data, or C due to flaky data.
If the prefix has been allocated, it will show up in the APNIC database (part of the procedure for allocation is updating the APNIC database).
Which is what seemed to have been assumed by the people that sent the responses we received. However they did not include the "correct" information. When we query the registries (which we try to avoid since its such a slow, and imprecise mechanism) we first try the exact address, then we back-off (class-wise) until either a non-catch-all response is received, or an /8 is achieved.
Might show up as the service provider instead of the end user though...
That is what we usually locate, as is who we prefer to contact. I should clarify that we have made many queries to the various registries, and in most cases we have received sufficiently precise information so as to avoid a "please advise or forward" situation. The problem usually lays in the remaining, imprecise, cases.
Note: Don't fear, APNIC isn't out-of-norm, most NSP's are doing the same.
APNIC isn't an NSP.
I wasn't clear enough, sorry. What I meant to say was that, amongst all cases where it was apparent that the database yielded contacts that almost certainly were not the operators of the source networks APNIC was not unique in their responses. Specifically, we've also sent plenty of "please advise or forward" messages to MCI, PSI, SPRINT, and UUNET (just to name a few) that have yielded the same, or similar, results as those sent to the registries.
And the chances standard Unix vendors who supply sendmail (etc.) with their distributions will even include up to date distributions, much less up to date documentation or even documentation more than a man page are? And you expect these folks to also translate the documentation?
I certainly do expect it of the vendors. That they don't should not reflect poorly on Eric. No "service provider" specific distributions of any MTA exist of which I am aware. Anyone using a general distribution, or even a service provider specific one, that did not take the time to examine the settings for appropriateness are themselves delinquent, rather than the package's author. Having chosen to provide e-mail services they should have examined the package in-hand (probably part of a general, rather than service provider specific, OS distribution) as well as the alternatives. This should have resulted in them scuttling off to, e.g., www.exim.org, www.qmail.org, www.sendmail.org, and www.zmailer.org (to name a few). Information is present at the Sendmail site describing the pros and cons of the relay settings extant, and how to change them within several service provisionings.
APNIC (all): "please send to the registered entity", none was listed.
We also tell you how to determine how to find the registered entities in the canned response.
We used that method to arrive at the address we used. The mail we sent indicated that you were receiving it due to a lack of additional information. Since the registries receive so many pieces of mail I understand the need for a canned response, but one to/in which the correct data had been appended/inserted would have been much more helpful.
For reference, I've personally received about 100 complaints about spam over the past 12 hours, about 85% demanding that APNIC disconnect "our dialup customer" which has resulted in the spam, and about 50% you have included the response from InterNIC that states "please check the APNIC database prior to contacting APNIC". I don't even bother to respond any more.
I can understand, and I do sympathize -- you will never have received such mail from us. What are those of us that do query the registry properly, yet still land on the registry's entry supposed to do? It may be that ARIN recognizes this catch-22, and has begun to act in a fashion that helps. What we have received from the (previously named) registries, and from several (just named) NSP's ... APNIC: Usually no response, nor evidence of forwarding. Five "please send to the registered entity" but no information as to who that would be. MCI: No response, nor evidence of forwarding. In one case a voice call to their security department caused a message to be passed to the source network, which responded within an hour. (By then the relay had been totally absorbed by us, so the useful net effect was nil.) NORGESNETT: Good intentioned responses to the first two messages. The next three garnered no response, nor evidence of forwarding. We've since had no reason to send to them as: a) analysis showed that the addresses were IBM dial-up ports, and b) the registry database now clearly shows this anyway. PSI: Usually no response, nor evidence of forwarding. Twice "please send to the registered entity" but no information as to who that would be. RIPE: Usually no response, nor evidence of forwarding. Twice "please send to the registered entity" but no information as to who that would be. In one of the later cases the registry had been updated after our message was transmitted, but the new information did not contain an e-mail entry. SPRINT: No response, nor evidence of forwarding. UUNET: No response, nor evidence of forwarding. An example: Note: ARIN is the correct NIC to query these days, at the time it was InterNIC. $ whois 203.30.7.44@whois.internic.net [originally this yielded a "not found" response] $ whois 203.30.7.0@whois.internic.net [originally this yielded a "not found" response] $ whois 203.30.0.0@whois.internic.net [originally this yielded a "not found" response] $ whois 203.0.0.0@whois.internic.net [originally this yielded the following response] [rs.internic.net] Asia Pacific Network Information Center (APNIC2) [...] Netname: APNIC-CIDR-BLK Netblock: 202.0.0.0 - 203.255.255.0 Maintainer: AP Coordinator: Gampe, Paul A. (PAG4-ARIN) hostmaster@APNIC.NET +81-3-5500-0480 (FAX) +81-3-3353-6096 [...] *** please refer to whois.apnic.net for more information *** *** before contacting APNIC *** *** use whois -h whois.apnic.net <object> *** [...] Okay, we know we have to parse responses for the "please refer to" redirection -- we know what to do ... $ whois 203.30.7.44@whois.apnic.net [teckla.apnic.net] inetnum: 203.0.0.0 - 203.63.255.255 netname: AUNIC-AU [...] person: Geoff Huston [...] e-mail: gih@aarnet.edu.au [...] The response has no indication that AUNIC should be polled for more information -- Geoff probably has the same problem you do as a result of this. Fortunately we know about the AUNIC whois server, yet ... $ whois 203.30.7.44@whois.aarnet.edu.au [nico.telstra.net] inetnum: 203.30.0.0 - 203.30.15.255 netname: AUSSIENET-AU [...] admin-c: AK600 tech-c: AK600 [...] $ whois AK600@whois.aarnet.edu.au [nico.telstra.net] No entries found for the selected source(s). So Geoff still would have gotten the mail. These days we also tend to try rwhois using root.rwhois.net ... $ rwhois whois 203.30.7.44 Referral Whois (RWhois) spec version 1.0 (InterNIC V-1.0B9.2) network:Class-Name:network network:Auth-Area:0.0.0.0/0 network:ID:NETBLK-AUSSIENET-AU.0.0.0.0/0 [...] network:Tech-Contact;I:AK600.NET [...] Which still isn't quite enough, so an extra pass is needed. $ rwhois ak600.net Referral Whois (RWhois) spec version 1.0 (InterNIC V-1.0B9.2) [...] contact:Email:andrew@AUSSIE.NET [...] Finally a contact that should be near enough to be useful. This is a sufficiently large block that its unlikely that aussie.net is the actual source network, but they should be close enough to be a useful first step. I always say that to myself, yet often nothing comes of these messages. And the point to it all? I suppose I am just restating the original poster's complaint that it is damned hard to know where to go to get the ultimate information, as well as a responding poster's desire that the system do the right thing so that everyone doesn't have to know the proper incantation to avoid sending mail to people far removed from the actual source. It may be that ARIN recognizes this -- a run of this query today yielded ... [rs.arin.net] Asia Pacific Network Information Center (APNIC2) APNIC-CIDR-BLK 202.0.0.0 - 203.255.255.0 The Australian Internet Registry Pty Ltd (NETBLK-AUSTRALIA) AUSTRALIA-CIDR-BLK 203.0.0.0 - 203.63.255.0 aussie.net Pty Limited (NETBLK-AUSSIENET-AU) AUSSIENET-AU 203.30.0.0 - 203.30.15.255 [...] Our scripts would have selected NETBLK-AUSSIENET-AU for expansion ... [rs.arin.net] aussie.net Pty Limited (NETBLK-AUSSIENET-AU) [...] Coordinator: Khoo, Andrew (AK600-ARIN) andrew@AUSSIE.NET 61-2-318-2341 (FAX) 61-2-310-3362 [...] Bingo, there in two steps. (An rwhois-based query also requires two steps.) The original whois trail required seven, but only yielded a national registry address.