Re: Question concerning authoritative bodies.
On Sun, 9 Mar 2003, E.B. Dreger wrote: In AOL's case, they couldn't even tell us why our mail was being rejected or our connections to their MX's blocked and I had to wait a week for their postmaster dept. to get to my ticket and return my call to fill me in on what was going on. E. Much better to put a semi-descriptive code in the 5.x.x and give a contact phone number and/or off-net email box. There was a multiline message (when our connections weren't just refused or immediately closed). 550-The information presently available to AOL indicates that your server 550-is being used to transmit unsolicited bulk e-mail to AOL. Based on AOL's 550-Unsolicited Bulk E-mail policy at http://www.aol.com/info/bulkemail.html 550-AOL cannot accept further e-mail transactions from your server or your 550-domain. Please have your ISP/ASP contact AOL to resolve the issue at 550 703.265.4670. Trouble was, the people at 703.265.4670 can't help you. They just take your name, number, and some other basic info, and open a ticket that the postmaster group will get to eventually. On the affected system, I ended up changing the source IP for talking to AOL's servers. True. It cracks me up when someone complains about being on Selwerd XBL. xbl.selwerd.cx might be useful for a few points in a spamassassin setup. I don't use it. [EMAIL PROTECTED] implied that some of the other DNSBLs include selwerd. I'm not aware of any, but I'm sure there are lots of DNSBLs I've never heard of and know nothing about. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
69/8...this sucks
Atlantic.Net has just joined the 69/8 club of ARIN members with assignments in this IP block that's apparently in numerous outdated bogon filters. As I posted I'd do earlier if given space from this block, I've written some code to check reachability to a large number of remote IPs from 2 source IPs...one in one of our older ARIN blocks, one in the new 69 block. I'm feeding this code a very large list of known mail server IPs, and having it ping each IP...only it'll ignore /24's once reachability from both the old and new IPs has been established to an IP in that /24. It's only just getting started on the list, but I've already found dozens of networks that appear to be problems. I've hand confirmed a couple and sent off emails to the ARIN contacts. It looks like there are going to be so many networks to notify, I'll have to write some more code to automate these emails. What have others in this situation done? Are you actually assigning 69/8 IP's to unsuspecting customers and hoping they won't notice parts of the internet ignoring them? According to ARIN's whois server, there are 95 subdelegations for NET-69-0-0-0-0...we're the 95th. I don't know if ARIN has other less tainted IP space to give out, but something ought to be said/asked about this at the next meeting. I realize ARIN can't guarantee global routability of IP space, but should they continue to give out IP blocks they absolutely know are not fully routable on the internet today? -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Who uses RADB? [was BGP to doom us all]
On Sat, 1 Mar 2003, Mark Radabaugh wrote: Who actually uses RADB to build filters other than Verio? While my experience with other providers is limited Verio is the only one (of the ones we have used) who used RADB entries for BGP peers. AFAIK, Level3 and CW. I have to keep RADB entries (actually altdb, and cw's own) up to date in order for each of them to accept our routes and our BGP customers' routes. Overall it wasn't the best solution IMHO for a couple of reasons: - there was nothing to keep us from making bogus entries in the RADB - filters were only updated once a day making changes slow OTOH, they don't have to pay someone to answer and respond to email sent to bgp-admin. They won't accept routes you accidentally leak to them. Is it secure? Not really. Is it cheap, reliable automation, I suspect so. This is not meant as a complaint toward Verio - I'm simply trying to decide why we should go to the added expense of entering our routes in a RADB. To date I have seen no operational difference between using RADB and not using www.altdb.net. No expense other than the time you spend keeping your objects up to date. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: anti-spam vs network abuse
On 1 Mar 2003, Michael Lamoureux wrote: andy If so, why outlaw the act of probing? Why not outlaw probing andy for the purposes of...? What's the offset into the probe packets to the intent of the this probe field? And would you trust it if there were one anyway? People speed, drive drunk, and run over pedestrians. Should we outlaw cars? Maybe just in California? :) What's a legit probe? One where the owner gave you permission in advance to run the scan? I can't think of another definition of that phrase. When you walk into the secure part of an airport or some schools in rough neighborhoods, you're scanned for metallic objects. When you exchange traffic with certain networks, they may also want to check you out to see what risk may be associated with accepting your data in the future. If your system is an open relay/proxy, then there's elevated risk that at some point (if not already), the data coming from your system will be SPAM. Some networks will choose not to accept your data or to tag it in order to prevent their customers from having to accept unwanted data. This is a completely naive statement. There are 0 networks that I'm willing to believe have 0 vulnerabilities on them. There may be 0 that you know about, but that doesn't mean there aren't more vulnerabilities which aren't public knowledge lurking in sendmail or bind or ssh or ssl or apache or any number of other services you have running. So if nobody probes your network, it's more secure? -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: anti-spam vs network abuse
On Fri, 28 Feb 2003, Roy wrote: I haven not checked NJABL but some of the other other open relay testers use scenarios that are illegal (actually criminal) in California. If you mean the use of incorrect from addresses, I believe that law only applies if the message(s) sent with someone else's address results in damage. I'm not here to debate the issue, and I certainly didn't mean to start such a long thread here (the same post went to spam-l, where it was nearly ignored), but I don't think 1 test message sent every 4 weeks (or less frequently) will cause damage[1]. [1] yes...I am aware of one case where were ORBZ got in some hot water over an SMTP envelope that effectively broke an outdated version of Lotus Domino. NJABL takes precautions to not repeat that mishap. Just to be safe, mayby I'll avoid visiting the People's Republic of Kalifornia. That shouldn't be so hard. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: anti-spam vs network abuse
On Fri, 28 Feb 2003, Andy Dills wrote: Actually, I think the debate starts with Paul telling Jon that Jon isn't passively scanning connection hosts, he's actively trawling for open proxies, that Paul has the logs to prove it, and that since Paul is in California, Jon has broken the law. He was using considerable artistic license with the numbers when he said every IP on every net he owns had been checked by NJABL. The reality is more like 0.06% of the IPs on 3 networks he owns or manages were checked over the span of about 7 months. At that rate (if my math is correct), it would take almost 1000 years to scan all the IPs on those networks. Hopefully, someone will have solved this spam problem by then. You don't have to. This is why I never understood why people care so much about probing. If you do a good job with your network, probing will have zero affect on you. All the person probing can do (regardless of their intent) is say Gee, I guess there aren't any vulnerabilities with this network. When I hooked up my first server on the internet back in 1993, I was kind of shocked that some far away stranger was trying to log into my POP3 server. Unwanted connections have been a fact of life on the internet probably since its beginning. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: RIPE Down or DOSed ?
On Thu, 27 Feb 2003, Kai Schlichting wrote: Secrecy over a public resource = no oversight = facilitator of abuse. Why do I get the distinct feeling that this move by Level3 is aimed not at creating greater customer privacy (it never served POC email addresses), or protecting themselves from getting their customer base poached by other providers, but at preventing people from identifying spamming Level3 customers (of which they seem to have 100's) by organization name and being able to correlate activity from different netblocks of theirs. Though I agree, Level3 seems to host a good number of spammers, they're by no means the only guilty party. Pulled at random from recent spams I've submitted to NJABL are 69.6.4.104, 69.6.4.114, and 69.6.4.156. whois @arin.net yields the following: ... NetRange: 69.6.0.0 - 69.6.63.255 CIDR: 69.6.0.0/18 NetName:WHOLE-2 NetHandle: NET-69-6-0-0-1 Parent: NET-69-0-0-0-0 NetType:Direct Allocation NameServer: NS1.WHOLESALEBANDWIDTH.COM NameServer: NS2.WHOLESALEBANDWIDTH.COM ... Where are the swips? The rest of that record makes no mention of an rwhois server. Doing a bunch of whois requests for IPs in that block, I found only one swip (for a /21). I realize the ARIN regs don't seem to require that reassignment info be made available to the public (just to ARIN), but using your innocent customers (if there are any) as a shield to hide your spammer customers is just wrong. Should I block 69.6.4.0/24 from sending email into my systems? 69.6.0.0/18? http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.104 http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.114 http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.156 -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
anti-spam vs network abuse
We (Atlantic.Net) have gotten a flurry of abuse complaints from people who's systems have been scanned by 209.208.0.15 (rt.njabl.org...a DNSBL hosted on our network). I'm hoping the new PTR record will head off many complaints now. For the past 15 months, NJABL has reactively tested systems that have connected to participating SMTP servers to see if those systems are open relays. Just over a week ago, NJABL added open proxy testing to its relay testing software. The proxy testing checks for a variety of common proxy software/protocols on about 20 different ports simultaneously. This is apparently setting off some IDS/firewall alarms. We do not consider what NJABL does abuse, and we reply to all the complaints explaining that the complainant should go have a look at http://njabl.org/ and hopefully they'll understand why their system was scanned. This sort of activity is becoming more common / mainstream, so people ought to just get used to it. Road Runner is doing the same thing (according to http://sec.rr.com/probing.htm) which is pretty ironic given how their security department has gotten along with (or not) various DNSBLs in the past. BTW...in the week that NJABL has been testing for open proxies, more than 18000 have been detected, pretty much all of which are actively being abused by spammers, else mail would not have come through them. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: IP Management tool for service providers
On Thu, 20 Feb 2003, John Todd wrote: Here's one. I haven't used it in production, but the demo that I was given was pretty slick. Works on pretty much any POSIX platform... Alas, it is commercial software. Voyager IP http://www.vger.com/products.shtml#v_ip Where did you see a demo? Any idea what it costs? I just sent them an email. Not much info on their web site, and their contact submission form is broken. This was referenced on the list back in Jan of 2002: http://www.freeipdb.org/ http://www.globalcrossing.com A coworker took a look at this recently. He had some difficulty getting it installed properly and it lacks some features we'd require relating to the tracking of IP allocations in the ways ARIN demands. This was referenced on the list in November of 2001: http://www.brownkid.net/NorthStar/ I just installed this. Installation went easily, but it doesn't seem to actually work :) After adding a big block of space and creating one allocation in it, the links to create additional subnets bring up the wrong page. It seems very browser dependent. i.e. with various versions of Netscape and Mozilla on Linux, some of the pages don't work (but don't produce any error messages). The same pages did work in IE on Windows, at least until the whole thing quit working. It also lacks necessary features and doesn't seem to be flexible enough to incorporate the features I want without digging into the code. The basics of what I think an IP allocation tracking system needs (at least for any ARIN member) are: 1) Ability to track allocations from multiple IP blocks 2) Ability to track type of assignment (i.e. assigned vs reserved) 3) Ability to track service category as required on ARIN additional request form. i.e. Dial-up|Cable|Web Hosting|Leased Line| xDSL|Co-location|Wireless|Other-other subcategory 4) Storage of customer name and contact info for each allocation 5) Storage of justification info for each assignment 6) Ability to present unallocated space in such a way that allocations can be done efficiently. i.e. if a /28 needs to be allocated, make it easy to find unallocated existing /28's, rather than do unnecessary subnetting to create a new /28. 7) Auditing. When it's additional request time, you need to be able to audit your assignments and add up how much space is reserved, how much is assigned, how much is being used for each of the various ARIN defined categories, look up justifications, etc. 8) Automated swip/unswip or hooks to automate rwhois maintenance would be nice, but not absolutely required. The systems I've seen so far lack multiple features from the above list. Is everyone just using flat files, spreadsheets, or home grown solutions? -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69.0.0.0/8 - Please update your filters
On Tue, 25 Feb 2003, Stephen Sprunk wrote: Thus spake E.B. Dreger [EMAIL PROTECTED] I _still_ like the idea of putting DNS roots in new IP blocks during sunrise and having the final octet be .0 and/or .255. It would be nice to catch dated bogon filters, lame attempts at smurf stopping, _and_ stale root.cache in one blow. From an academic standpoint, that would be a very interesting experiment. However, most of us are paid to keep our networks or services running, not to intentionally break them. The trouble is, some people are neglecting their jobs and making things rough for others (the people getting new allocations). Somebody with one of these new cursed allocations ought to setup a system with two IPs (one from the new block, one from an older established block) and do reachability tests to various parts of the net, and then automate sending a notice of bogus filters to those ASNs reachable from the old IP, but not from the new one. If I end up with some of this space, I'll be doing this. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69.0.0.0/8 - Please update your filters
On Tue, 25 Feb 2003, Haesu wrote: And how quickly would those ASN's respond to or even comprehend the bogon-filter update notices? If those ASN's are competent and quick-responsive ones, we should not even be having these prroblems to begin with. If the alternative is getting space, giving it to customers, and explaining why they can't reach X, Y, and Z on their connection to us, but they can on other internet connections, we're going to at least have to try. I like the idea of moving the gtld servers into such space. That way, the networks that are at fault will break, and they'll be well motivated to fix their filters. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: M$SQL cleanup incentives
On Sat, 22 Feb 2003, Doug Clements wrote: The issue I had with your argument is forever. You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory. Unlikely in this case. A reasonably fast system infected with slammer is capable of generating enough traffic to make the Cisco 2900XL switch its plugged into incapable of passing normal traffic. All it takes is one infected customer's system to really foul up the network it's attached to. The only plus side is, this is perfect justification to management for replacing any switches customers connect to with newer ones that (at least claim to) do per-port rate limiting. If your network is able to contain slammer infected boxes without melting down, who cares if you have a few infected customers? You don't need to filter, and they'll all be encouraged to fix their systems sooner. I setup inbound 1434/udp filters the 3rd time we had a customer (different ones each time) get (re-?)infected weeks after the initial outbreak. Sure, some DNS replies and assorted other packets will get dropped, but AFAIK, nobody has complained or even noticed...and we've had no more re-infections since the filters were put in place. I don't believe we'll have to filter 1434/udp forever, but I plan to leave the filters in place until we no longer need them or until they hurt more than they help. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: M$SQL cleanup incentives
On Sat, 22 Feb 2003, Stephen Sprunk wrote: As one hoster put it to me, DoS and worm traffic is billable so it's not in the hoster's interests to protect customers -- quite the opposite in fact. Whether or not the traffic is billable is irrelevant if your network is effectively down. One infected host connected to a 2900XL effectively kills the switch. I was fortunate enough to be on vacation and not even have net access when the initial slammer wave hit. But when I was back and on-call, we had a single customer get (re-?)infected, killing the switch they were on and noticably slowing down the network for the whole POP. What will you do when a similar worm appears on 53/udp or some other heavily-used port? We lucked out with Sapphire because MS/SQL is generally Be screwed unless we've completed planned upgrades. But in this case, I can filter until we've upgraded our network to hardware that's better able to deal with such traffic. Just because filtering might not always work doesn't mean it shouldn't be done when it does work. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: scripts to map IP to AS?
On Thu, 20 Feb 2003, William Allen Simpson wrote: Anybody have a pointer to scripts to map IP to AS? I suspect the easiest thing to do would be to write some code to query a looking glass, perhaps even install your own for this There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets, and I'd like to start blocking routing to those irresponsible AS's that haven't blocked their miscreant customers. but automatically blocking AS's that send some 1434/udp traffic your way sounds like a really bad idea and would setup an easy way to DoS your network by tricking you into blocking certain AS's. Why not just block 1434/udp at your ingress points and be happy? -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: DC power versus AC power
On Fri, 27 Dec 2002, Scott Granados wrote: It is likely that in many settings during power failures transition from ac street power to ac generator power will have some lag and during that time your hardware could loose power. This of course depends on ups systems in use and many factors. Dc usually however is clean in its transition and goes with out saying is battery backed up. I'll add to that, that since DC removes the need for your own UPS's, by going with DC, you save rack space, deploy less gear (UPS's are HEAVY), and don't have to worry about which POPs have how many UPS's with dead batteries at any given time. OTOH, since with DC you're unlikely to have any backup power of your own, it is important to wire up both an A side and B side. Some places (like certain telcos) like to briefly turn off parts of their DC power grids somewhat regularly. This makes gear with only one set of DC inputs rather annoying. Does anyone actually wire up both the A side and B side to a single DC power supply and use diodes to keep the two supply grids separate? DC also avoids bulky AC power cords...and not only are the wires less bulky, but you'll likely cut them to the actual length needed. Since DC wiring is usually screwed down, they don't get bumped or accidentally pulled out of the outlets as often. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Operational Issues with 69.0.0.0/8...
On Mon, 9 Dec 2002, Todd A. Blank wrote: I hereby challenge one of you to trade CIDRs with us. You take this 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, resources, and money working out what seems to be nobody's problem. Was this an initial allocation into which you're renumbering out of provider space, or a trade-in (you gave some block back to ARIN and got this one)? Based on the newness of your ASN and sho ip bg regex _26483, I'm guessing it's your first allocation. Assuming you did this because you were about out of the space allocated to you by your provider(s), have you looked into getting some more space from your providers to keep things running while the issues with 69.0.0.0/8 filters are worked out? Even if they've already given you as much space as their policies allow, I suspect you could talk them into bending the rules in a case like this. Creating more networks to renumber sucks, but it beats losing customers, and you have plenty of time...probably even more than the ARIN published guidelines for renumbering due to the problems you've encountered...and what can ARIN do if you go beyond their suggested deadline anyway? I don't have any spare CIDRs to trade you. In fact, I'll be doing the ARIN dance again soon to get more space since we're running out. I'm really not looking forward to being in the same boat as you, but at least I know now to expect trouble, especially if we get a chunk of the same /8 you did. In your first message, you posted a couple of web sites that were not reachable from your IP space. It'd be more useful (to people in your shoes) and more embarrassing (to the offending networks) if you could post the names of the networks/backbones you've identified thus far that are still filtering 69.0.0.0/8. Maybe someone reading this list will know someone who knows someone at those networks and be able to get something done. If nothing else, it gives the next guy who gets 69.0.0.0/8 space a starting point of networks to check connectivity to and networks to contact if things don't work for them. Then those networks will have multiple people pestering them to fix their filters even if not everyone affected has customers that actually care about reaching those nets. Also, if you would like to come over and answer the support calls and explain to our customers why the competitor's networks can reach these sites, but ours can't. Hey - after all, it's just CIDR - it's all the same, right? Have you given customers in the affected space the option of renumbering back into your previous IP space? What all of you don't know, is that for the first month we had this CIDR, we could not register hosts on it at NetSol/Verisign, because their core registry did not recognize it. We have been getting F***ed That should have set off some alarm bells and prompted a post to nanog a month ago. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002, Ralph Doncaster wrote: ARIN clients should have the ability to exchange defective goods. It seems ARIN won't do this. And posting to NANOG or similar lists doesn't seem to fix the problem. Sooner or later someone's going to decide to let the lawyers deal with it. I don't think ARIN's resources should be wasted in the courts. ARIN can't change (or even detect) who's filtering what. They likely have no way of knowing in advance if any IP block is filtered anywhere. How many places need to block your IP before you declare the IP bad? Should ARIN announce and test connectivity with some standard suite before giving each allocation? Should the end-user be given some trial period during which they can do this? What happens when ARIN runs out of IPs that don't appear to be filtered by any recognized network? This is an unfortunate pitfall that goes along with portable IP space and BGP. When I got the company's first ARIN block at a previous employer (back in the late 90s), we ran into issues with several large/well known networks ignoring our BGP route. Some were fixed just by doing the RADB thing. Some had to be emailed or phone called before they fixed their filters. This isn't a new problem, and there's no magic solution ARIN can execute...at least not that anyone's come up with so far. ...wondering when we'll hear from Dalph on the matter. :) -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Odd DDoS, anyone else seen this?
On Mon, 25 Nov 2002, Christopher L. Morrow wrote: On Mon, 25 Nov 2002 [EMAIL PROTECTED] wrote: Can anyone think of a reason why this sort of traffic should be routed at all? Does anyone actually drop hosts on to addresses ending in x.x.x.0? I've seen cable modem users have .0 ips. DSL ports too. I was spammed today from a Verizon DSL IP of 4.46.3.0. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: sprint passes uu?
On Tue, 15 Oct 2002, Brian wrote: The interesting part of that to me is that the total number of prefixes in a full feed is in the low 100,000 range, so this still represents a very large percentage of the entire prefix pie. x.x.x.x 4 1239 2396636 438162 6144276100 9w3d47637 x.x.x.x 4 701 3768775 499186 6144276100 1w5d45410 It's hard to know how large a percentage though without knowing how many Sprint customers are also UU customers. i.e. The combination of Sprint and UU customer routes could still be just 47637 prefixes, though I'm sure it's somewhere between that and 47637+45410. It's certainly not 47637+45410, which would falsely suggest that together Sprint and UU have roughly 80% of the internet as customers. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
selective prepends...one more time
From last week's thread on Cogent service and selective prepends, I've compiled a list of transit providers that support BGP communities for selective prepends when propagating routes to peers. sprint cw gblx.net level3 Williams Communications Group internap.com Is anyone aware of others, preferably of similar size to Sprint and CW (and in the US) that support this? I need to choose an additional provider real soon and already have Sprint and CW. We'll be connecting ideally in Orlando, FL, but can take connectivity in most of the bigger cities in FL. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: Cogent service
On Fri, 20 Sep 2002, Dale Levesque wrote: I must agree with everyone else's synopsis. There bandwidth is cheap, and connection is reliable. They however do have some congestion issues and are not very flexible when it comes to special needs. What are these 'special needs' people keep mentioning? What special needs might you have of your transit providers? Speaking of special...having played around a little with the BGP communities supported by CW and Sprint, I'm wondering which other big transit providers (it seems almost a waste to say Tier 1 anymore) support community strings that will let you (the customer) cause them to selectively prepend route announcements to their peers. This seems to be a really handy tool for balancing (or at least trying to balance) traffic across multiple transit providers without having to resort to the sort of all or nothing results you'd get by prepending your announcements to the transit provider, or worse, deaggregating your IP space for traffic engineering. AFAIK, Genuity does not have this. UUNet has a very rudimentary version which allows you to cause them to do prepending to all or no non-customer peers. Sprint and CW do it very differently but allow you to select which peers to prepend to (though you'll likely have to work with several Sprint engineers or get lucky to get it working). If there are others that support the sort of flexibility of Sprint and CW, and have decent T3 level pricing, I'd like to hear about/from them. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: e-mail blacklists (was Re: SPEWS?)
On Thu, 20 Jun 2002 [EMAIL PROTECTED] wrote: On Thu, 20 Jun 2002, J.D. Falk wrote: But spamcop's in specific is still based on spamcop user complaints, and most of the spamcop user complaints I've seen have been grossly mistargetted. How? I find spamcop to be very reliable, and the basis of many actions. Spamcop is a perfect example of garbage in / garbage out. I've had a number of servers in spamcop's blacklist for the following reasons: 1) Local user misinterprets headers and reports one of our own MX's thinking it generated a spam he/she received. We get blacklisted. 2) Remote user gets the same message a few times from one of our users (some tax related documents) and for reasons unknown to us, reports it as spam, and we're blacklisted. 3) Local user runs a mailing list on one of our servers and leaves posting open (yeah...that was a bad idea, but lots of lists still do it). List gets spammed. A list member reports our server, causing it to be blacklisted. This one is actually listed right now, and we've gotten a few why can't I send email to ...? questions from other customers on the same server. The idea of a spam blacklist with an army of contributors is appealing. In theory, it could blacklist large numbers of spam sources, perhaps before they get a chance to hit your servers...but the reality is an army of idiots turning a good idea into an unusable mess. Some sort of hybrid of spamcop with dsbl, where those who screw up have their contributing rights revoked would be far more interesting. There also needs to be some method for intervening when someone screws up rather than having to just wait out expiration of a listing that should never have happened. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
AOL and Sprint
Anyone else unable to reach AOL this morning via Sprint's network? I can get there through CW or UUNet, but not via Sprint. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Controlling Spam to the NOC
On Thu, 23 May 2002 [EMAIL PROTECTED] wrote: ramble You hit it dead on: use all the tools at your disposal, but preemptively whitelist your customers. Unfortunately, the whitelisting isn't always as easy as it sounds. If they are within your IP space, you're good to go, but if they have the rare portable block, or they are multihomed, etc., you need to be more careful. /ramble In Short: Whitelist like crazy, and then blacklist like mad! We do both...but I wouldn't say whitelist like crazy. More like whitelist as needed, and find a blacklist or one of the message body parsing utils you like...or both. For the rare emergency when a customer (or non-customer) needs to talk to our NOC and can't get email through, we have these neat things called telephones. They work pretty well. In fact, I think mine often works too well. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: IP renumbering timeframe
On Mon, 6 May 2002, Stephen J. Wilcox wrote: I think they're on dangerous ground, whether or not their contract says the IPs should be returned if they not only stop routing them but then start contacting third parties that they have no relationship with and ask them to stop routing them with the end result being that your business cannot function then I'd say this looks more malicious than pure business and I'd suggest to them a courtroom might view it that way too. This whole thing sounds fishy. He never passed any traffic to cogent, but he was using their IPs. Why wasn't he using Peer1's IPs? Cogent tried to get them shut down on a sunday? Is there a serious BOFH in Cogent's network monitoring group? I doubt the billing department would be open sunday afternoon to order the disconnect, much less know to suggest contacting Peer1 to ask them to stop routing the space. It sounds like there's an awful lot missing from the story. This is why using provider IP space sucks...but you have to plan accordingly. If you're in dispute and plan to terminate service, start renumbering. I've been there and done that. I've also been on the other end and let a customer have several months to renumber, but that was a special case and they left on relatively good terms. A customer who left without paying their bill would likely not be treated so well. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: anybody else been spammed by no-ip.com yet?
On Fri, 3 May 2002 [EMAIL PROTECTED] wrote: Do you have data on approximate amount of this extra mail bandwidth due to spam per user? Actually lets be more exact, can some of you with 10,000 real user mail accounts reply how much traffic your mail server is using and if you have spam filter, how much (in percentage) of mail were filters. And how big were the filterd spam in comparison to all other regular mails? And if possible how much in amount of disk space was it in comparison to all other emails? Since sendmail applies our dnsbl rules before accepting the message, I can't say how much bandwidth the blocked spam would have used. On a MX that handles mail for several tens of thousands of actual user accounts, it's not unusual for us to deliver ~400k messages and reject anywhere from 200k-500k messages. A few weeks ago we had a several day period during which we rejected 1,000,000 messages/day. The rejected numbers can be somewhat inflated though by the 'alphabet spammers'. I'm not sure what else to call them...but these are the people who try to send mail to every conceivable address @yourdomain. If you run a large mail server, you've probably seen them hit you. When they dump their random address spam on an open relay, that relay gets blacklisted pretty quickly, resulting in large numbers of dnsbl rejected messages that would have eventually bounced as 'no such user' bounces, and likely double bounced. Worse, IMO, than the bandwidth issue (mail from/rcpt to/571 doesn't use that much bandwidth), is the mail server load issue. A couple of open relays pounding on our mail servers trying to deliver a truckload of spam someone dumped on them will drive up the load in no time. I'm seriously considering adapting some existing code to watch syslog data and use kernel packet filtering to cut off connectivity for say 24h from IP's after N dnsbl caused rejections in Y minutes. This should reduce load considerably. While typing this I was just watching the log on one mail server and noticed several rejections/sec from mail.ignacio.k12.co.us. That system is an open relay (listed in several blacklists) and has been trying to deliver mail to atlantic.net since last wednesday. We've rejected from them the following numbers of messages: Wed: 82102 Thur: 286861 Fri: 215779 Sat (so far): 62128 -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: UUNET instability?
On Thu, 25 Apr 2002, Streiner, Justin wrote: Anyone else seeing routing instability through UUNET or have any more details? I saw a significant drop in my inbound and outbound traffic to them around 10:00AM EDT. UUNET has a prompt on their phone menus about I saw the same thing on our UUNET connection. Backbone: Normalhm -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: UUNET instability?
On Thu, 25 Apr 2002, Chris Pace wrote: It was really bad this morning. I had problems with Bellsouth, ATT and Qwest's connection to UUNET. Does anyone know if there is a web site or newsgroup I can get alerts and updates about what is going on with UUNET ? There's www.noc.uu.net, but unless the problem is long lasting or severe enough that it can't be swept under the rug, they don't seem to admit to anything on that page. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
