On Sat, 27 Jun 1998, Karl Denninger wrote:

A long time. We're blocking huge parts of the Asian and European networks right now in the Spamblock system, and in fact, I'd estimate that 80% of all entries made are non-US these days.

95% of the spam attacks we see come from the USA, advertising USA services, 99% with forged headers (yahoo, hotmail, msn, prodigy and earthlink are tops, juno and bigfoot much less now). 5% and growing are people in Europe who seem to think they can get payment for spamming on behalf of USA web sites! However, in late October, Europe will require its member states to enact legislation to control unsolicited communication of any type. Hopefully the respective gov'ts will do something effective rather than try and sidestep the issue (just after pigs master basic aerobatics :-). Agreed that a lot of open relays seem to exist in JP... and there are significant numbers in Europe as suggested. The time zone and language differences are going to be a big PITA in terms of getting the problems sorted quickly. In Japan, they seem to think <postmaster> is optional!!! The UK is getting its act together on spam... as spammers's targets for relays are driven out of the USA they are hitting further down the chain (machines on slower lines rather than close to the cores), targeting ISP's customers not the ISPs. I suspect that Europe will be the next spammers's paradise regardless of gov't support etc. Perhaps we should all hope that the year2000 bug will break all broken systems totally, leaving only the clueful to run the place properly. Paul ---- P Mansfield, Senior SysAdmin PSINet, +44-1223-577577x2611/577611 fax:577600 :r~/humour/signature :wq

On Tue, 30 Jun 1998, Peter Evans wrote:

Getting providers here to institute <abuse> and or even take any sort of measures against spamming by their own users is an uphill task.

I've been working with JD Falk and the CAUCE folks about getting some resources in japanese together covering MTA configuration and usage of the RBL among other things. My personal goal is finding someone willing to actively maintain parts of the sendmail FAQ and vix's tsi pages in japanese.

Peter

matt postmaster@interq.or.JP --matt@bikkle.interq.or.jp------------------------------------------- Matt Ghali MG406/GM023JP - System Administrator, interQ, Inc AS7506 "Sub-optimal is a state of mind." -Dave Rand, <dlr@bungi.com>

David R. Conrad wrote:

Hi,

One reason might be that clueless folk in the US that complain to APNIC or RIPE (or NANOG) directly instead of looking stuff up in the appropriate whois database ("ARIN has all the IP information, right?") and complaining to the people who can actually do something about the problem.

Keep in mind that some of these "clueless folk" may expect individually assigned CIDRs to be registered accurately, and are complaing to the registered contact for the block. If these blocks aren't registered/SWIPed appropriately, your argument is weak. As to the "people who can actually do something about the problem", generally they are the problem. Polite requests for resolution regularly fall on unhearing ears. The problem is escalating to the point where it's much more convenient to simply block an entire /16 or larger, than to attempt to contact the appropriate person, which is quite unfortunate.

Another reason might be that until very recently, sendmail shipped with relay enabled by default and very little in the way of easily understood (particularly by non-native English speakers) documentation on how to disable relaying in the shipped tarball. Not that either matters, of course. Everyone has the same access to knowledge and skills as ISPs in the US, right? Besides, it is so much more productive (or at least cathartic) to whine to a US based mailing list that targets ISPs in North America.

If you know of a more appropriate forum for such a question, I'm listening. This was indeed more a legit question (with a possibly poorly-chosen subject line) than a whining waste of space. Out of curiosity, are you advocating a certain measure of irresponsible network management based on sendmail's somewhat cryptic nature? God forbid a net manager should open a book.

