Re: no whois info ?
william(at)elan.net [EMAIL PROTECTED] wrote: [...] Read NANOG archives - Verisign now allows immediate (well, within about 10 minutes) updates of .com/.net zones (also same for .biz) while whois data is still updated once or twice a day. That means if spammer registers new domain he'll be able to use it immediatly and it'll not yet show up in whois (and so not be immediatly identifiable to spam reporting tools) - and spammers are in fact using this feature more and more! This tempts me to hack something into Exim that does a whois on previously-unseen sender domains, and give a deferral if the whois denies existence of the domain. Is this likely to have any meaningful effect? -- Just last week, someone called every morning to speak to President Gore. By Friday, the operator was flustered, and finally snapped, You call every day asking that, and every day I tell you that Mr. Gore lost the election. Why? I just like hearing that. It's a great start for the day!
Re: no whois info ?
[EMAIL PROTECTED] (Peter Corlett) wrote: william(at)elan.net [EMAIL PROTECTED] wrote: [...] Read NANOG archives - Verisign now allows immediate (well, within about 10 minutes) updates of .com/.net zones (also same for .biz) while whois data is still updated once or twice a day. That means if spammer registers new domain he'll be able to use it immediatly and it'll not yet show up in whois (and so not be immediatly identifiable to spam reporting tools) - and spammers are in fact using this feature more and more! This tempts me to hack something into Exim that does a whois on previously-unseen sender domains, and give a deferral if the whois denies existence of the domain. Is this likely to have any meaningful effect? No. It depends too much on (a) the registry and registrar for the domain (b) overall whois availability to that TLD (not everybody uses whois) (c) your connectivity to the whois servers involved (possibly more than one) Yours, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: no whois info ?
Captain's Log, stardate Thu, 09 Dec 2004 15:10:14 -0500, from the fingers of Daniel Senie came the words: snip We have clients complaining about the junk email, junk faxes and junk postal mail that results from these listings. snip I agree, Even the .ie domain registry doesn't add personal information by default. For example, one of the domains I've registered has only the registrant name and the DNS host's name. This is our full .ie whois info: domain: blah descr: BLAH descr: Body Corporate (Ltd,PLC,Company) descr: Registered Business Name admin-c: ABA822-IEDR tech-c: IBH1-IEDR nserver: AUTH-NS1.IRISHBROADBAND.IE nserver: AUTH-NS2.IRISHBROADBAND.IE source: IEDR person: Ken Gilmour nic-hdl: ABA822-IEDR source: IEDR person: Irish Broadband Hostmaster nic-hdl: IBH1-IEDR source: IEDR
Re: no whois info ?
On Fri, 10 Dec 2004, Elmar K. Bins wrote: william(at)elan.net [EMAIL PROTECTED] wrote: [...] Read NANOG archives - Verisign now allows immediate (well, within about 10 minutes) updates of .com/.net zones (also same for .biz) while whois data is still updated once or twice a day. That means if spammer registers new domain he'll be able to use it immediatly and it'll not yet show up in whois (and so not be immediatly identifiable to spam reporting tools) - and spammers are in fact using this feature more and more! This tempts me to hack something into Exim that does a whois on previously-unseen sender domains, and give a deferral if the whois denies existence of the domain. Is this likely to have any meaningful effect? No. It depends too much on (a) the registry and registrar for the domain (b) overall whois availability to that TLD (not everybody uses whois) (c) your connectivity to the whois servers involved (possibly more than one) I disagree, I think this may be ok, but its specifically because its for .com/.net whois (not ok for general TLD). Reasons are: 1. Internic.net / CRSNIC whois has no limit set on number of queries client from particular ip can make before queries are denied (or it may have limit but its set very high) and its data is almost always available and quite fast (but there were some outages). 2. Internic.net data is very brief listing only when domain was registered and which registrar and status 3. If there is a problem getting whois data at the moment, SMTP connection would not be denied but only deferred I think what should be done based on data is: 1. Check creation data and if the domain is very new (not even in whois or in whois but registration date is today or yesterday) then defer it for 48 hours but count the connection and report to some central system. If after one day from that new domain came way too many attempts to send email, then it maybe assumed fairly safely the domain is being setup by spammer. Additionally if there are spam reports that came about the domain then a responsible registrar (like godaddy) would put it on hold and this would be reflected in the domain status. I'll also note that registar has 72 hours in which they can delete newly registered domain if they believe the registration was fraudelent (i.e. stolen credit card) and not have to pay registrar for it - in fact that is quite often what happens to spammer used domains. 2. You probably should not accept email from domains that have any kind of HOLD status (this is the same as domain not deligated in dns) but again this should not be outright denial but deferral (in case its just that somebody forgot to pay registration feee). 3. By checking Internic whois you get a name of the registrar (i.e. opensrs, enom, etc) and can decide that if the registrar is too dirty you do not want to accept email from domain. If enough people do it, this may cause registrar to become more responsible towards who they let register domains. It maybe quite good if several of us come together and create a project to create such whois filtering library for SMTP. This library can then be called from extensions for Sendmail, Postfix, Exim and other popular mailers. I certainly will be willing to help with my whois programming skills but I have no experience (yet) writing extensions for MTAs. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: no whois info ?
Elmar K. Bins [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Peter Corlett) wrote: [...] This tempts me to hack something into Exim that does a whois on previously-unseen sender domains, and give a deferral if the whois denies existence of the domain. Is this likely to have any meaningful effect? No. It depends too much on (a) the registry and registrar for the domain (b) overall whois availability to that TLD (not everybody uses whois) (c) your connectivity to the whois servers involved (possibly more than one) You have a point if I were attempting to do this for all TLDs, but at least for a first cut, I'm only interested in .com/.net. A single query of whois.crsnic.net (and not bothering to follow referrals) would be sufficient to determine the existence of the domain in whois. There's some awful tinpot domain registrars out there where you have to wonder if their whois server is on the end of a dialup link, but fortunately I'm not attempting to access those. Connectivity from here to the CRSNIC server is good and no worse than to any other server I may wish to query for purposes of black- or greylisting. -- The advice given me about Maglites is to hold it out sideways from yourself but at shoulder height, this makes the opponent think you are standing 3 foot to one side of reality. - Rob Adams in the Monastery
Re: no whois info ?
Peter Corlett wrote: There's some awful tinpot domain registrars out there where you have to wonder if their whois server is on the end of a dialup link, but fortunately I'm not attempting to access those. Connectivity from here to the CRSNIC server is good and no worse than to any other server I may wish to query for purposes of black- or greylisting. Doing live queries of domain names like that, on the fly - even if you cache lookup data - will lead to your IP getting rate limited or even blocked by most whois servers, unless you register your IP with them for doing bulk whois lookups. srs
test please disregard
--Rob Crowe [EMAIL PROTECTED]
verizon.net and other email grief
Hi, trying to pin down why so much email isn't making it recently. We see issues with various big ISPs. The most obvious is none of the three UK ISPs I have ready access to can connect to port 25 on relay.verizon.net. (MX for all the verizon.net email addresses). We can ping it (I'm sure it isn't singular?), but we have no more luck delivering email than contacting verizon technical staff, logs suggests we are in day 3 of this. I'm now listening to hold music at International rates - ouch. Have a support call with GXN open on connectivity to hotmail, which seems to vary with UK ISP, but is in general pretty poor from all of them. In general I'd say off topic in Nanog, but there comes a point where you start wondering if the routing is messed up. Am I alone before posting more details. Simon
normally CFP's are off-topic for NANOG but this one's *about* us
Speaking for the program committee, I hope to see submissions from this crowd, as well as faces from this crowd at MIT in July. 'nuf said; read on: SRUTI 2005 Workshop Steps to Reducing Unwanted Traffic on the Internet Sponsored by USENIX http://www.research.att.com/~bala/sruti July 7-8, 2005 MIT, Stata Center, Cambridge, MA, USA. The Internet is under increasing attacks with unwanted traffic in the form of spam, distributed denial of service, virus, worms, etc. Unwanted traffic on the Internet has manifested itself as attacks on many protocols (IP, TCP, DNS, BGP, and HTTP) and popular applications (e.g., Email, Web). Recently, attacks combining multiple exploits have become common. Many solutions have been proposed for specific attacks, some of which have had limited success. SRUTI seeks research on the unwanted traffic problem that looks across the protocol stack, examines attack commonalities, and investigates how various solutions interact and whether they can be combined to increase security. Original research, promising ideas, and steps towards practical solutions at all levels are sought. We look for ideas in networking and systems, and insights from other areas such as databases, data mining, and economics. SRUTI aims to bring academic and industrial research communities together with those who face the problems at the operational level. SRUTI 2005 will be a one and a half day event. Each session chair will play the role of a discussant and present a summary of the papers in the session and a state-of-the-art synopsis of the topic. The workshop will be highly interactive, with substantial time devoted to questions and answers. Submissions must contribute to improving the current understanding of unwanted traffic and/or suggestions to reducing it. The proceedings of the workshop will be published. Relevant topics include: * Architectural solutions to the unwanted traffic problem. * Scientific assessment of the spread and danger of the attacks * Practical countermeasures to various aspects of unwanted traffic (Spam, DoS, worms,...) * Cross-layer solutions and solutions to combination attacks * Attacks on emerging technologies (e.g., sensors, VOIP, PDAs) and their countermeasures * Privacy and anonymity * Intrusion avoidance, detection, and response * Virus, worms, and other malicious code * Analysis of protocols and systems vulnerabilities * Handling errors/misconfigurations that might lead to unwanted traffic * Attacks on specific distributed systems or network technologies (e.g., P2P, wireless networks) * Data mining with application to unwanted traffic * New types of solutions: incentive-based, economic, statistical, collaborative, etc. Program Committee Paul Barford, University of Wisconsin Steven M. Bellovin, ATT Labs--Research Herve Debar, France Telecom RD Mark Handley, University College London Dina Katabi, MIT Balachander Krishnamurthy, ATT Labs--Research Doug Maughan, U.S. Dept. of Homeland Security Chris Morrow, UUNET Vern Paxson, ICIR/ICSI Dawn Song, Carnegie Mellon University Paul Vixie, ISC Steering Committee Dina Katabi, MIT. Balachander Krishnamurthy, ATT Labs--Research. Deadlines Submission deadline: March 30, 2005 (11:59 PM EST, HARD) Acceptance notification: May 3, 2005. Final papers due: May 23, 2005. Workshop: July 7-8, 2005. Submissions All submissions must be in English, must include a title and the authors' names and affiliations. Submissions should be no more than six (6) pages long, and submitted in Postscript or PDF only. Each submission should have a contact author who should provide full contact information (e-mail, phone, fax, mailing address). One author of each accepted paper will be required to present the work at the workshop. For uptodate Web page please see http://www.research.att.com/~bala/sruti
Re: no whois info ?
In an earlier episode I pointed out to the list-resident VGRS person that
the dynamic properties introduced for one marketing purpose would have a
consequence in another problem domain, but no point revisiting that issue.
[EMAIL PROTECTED] (Peter Corlett) wrote:
There's some awful tinpot domain registrars out there where you have
to wonder if their whois server is on the end of a dialup link, but
fortunately I'm not attempting to access those.
The ICANN Registrar agreement has no transactional temporal property
for :43 queries. In fact, quite a few registrars associated with one of
several outsource business models, e.g., the Tucows HRS customers (complete),
the Pool thead customers (partial addr allocation), etc., use common :43
servers.
I've tried to work this problem, but it appears to require cooperation
between isps and registrars, and that's just not happening, and agreement
that persistent (hours or longer) name-to-address associations factor into
the prevelant economic spam business models, and that's just not happening
either as spam-presentation (to the user or the interposing device) is the
problem of choice. Schemes to exhaust the dotted quad space, or exhaust
the dotted string space (*lists generally) just don't help identify one
asset economic spam schemes appear to require to extract value from the
spam-presentation instances -- a return path that works.
So, call the small registrars names as long as you want, and as long as
you don't want to pay for a service, and spend your money elsewhere on
something that works better, for some value of better.
Cheers,
Eric
{registry,registrar,isp}_hat = off
Re: no whois info ?
On Fri, 10 Dec 2004, kent crispin wrote: I disagree, I think this may be ok, but its specifically because its for .com/.net whois (not ok for general TLD). Reasons are: 1. Internic.net / CRSNIC whois has no limit set on number of queries client from particular ip can make before queries are denied (or it may have limit but its set very high) and its data is almost always available and quite fast (but there were some outages). Only works for .com and .net. Which is exactly what I said :) Nevertheless majority of the domains used (including very large number of spammer registered domains) are in .com/.net which is why I think this would be usefull greylisting technique (note that its not good idea for blacklisting unless data other then from whois is available!). I'm going to explore this weekend what it would take to take some of the code I have and make into the kind of library I described (this will require addition of specialized caching database, etc) and then if others are interested I'd like to get together with MTA and/or greylisting spamfilter developers to finish this all up. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: verizon.net and other email grief
On Fri, Dec 10, 2004 at 02:43:21PM +, Simon Waters wrote: The most obvious is none of the three UK ISPs I have ready access to can connect to port 25 on relay.verizon.net. (MX for all the verizon.net email addresses). We can ping it (I'm sure it isn't singular?), but we have no more luck delivering email than contacting verizon technical staff, logs suggests we are in day 3 of this. I'm now listening to hold music at International rates - ouch. I think I can shine a little bit of light on what might be your Verizon problem. Summary: Verizon has put in place an exceedingly stupid anti-spam system which does not work, which facilitates DoS attacks, and which provides active assistance to spammers. Verizon has been told all of this, and it's been discussed on Spam-L. If there's been a response from Verizon, I haven't seen it: and AFAIK the practice continues. Anyone trying to deliver mail there might want to at least skim this to get an idea of the issues they may bump into. Please note that in places this is sketchy because it seems impossible to get Verizon to provide the information necessary to make it otherwise (or correct any errors). Details: When an incoming SMTP connection is made to one of Verizon's MX's, they allow it to proceed until the putative sender is specified, i.e. they wait for this part of the SMTP transaction: MAIL From:[EMAIL PROTECTED] Then they pause the incoming connection. And then they start up an outbound SMTP connection from somewhere else on Verizon's network, back to one of the MX's for example.com. They then attempt to verify that blah is a valid, deliverable address there. Since most people have long since disabled SMTP VRFY, they actually construct a fake message and attempt delivery with RCPT. If delivery looks like it's going to succeed, they hang up this connection (which is rude), and un-pause the incoming one, and allow it to proceed. If delivery looks like it's going to fail, then they also hang up their outbound connection (still rude), un-pause the incoming one, and reject the traffic. This also means that if the MX they try to connect to is (a) busy (b) down (c) unaware of all the deliverable addresses (d) something else, that they'll refuse the incoming message. It also means that if the address that's trying to send mail to Verizon is something like [EMAIL PROTECTED], which is the address that the people at Thule Racks emit support traffic from, but which doesn't accept traffic, that Verizon will deny the message. (Yeah, this isn't very bright on Thule's part, either.) Whoops. This is bad for a whole bunch of reasons: two of the more obvious ones are (a) it's a pathetic anti-spam measure because ANY forged address ANYWHERE will do, and (b) it doesn't scale. Add to that (c) it abuses RCPT because apparently Verizon is unwilling to use VRFY and to accept the decision of many mail server operators to disable it. Oh, and (d) the behavior of their probe systems is nearly indistinguishable from that of spam-spewing zombies, which don't obey the SMTP protocol either. [ (b) is also how it lends itself to DoS attacks. Sure, Verizon could rate-limit the rate at which they make outbound connections, but then attacker X could impose significant delay on mail from domain Y just by forging a boatload of messages purporting to be from addresses in Y to Verizon. If Verizon rate-limits their outbound connections, then any real messages from Y will be stuck in the verification queue along with a kazillion forgeries. And beyond that: other people are foolishly adopting this callback nonsense as well. Slashdot carried a note the other day about a program _designed_ to do this. This allows attacker X to forge messages from domain Y to idiots I1, I2... In, for a very large n, and then stand back as all of them simultaneously try to connect to the MX's for domain Y. General principle: any anti-spam measure that generates more junk SMTP traffic at a time when we're drowning in it is probably a bad idea. ] One thing that's not clear is whether or not Verizon caches any of this information. Doing so might help cut down on DoS attack methods that involve them, but of course it doesn't do anything about those which leverage everyone else who's doing callbacks. And this is unfortunately, not the end of it. A lot of people, including me, are blocking particularly problematic spammer-controlled networks at (a) our border routers (b) our firewalls or (c) our mail servers. In other words, we not only won't accept mail from them, we won't even allow them to connect: we're blocking all IP traffic from them. This prevents them from spamming (at least directly from their own network space); it also prevents them from using their resources to build lists of deliverable addresses to sell to other spammers by poking
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 11 Dec, 2004 Analysis Summary BGP routing table entries examined: 152879 Prefixes after maximum aggregation: 89593 Unique aggregates announced to Internet: 73091 Total ASes present in the Internet Routing Table: 18626 Origin-only ASes present in the Internet Routing Table: 16151 Origin ASes announcing only one prefix:7585 Transit ASes present in the Internet Routing Table:2475 Transit-only ASes present in the Internet Routing Table: 76 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 17 Prefixes from unregistered ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 16 Number of addresses announced to Internet: 1357811304 Equivalent to 80 /8s, 238 /16s and 142 /24s Percentage of available address space announced: 36.6 Percentage of allocated address space announced: 59.2 Percentage of available address space allocated: 61.9 Total number of prefixes smaller than registry allocations: 70601 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:30023 Total APNIC prefixes after maximum aggregation: 14602 Prefixes being announced from the APNIC address blocks: 28078 Unique aggregates announced from the APNIC address blocks:14488 APNIC Region origin ASes present in the Internet Routing Table:2176 APNIC Region origin ASes announcing only one prefix:647 APNIC Region transit ASes present in the Internet Routing Table:332 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 168393472 Equivalent to 10 /8s, 9 /16s and 123 /24s Percentage of available APNIC address space announced: 76.8 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 23552-24575 APNIC Address Blocks 58/7, 60/7, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 86261 Total ARIN prefixes after maximum aggregation:52104 Prefixes being announced from the ARIN address blocks:66033 Unique aggregates announced from the ARIN address blocks: 23747 ARIN Region origin ASes present in the Internet Routing Table: 9767 ARIN Region origin ASes announcing only one prefix:3524 ARIN Region transit ASes present in the Internet Routing Table: 972 Average ARIN Region AS path length visible: 4.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 236478976 Equivalent to 14 /8s, 24 /16s and 98 /24s Percentage of available ARIN address space announced: 70.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647,29695-30719, 31744-33791 ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/7, 72/8, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 28565 Total RIPE prefixes after maximum aggregation:19796 Prefixes being announced from the RIPE address blocks:25446 Unique aggregates announced from the RIPE address blocks: 16691 RIPE Region origin ASes present in the Internet Routing Table: 6109 RIPE Region origin ASes announcing only one prefix:3274 RIPE Region transit ASes present in the Internet Routing Table:1045 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 17 Number of RIPE addresses announced to Internet: 181889536 Equivalent to 10 /8s, 215 /16s and 106 /24s Percentage
RE: verizon.net and other email grief
While I can't speak to what Verizon is using, Both Exim and Postfix have the very same feature called address verification. Its in use at a number of ISPs. My systems reject 1000's of messages every day because of verification failures. Roy Engehausen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rich Kulawiec Sent: Friday, December 10, 2004 9:27 AM To: [EMAIL PROTECTED] Subject: Re: verizon.net and other email grief On Fri, Dec 10, 2004 at 02:43:21PM +, Simon Waters wrote: The most obvious is none of the three UK ISPs I have ready access to can connect to port 25 on relay.verizon.net. (MX for all the verizon.net email addresses). We can ping it (I'm sure it isn't singular?), but we have no more luck delivering email than contacting verizon technical staff, logs suggests we are in day 3 of this. I'm now listening to hold music at International rates - ouch. I think I can shine a little bit of light on what might be your Verizon problem. Summary: Verizon has put in place an exceedingly stupid anti-spam system which does not work, which facilitates DoS attacks, and which provides active assistance to spammers. Verizon has been told all of this, and it's been discussed on Spam-L. If there's been a response from Verizon, I haven't seen it: and AFAIK the practice continues. Anyone trying to deliver mail there might want to at least skim this to get an idea of the issues they may bump into. Please note that in places this is sketchy because it seems impossible to get Verizon to provide the information necessary to make it otherwise (or correct any errors). Details: When an incoming SMTP connection is made to one of Verizon's MX's, they allow it to proceed until the putative sender is specified, i.e. they wait for this part of the SMTP transaction: MAIL From:[EMAIL PROTECTED] Then they pause the incoming connection. And then they start up an outbound SMTP connection from somewhere else on Verizon's network, back to one of the MX's for example.com. They then attempt to verify that blah is a valid, deliverable address there. Since most people have long since disabled SMTP VRFY, they actually construct a fake message and attempt delivery with RCPT. If delivery looks like it's going to succeed, they hang up this connection (which is rude), and un-pause the incoming one, and allow it to proceed. If delivery looks like it's going to fail, then they also hang up their outbound connection (still rude), un-pause the incoming one, and reject the traffic. This also means that if the MX they try to connect to is (a) busy (b) down (c) unaware of all the deliverable addresses (d) something else, that they'll refuse the incoming message. It also means that if the address that's trying to send mail to Verizon is something like [EMAIL PROTECTED], which is the address that the people at Thule Racks emit support traffic from, but which doesn't accept traffic, that Verizon will deny the message. (Yeah, this isn't very bright on Thule's part, either.) Whoops. This is bad for a whole bunch of reasons: two of the more obvious ones are (a) it's a pathetic anti-spam measure because ANY forged address ANYWHERE will do, and (b) it doesn't scale. Add to that (c) it abuses RCPT because apparently Verizon is unwilling to use VRFY and to accept the decision of many mail server operators to disable it. Oh, and (d) the behavior of their probe systems is nearly indistinguishable from that of spam-spewing zombies, which don't obey the SMTP protocol either. [ (b) is also how it lends itself to DoS attacks. Sure, Verizon could rate-limit the rate at which they make outbound connections, but then attacker X could impose significant delay on mail from domain Y just by forging a boatload of messages purporting to be from addresses in Y to Verizon. If Verizon rate-limits their outbound connections, then any real messages from Y will be stuck in the verification queue along with a kazillion forgeries. And beyond that: other people are foolishly adopting this callback nonsense as well. Slashdot carried a note the other day about a program _designed_ to do this. This allows attacker X to forge messages from domain Y to idiots I1, I2... In, for a very large n, and then stand back as all of them simultaneously try to connect to the MX's for domain Y. General principle: any anti-spam measure that generates more junk SMTP traffic at a time when we're drowning in it is probably a bad idea. ] One thing that's not clear is whether or not Verizon caches any of this information. Doing so might help cut down on DoS attack methods that involve them, but of course it doesn't do anything about those which leverage everyone else who's doing callbacks. And this is unfortunately, not the end of it. A lot of people, including me, are blocking
Re: verizon.net and other email grief
On Fri, 10 Dec 2004, Rich Kulawiec wrote: Verizon has put in place an exceedingly stupid anti-spam system which does not work, which facilitates DoS attacks, and which provides active assistance to spammers. The technique discussed is called callback verification and I do not agree that the technique stupid or provides assistance to spammers. I do agree that some of the aspects in how this was implemented by Verizon is not correct and causing problems. Details: When an incoming SMTP connection is made to one of Verizon's MX's, they allow it to proceed until the putative sender is specified, i.e. they wait for this part of the SMTP transaction: MAIL From:[EMAIL PROTECTED] Then they pause the incoming connection. And then they start up an outbound SMTP connection from somewhere else on Verizon's network, back to one of the MX's for example.com. They then attempt to verify that blah is a valid, deliverable address there. Since most people have long since disabled SMTP VRFY, they actually construct a fake message and attempt delivery with RCPT. If delivery looks like it's going to succeed, they hang up this connection (which is rude) If I were them I'd do RSET first and then QUIT instead of direct hangup , and un-pause the incoming one, and allow it to proceed. If delivery looks like it's going to fail, then they also hang up their outbound connection (still rude), un-pause the incoming one, and reject the traffic. Rejection of traffic is not approriate in this case, the greylisting technique should instead be used and they should reply back with 4xx error code (most likely 421 or 451), this allows for retry of email later on instead of outright denial. This also means that if the MX they try to connect to is (a) busy (b) down (c) unaware of all the deliverable addresses (d) something else, that they'll refuse the incoming message. All good reasons explaining why error code should 4xx instead of 5xx as I noted above. It also means that if the address that's trying to send mail to Verizon is something like [EMAIL PROTECTED], which is the address that the people at Thule Racks emit support traffic from, but which doesn't accept traffic, that Verizon will deny the message. (Yeah, this isn't very bright on Thule's part, either.) They are correct in this case. The address entered in RFC2821 MAIL FROM is Bounces-To address and it must accept bounced email and as such it must accept incoming emails. If the address does not accept traffic as you indicated should not be used in MAIL FROM and different adddress from local machine should be used. Please read email RFCs and then you'll understand that Envelope MAIL FROM (despite its name) is not an address that indicate source of email, the source of email address is actually From: header (or in some cases Sender header - which one to use will depend on your situation) This is bad for a whole bunch of reasons: two of the more obvious ones are (a) it's a pathetic anti-spam measure because ANY forged address ANYWHERE will do I agree that it requires verification that connecting machine has right to use given mail-from address as part of its sending email. See SPF. But for current situation it does work just fine and causes number of emails with randomly generated emails to be stopped. , and (b) it doesn't scale. The scalability depends on implementation. Since we have Verizon implementing it, I'm guessing it scales just fine based on the size of their email network. I'll also note that a lot of email is sent from the same address and as long as they cache results of verification it'll not be necessary to do verification each and every time. Add to that (c) it abuses RCPT because apparently Verizon is unwilling to use VRFY and to accept the decision of many mail server operators to disable it. Oh, and (d) the behavior of their probe systems is nearly indistinguishable from that of spam-spewing zombies, which don't obey the SMTP protocol either. Sometimes spammers probe various address before sending email to compile new list of email addresses and they use similar technique, however those are in fact distinguishable because you'll see them probing multiple non-existing address usually in alphabetical order. If email is sent from real working addresses, the callback verification would not look like a spammer probing technique. [ (b) is also how it lends itself to DoS attacks. Sure, Verizon could rate-limit the rate at which they make outbound connections, but then attacker X could impose significant delay on mail from domain Y just by forging a boatload of messages purporting to be from addresses in Y to Verizon. If Verizon rate-limits their outbound connections, then any real messages from Y will be stuck in the verification queue along with a kazillion forgeries. As with many techniques trying to address problems of current email
Re: verizon.net and other email grief
- Original Message - From: Roy [EMAIL PROTECTED] To: Rich Kulawiec [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, December 10, 2004 2:23 PM Subject: RE: verizon.net and other email grief While I can't speak to what Verizon is using, Both Exim and Postfix have the very same feature called address verification. Its in use at a number of ISPs. My systems reject 1000's of messages every day because of verification failures. i've never seen this done with postfix, but i know that exim's default 'address verification' for non-local addresses just checks that the domain in the from is valid and that an mx record exists for it. they also have what they call 'callout verification', which is equivalent to what is being discussed, but the documentation makes the drawbacks painfully clear and suggests that it only be used against hosts within the same organization. i'm not a fan of exim, but it appears that although they've given users the rope, they've been diligent enough to label it appropriately. -p --- paul galyinin
Re: verizon.net and other email grief
--On Friday, December 10, 2004 12:30 -0800 Paul Trebilco [EMAIL PROTECTED] wrote: Christopher X. Candreva wrote: That would be 1000's of other people's servers getting traffic from you because someone forged their address in the spam. You are effectively doubleing the total load spam places on the net. This doesn't scale. How so? Are you maybe confusing reject with bounce? If address verification takes place while the SMTP connection is still up, no forged adresses get messaged, at least not by the server doing the rejecting. The other part is that you CACHE the answer you get (good, bad, or indifferent). I think that SPF+sender address verification is a GOOD thing when properly implemented. Yes it can be a bit of a hassle, but you shouldn't be sending mail you're not prepared to bounce. That said, none of my sites are running a current enough version of Postfix to do this.
Re: verizon.net and other email grief
--On Friday, December 10, 2004 15:38 -0500 Paul G [EMAIL PROTECTED] wrote: - Original Message - From: Paul Trebilco [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 10, 2004 3:30 PM Subject: Re: verizon.net and other email grief How so? Are you maybe confusing reject with bounce? If address verification takes place while the SMTP connection is still up, no forged adresses get messaged, at least not by the server doing the rejecting. oh, so you would be ok with someone joe-jobbing you on their 1 million messages/day spam run and getting 1 million 'verification' connections to your mailserver farm? Far less traffic than the bounces would create at both ends. Yes this doesn't prevent it from happening if the address is real, but that's why I mentioned SPF in my previous email..That helps to verify the sender can send email for a given domain, and if that passes, then you want to see if the sender exists, if both pass then you can go on to other methods. OF course I'd first check blacklists before any of this, but that's my personal preference.
Re: verizon.net and other email grief
- Original Message - From: Paul Trebilco [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 10, 2004 3:30 PM Subject: Re: verizon.net and other email grief How so? Are you maybe confusing reject with bounce? If address verification takes place while the SMTP connection is still up, no forged adresses get messaged, at least not by the server doing the rejecting. oh, so you would be ok with someone joe-jobbing you on their 1 million messages/day spam run and getting 1 million 'verification' connections to your mailserver farm? -p --- paul galynin
Re: verizon.net and other email grief
Paul G [EMAIL PROTECTED] wrote: [...] they also have what they call 'callout verification', which is equivalent to what is being discussed, but the documentation makes the drawbacks painfully clear and suggests that it only be used against hosts within the same organization. No, that caveat is given for *recipient callforward verification* which is dangerous if turned on blindly. I know, I tried it for a very short while :) i'm not a fan of exim, but it appears that although they've given users the rope, they've been diligent enough to label it appropriately. Sender callback verification is a different beast and is highly effective against spam. It does of course not come without its price of false positives caused by misconfigured senders. Unlike other mechanisms, it at least doesn't inconvenience senders who haven't botched their mail system. The only false positives I see are things like web sites that mail from a webserver role account which doesn't have a mailbox. Even so, ecommerce sites are learning to not do this, and ordered goods usually turn up regardless of whether or not an automatically-generated confirmation email arrives. -- PGP key ID E85DC776 - finger [EMAIL PROTECTED] for full key
Re: verizon.net and other email grief
on Fri, Dec 10, 2004 at 12:36:12PM -0800, william(at)elan.net wrote: On Fri, 10 Dec 2004, Rich Kulawiec wrote: Verizon has put in place an exceedingly stupid anti-spam system which does not work, which facilitates DoS attacks, and which provides active assistance to spammers. The technique discussed is called callback verification and I do not agree that the technique stupid or provides assistance to spammers. I do agree that some of the aspects in how this was implemented by Verizon is not correct and causing problems. snip But for current situation it does work just fine and causes number of emails with randomly generated emails to be stopped. Erm. Yeah, it stops them from being delivered to Verizon by shifting half the cost of verification onto the victims. , and (b) it doesn't scale. The scalability depends on implementation. Since we have Verizon implementing it, I'm guessing it scales just fine based on the size of their email network. See above. It doesn't scale when /everyone else/ starts doing it. Callback verification if properly implemented will never generate more junk SMTP traffic as DATA part of SMTP transmission never happens. By the time Verizon's callback servers hang up on us they've already generated more junk SMTP traffic, wasted our resources to protect their customers, and aided spammers doing list validation. Your claim that dictionary attacks are always alphabetical is pretty weak and brings nothing to bear on the actual problem - that by rejecting mail from a given address because of (possibly spurious) verification, they are actually giving the spammers a tool they can use to cull bad addresses from their own lists. The only positive thing I have to say about Verizon's callback scheme is that so far it has not been seen here more than 6 times in a single day in the past two months. So they must be doing some caching, given that at least one of the domains we host has been under joe job outscatter attack for several months running now. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: verizon.net and other email grief
On Fri, 10 Dec 2004 12:36:12 PST, william(at)elan.net said: They are correct in this case. The address entered in RFC2821 MAIL FROM is Bounces-To address and it must accept bounced email and as such it must accept incoming emails. If the address does not accept traffic as you indicated should not be used in MAIL FROM and different adddress from local machine should be used. Please read email RFCs and then you'll Yes - *you* know that the address you put in the MAIL FROM: should be one that you know is willing to accept any bounces you may be about to generate, and *I* know that. The problem is that the spammer (I include A/V companies that still generate rejection notices) knows that as well - and doesn't feel the same need to follow the rules and be a good netizen. Yes, it's a royal pain trying to follow a protocol when you know up front that there's a 70% to 90% chance that the other person is intentionally failing to follow it pgpOpxPsgi6Lm.pgp Description: PGP signature
Re: verizon.net and other email grief
Krzysztof Adamski wrote: On Fri, 10 Dec 2004, Jeffrey I. Schiller wrote: On Fri, Dec 10, 2004 at 12:26:59PM -0500, Rich Kulawiec wrote: One thing that's not clear is whether or not Verizon caches any of this information. It appears that they do some amount of caching. -Jeff It does not appear that they are caching it, here is a sample from my log file: Dec 6 19:18:15 white sm-mta[25976]: iB70IF6n025976: [EMAIL PROTECTED]... User unknown Dec 6 19:18:15 white sm-mta[25977]: iB70IF6n025977: [EMAIL PROTECTED]... User unknown Dec 6 19:18:16 white sm-mta[25976]: iB70IF6n025976: from=, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc006pub.verizon.net [206.46.170.182] Dec 6 19:18:16 white sm-mta[25977]: iB70IF6n025977: from=, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc019pub.verizon.net [206.46.170.68] Dec 6 19:18:16 white sm-mta[25976]: iB70IF6o025976: [EMAIL PROTECTED]... User unknown Dec 6 19:18:16 white sm-mta[25977]: iB70IF6o025977: [EMAIL PROTECTED]... User unknown Dec 6 19:18:16 white sm-mta[25976]: iB70IF6o025976: lost input channel from sc006pub.verizon.net [206.46.170.182] to MTA after rcpt Dec 6 19:18:16 white sm-mta[25976]: iB70IF6o025976: from=[EMAIL PROTECTED], size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc006pub.verizon.net [206.46.170.182] Dec 6 19:18:16 white sm-mta[25977]: iB70IF6o025977: lost input channel from sc019pub.verizon.net [206.46.170.68] to MTA after rcpt Dec 6 19:18:16 white sm-mta[25977]: iB70IF6o025977: from=[EMAIL PROTECTED], size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc019pub.verizon.net [206.46.170.68] What happens when verizon tries to send email to somebody who does the same type of check, does this not create an infinite loop? Not if Verizon treats the antispam[0-9]+ mailboxes in a special manner and answers without a check. And they have to answer that the box exists or things are gonna _really_ break. Doing a quick test using the last antispam[0-9]+ address in my SMTP logs, I got all 250 responses without a more recent call back. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Sincerely requesting help for my Doctoral Research
Dear Respected Participants of Nanog Greetings! I introduce myself as Ananth Chiravuri, a doctoral student at the University of Wisconsin Milwaukee. As part of my doctoral dissertation, I am working on how best to come to a consensus when capturing knowledge, and am studying the effectiveness of two techniques. I am writing to request help because in order for my research to contribute meaningfully, I need the participation of real world experts and not students. The tasks that I have chosen relate to networking and therefore, I am looking for experts or professionals in network management or network design. (An expert would be anyone who has had more than 12-18 months of experience). The experiment will be conducted online using virtual teams and the time required may be at most 3-4 hours asynchronously (you can participate at your convenience). I am willing to customize the report to meet the requirements of your organization and anonymity of participants and the firms will be ensured. The results of this report will indicate an effective technique of capturing knowledge using virtual teams of experts. It may help your firm to use the technique to capture knowledge and come to a consensus at a much faster time, thus saving precious resources and time. Please kindly email me at [EMAIL PROTECTED] or at [EMAIL PROTECTED] if you are interested to participate. I am looking for a total of 50 members (10 teams of five each) for each technique (a total of 100 participants) and therefore, I sincerely request and would highly appreciate if each one of you (and your firms) could help me and give me some of your precious time. Most importantly, your participation will ensure support for academic research in a big manner. Thanking you all in advance. I apologize for any inconvenience, if caused. Happy Holidays! Regards ananth chiravuri Univ of Wisconsin Milwaukee Milwaukee, WI [EMAIL PROTECTED]/[EMAIL PROTECTED] __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
RE: verizon.net and other email grief
On Fri, 10 Dec 2004, Roy wrote: While I can't speak to what Verizon is using, Both Exim and Postfix have the very same feature called address verification. Its in use at a number of ISPs. My systems reject 1000's of messages every day because of verification failures. That would be 1000's of other people's servers getting traffic from you because someone forged their address in the spam. You are effectively doubleing the total load spam places on the net. This doesn't scale. == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: verizon.net and other email grief
On Fri, Dec 10, 2004 at 12:26:59PM -0500, Rich Kulawiec wrote: One thing that's not clear is whether or not Verizon caches any of this information. It appears that they do some amount of caching. -Jeff
Re: verizon.net and other email grief
Christopher X. Candreva wrote: That would be 1000's of other people's servers getting traffic from you because someone forged their address in the spam. You are effectively doubleing the total load spam places on the net. This doesn't scale. How so? Are you maybe confusing reject with bounce? If address verification takes place while the SMTP connection is still up, no forged adresses get messaged, at least not by the server doing the rejecting. -- Best Regards, Paul D Trebilco Systems Administrator Server101.com -- Fast and Reliable Website Hosting! http://www.server101.com/ signature.asc Description: OpenPGP digital signature
(newbie) BGP For Dummies?
Hi, long-time listener, first-time caller... Can anyone recommend a good forum for BGP questions? I've got my copy of the O'Reilly book handy, but having never really worked with BGP before, I find it's not really the best novice-level work. (Or, if questions about weird inter-AS routing scenarios are on-topic here, I'd be glad to bounce my problems around on NANOG.) Thanks! David Smith MVN.net
RE: verizon.net and other email grief
On Fri, 10 Dec 2004, Christopher X. Candreva wrote: That would be 1000's of other people's servers getting traffic from you because someone forged their address in the spam. You are effectively doubleing the total load spam places on the net. That is already what happens when spammer forged your address - you see 1000's people sending you bounces and nastygrams. The real solution is to use some form of protection for envelope mail-from address so that it could not be so easily spoofed and forged. There are currently several proposals on the table on how to do it and some of the proposals are already being used on the internet in experimental ways: SPF (dns records listing ips of mail systems that can send mail with given envelope mail-from domain). For more information see: http://spf.pobox.com http://www.openspf.org http://www.spfhelp.org CSV with MPR records (similar SPF but provides list of mail-server hostnames that can use MAIL-FROM domain, the spoofing of mail-server names is protected based on EHLO by CSV): For more information see: http://www.csvmail.com/draft-otis-marid-mpr-00.html (and for CSV see http://mipassoc.org/csv/index.html) BATV (replacement of your real mail-from address with special private connection-specific address - this allows to /dev/null bad bounces if they come back to you and you did not send the email). For more information see: http://mipassoc.org/batv/index.html SES (predates BATV and similar technique, except that a HMAC encrypted address can confirmed by means of public server which allows email to be dropped at recepient instead of dropped at the source as being bad bounce as with BATV). For more information see: http://ses.codeshare.ca/ -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: verizon.net and other email grief
On Fri, 10 Dec 2004, Jeffrey I. Schiller wrote: On Fri, Dec 10, 2004 at 12:26:59PM -0500, Rich Kulawiec wrote: One thing that's not clear is whether or not Verizon caches any of this information. It appears that they do some amount of caching. -Jeff It does not appear that they are caching it, here is a sample from my log file: Dec 6 19:18:15 white sm-mta[25976]: iB70IF6n025976: [EMAIL PROTECTED]... User unknown Dec 6 19:18:15 white sm-mta[25977]: iB70IF6n025977: [EMAIL PROTECTED]... User unknown Dec 6 19:18:16 white sm-mta[25976]: iB70IF6n025976: from=, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc006pub.verizon.net [206.46.170.182] Dec 6 19:18:16 white sm-mta[25977]: iB70IF6n025977: from=, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc019pub.verizon.net [206.46.170.68] Dec 6 19:18:16 white sm-mta[25976]: iB70IF6o025976: [EMAIL PROTECTED]... User unknown Dec 6 19:18:16 white sm-mta[25977]: iB70IF6o025977: [EMAIL PROTECTED]... User unknown Dec 6 19:18:16 white sm-mta[25976]: iB70IF6o025976: lost input channel from sc006pub.verizon.net [206.46.170.182] to MTA after rcpt Dec 6 19:18:16 white sm-mta[25976]: iB70IF6o025976: from=[EMAIL PROTECTED], size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc006pub.verizon.net [206.46.170.182] Dec 6 19:18:16 white sm-mta[25977]: iB70IF6o025977: lost input channel from sc019pub.verizon.net [206.46.170.68] to MTA after rcpt Dec 6 19:18:16 white sm-mta[25977]: iB70IF6o025977: from=[EMAIL PROTECTED], size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc019pub.verizon.net [206.46.170.68] What happens when verizon tries to send email to somebody who does the same type of check, does this not create an infinite loop? K
Re: verizon.net and other email grief
On Fri, Dec 10, 2004 at 06:03:11PM -0500, Krzysztof Adamski wrote: It does not appear that they are caching it, here is a sample from my log file: ... Well when I tested it (3 hours ago) I connected to them manually while watching my incoming milter log. Indeed they visited immediate and verified my address (with an rcpt to command) and when that succeeded, I got the sender ok in my telnet session. I then broke the connection and tried again. The second time they did not contact my server and gave me a sender ok. It is now about three hours later and I just tried again and they did not contact my server. Now this is the success case where the mailbox exists. I don't know if they cache the non-existence of a mailbox. -Jeff -- = Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice [EMAIL PROTECTED]
The Cidr Report
This report has been generated at Fri Dec 10 21:40:00 2004 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
03-12-04149527 103159
04-12-04 672049850 103159
05-12-04 672118764 103159
06-12-04 -1077937252 103159
07-12-04 -1077936760 103159
08-12-04 672037797 103159
09-12-04 -1077937324 103159
10-12-04 134555056 103159
AS Summary
0 Number of ASes in routing system
0 Number of ASes announcing only one prefix
1405 Largest number of prefixes announced by an AS
AS7018 : ATTW ATT WorldNet Services
0 Largest address span announced by an AS (/32s)
pÐ( :
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 10Dec04 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 149527 1031594636831.0% All ASes
AS18566 7546 74899.2% CVAD Covad Communications
AS4134 831 179 65278.5% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4323 807 228 57971.7% TWTC Time Warner Telecom
AS7018 1405 994 41129.3% ATTW ATT WorldNet Services
AS27364 444 33 41192.6% ARMC Armstrong Cable Services
AS22773 405 20 38595.1% CXA Cox Communications Inc.
AS6197 806 429 37746.8% BNS-14 BellSouth Network
Solutions, Inc
AS701 1226 881 34528.1% UU UUNET Technologies, Inc.
AS22909 415 87 32879.0% CMCS Comcast Cable
Communications, Inc.
AS1239 934 623 31133.3% SPRN Sprint
AS9929 340 34 30690.0% CNCNET-CN China Netcom Corp.
AS17676 382 78 30479.6% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS7843 478 177 30163.0% ADELPH-13 Adelphia Corp.
AS4355 384 99 28574.2% ERSD EARTHLINK, INC
AS6478 435 156 27964.1% ATTW ATT WorldNet Services
AS21502 2733 27098.9% ASN-NUMERICABLE NUMERICABLE is
a cabled network in France,
AS4766 531 268 26349.5% KIXS-AS-KR Korea Telecom
AS14654 2626 25697.7% WAYPOR-3 Wayport
AS9443 362 113 24968.8% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS15557 371 126 24566.0% LDCOMNET LDCOM NETWORKS
AS6140 373 131 24264.9% IMPSA ImpSat
AS721 1039 803 23622.7% DNIC DoD Network Information
Center
AS25844 244 17 22793.0% SASMFL-2 Skadden, Arps, Slate,
Meagher Flom LLP
AS2386 847 622 22526.6% ADCS-1 ATT Data
Communications Services
AS1221 790 567 22328.2% ASN-TELSTRA Telstra Pty Ltd
AS6198 434 221 21349.1% BNS-14 BellSouth Network
Solutions, Inc
AS4814 2106 20497.1% CHINA169-BBN CNCGROUP IP
network¡ªChina169 Beijing
Broadband Network
AS5668 417 213 20448.9% CIH-12 CenturyTel Internet
Holdings, Inc.
AS9583 554 358 19635.4% SIFY-AS-IN Sify Limited
AS15270 232 38 19483.6% PDP-14 PaeTec.net -a division
of PaeTecCommunications, Inc.
Total 16985 7516 946955.7% Top 30 total
Possible Bogus Routes
24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o
Halifax Cable Ltd.
24.246.0.0/17AS7018 ATTW ATT WorldNet Services
24.246.38.0/24 AS25994 NPGCAB NPG Cable, INC
24.246.128.0/18 AS7018 ATTW ATT WorldNet Services
64.17.0.0/18 AS174 COGENT Cogent/PSI
64.17.32.0/24AS5024 BRIDGE-75 BridgeNet, LC
64.17.33.0/24AS5024 BRIDGE-75 BridgeNet, LC