If you think blocking all of Europe/Northern Africa/Former Soviet Union and Asia/Pacific helps you out (after all, the US is the only part of the Internet that matters, right?), knock yourself out. To give you a hand: APNIC allocates out of 202/7, 210/7, and 61/8 (althought we haven't allocated anything out of 211/8 to date) -- should make filters easy.

You've entirely misinterpreted my post. If it appeared as nothing more than an unsubstantiated rant, please accept my apology. Brian -- --=Please direct technical support questions to support@meganet.net =-- ======================================================================= Brian Wallingford voice: 508.646.0030 Network Operations Manager email: brian@meganet.net MEGANET COMMUNICATIONS, TCIX, Inc. http://www.meganet.net =======================================================================

In any case, I contest your statement that Europe (don't know about AP) is noticeably behind. If I look at the locations of the relays on the spam that gets through here, the vast majority are in the US.

I see the same here. And, as the US has the *minority* of hosts in the world, this jingositic thread is as stoopid as it appeared at first blush. randy

...

Keep in mind that some of these "clueless folk" may expect individually assigned CIDRs to be registered accurately, and are complaing to the registered contact for the block. If these blocks aren't registered/SWIPed appropriately, your argument is weak.

Wrong. Most people (clueless or not) only know of Internic and therefore do not look at Ripe or Apnic. Even when it says in the Internic (now Arin) entry to look at whois.ripe.net for proper delegation, they ignore it since it is one line and not prominent. ARIN refuses to add comments last time I requested. The end result is I get about a dozen spam complaints a week from users who are simply complaining to the wrong person.

ARIN adds comments to the records for RIPE and APNIC, it's not logical for us to add comments to every non-US network record when it makes more sense to take your record out of ARIN and put it in RIPE's db. This is something the registries are working on. Kim Hubbard ARIN

Hank Nussbacher

On Sun, 28 Jun 1998, Kim Hubbard wrote:

ARIN adds comments to the records for RIPE and APNIC, it's not logical for us to add comments to every non-US network record when it makes more sense to take your record out of ARIN and put it in RIPE's db. This is something the registries are working on.

I'm beginning to wonder if it makes more sense for ARIN's whois server to just reply to any queries for APNIC or RIPE space with this: No information available - RIPE Network. The ARIN Registration Services Host contains ONLY Internet Network Information: ARIN Region Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and nic.ddn.mil for MILNET Information. For European information use the whois server at whois.ripe.net and for the Asia-Pacific region use whois.apnic.net That will stop the flow of useless complaints and anyone who is clueful enough can pick up on the word "RIPE" or "APNIC" in the first line and use it to request the info from the correct source. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com Check the website for my Internet World articles - http://www.memra.com

[I should just keep my mouth shut, and pray the thread dies.] "David R. Conrad" writes:

APNIC has a policy that _all_ "permanent" reassignments made by ISPs must be recorded in the APNIC database before address space is considered used.

I believe RIPE-NCC has a similar policy

Sometimes it doesn't happen. I can't count the number of times we've queried APNIC, RIPE, etc., only to receive the catch-all record. (That's not to complain, directly, about the state of the databases, merely a statement of fact.) So that's where we send the complaint. I can count the number of times such messages have generated a response: five from APNIC, twice from NORGESNETT, and twice from RIPE. Its possible that many of them were forwarded, but most of the sources/relays we've complained to have been "sorry about that", so I expected to have received some responses -- count: zero. Note: Don't fear, APNIC isn't out-of-norm, most NSP's are doing the same.

Of course, the fact that an entry is in a database (any database) doesn't mean it is valid, either when it was inserted or anytime thereafter,

Aye. This has been hashed over before, but it would be quite helpful if the registries were to audit their databases periodically.

...

God forbid a net manager should open a book.

Ah, sorry. I must have missed the announcement of Allman's book translated into Thai, Mongolian, Bangala, (etc.).

I can't buy this complaint. Just because someone wrote a program does not mean that that person should have to publish instructions in every language possible just because its possible that people everywhere might use it. Whoever made the choice to use Sendmail should translate the documentation (man pages, op manual, _and_ web pages) for the target audience.  FYI: The responses received from regional or national registries were... APNIC (all): "please send to the registered entity", none was listed. NORGESNETT (both): They didn't grasp our request that we be told who was the next most responsible party (IBM as it turned out) or that the complaint be forwarded to that party. Since we have no Norweigean skills on staff the complaint fell through the cracks. (The space has since been registered more sanely.) RIPE #1: "please send to the registered entity", none was listed. RIPE #2: "please send to the registered entity", no e-mail contact information was present in the updated after our complaint entry.

[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.

On Sun, 28 Jun 1998, Mark Milhollan wrote:

"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.

What about d). Perhaps someone temporarily announced routes for unallocated space, setup a mail/spam server in that IP space, sent out their mail, and stopped exporting the route. Is there a place one can search to see a history of BGP announcements for a given route? ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

Although still somewhat primitive, there is a free tool (Java) that tracks current/historical BGP announcements from providers. The tool, RouteTracker, is available at http://www.merit.edu/ipma/tools - Craig at Sun, 28 Jun 1998 12:59:27 PDT, you wrote:

That might show up as a flap, visible in the databases that keep and publish histories of flap information. The IPMA reports at http://www.merit.edu/ipma/reports/ might help, specifically the reports on Routing Instability and Routing Problems. There doesn't seem to be an index into the data that would make a quick lookup based on a specific prefix easy, though.

If I recall correctly, there was a raging debate a while back on the topic of publishing route flap information because the Popular Press was using such information to rate one provider over another, or to assert that the whole net was about to drown in a sea of routing updates. The many lawyers that subscribe to the nanog list asserted that legal action against the publishers of flap information was a virtual certainty, and then the thread ... just ... died.

-- Craig Labovitz labovit@merit.edu Merit Network, Inc. http://www.merit.edu/~labovit 4251 Plymouth Road, Suite C. (734) 764-0252 (office) Ann Arbor, MI 48105-2785 (734) 647-3185 (fax)

Hi,

...

...

b) someone has dummied up a prefix in a mail header or something (typical) c) there is a bug in the database software (happens) What about d). Perhaps someone temporarily announced routes for unallocated space, setup a mail/spam server in that IP space, sent out

"David R. Conrad" writes: their mail, and stopped exporting the route.

Actually, that was "a", what I call prefix theft. I figure it is becoming more and more common, and I know of at least one case where it was an actual policy of a large network. <CYNICAL> However, this isn't a problem anymore given we have not one, but two proposals on how to authenticate routing announcments. All the rest is just a small matter of programming. </CYNICAL> As an aside, it always amazes me that the Internet even works (particularly for an infrastructure that the unwashed masses seems to think will replace the existing telephone network), but I guess the same could be said of any chaotic (in the non-linear sense) system... Regards, -drc

On Mon, 29 Jun 1998, David R. Conrad wrote:

Actually, that was "a", what I call prefix theft. I figure it is becoming more and more common, and I know of at least one case where it was an actual policy of a large network.

I don't see how it can be on the rise. When FDT multihomed, we had to arrange with both our providers to accept our route. Why aren't all the big providers putting distribute lists on their customer BGP peers? The access-lists should change infrequently enough that it wouldn't be a big deal to maintain, and it would make the net a better place. If I totaly hose our BGP setup and announce crap to either provider, nobody will be affected. In fact, I think I did this the first night I setup BGP. Nothing bad happened. While they're at it, they could use the same data to setup/maintain ingress filters. Last I heard, Cisco had finally made it so that non-logged extended access-list filtered packets are still fast switched. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

...

Why aren't all the big providers putting distribute lists on their customer BGP peers?

I suspect the same reason some people don't use condoms. Trusting folk to not do the wrong thing makes life so simple -- except when it doesn't work...

I always carry a distribute list in my wallet... -- Alex Bligh GX Networks (formerly Xara Networks)