- NZNOG - lists.nznog.org

Notification of NZRR Database changes
by NZRR Database Notifications 16 Nov '05

16 Nov '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS24078 as-name: NZRR-AS24078 descr: TradeMe descr: APE peering at '192.203.154.18' descr: see Citylink RT job #2209 descr: WIX peering at '202.7.1.67' descr: see Citylink RT job #359 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24078 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24078 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050408 source: NZRR REPLACED BY: aut-num: AS24078 as-name: NZRR-AS24078 descr: TradeMe descr: APE peering at '192.203.154.18' descr: see Citylink RT job #2209 descr: WIX peering at '202.7.1.67' descr: see Citylink RT job #359 descr: WIX peering at '202.7.0.153' descr: see Citylink RT job #3725 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24078 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24078 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24078 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051117 source: NZRR

1 0

100Mbps Internet for $150 per month
by Regan Murphy 15 Nov '05

15 Nov '05

"It's just a no-brainer these days," says InternetNZ president Colin Jackson of Wellington CBD businesses' attitude to using the CityLink service. "It costs you a few grand for a router and about $150 a month. For that you get [a connection speed of] 100 megabits per second. There's none of this metered bandwidth or anything." http://www.nzherald.co.nz/section/story.cfm?c_id=5&objectid=10355213 I always knew Citylink had a great product, but i never realised it was so cheap... -- Regan

6 6

Notification of NZRR Database changes
by NZRR Database Notifications 13 Nov '05

13 Nov '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9727 descr: advertised to AS9439 by Quicksilver Internet - AS9727 members: 202.89.128.0/19^19-29, 202.37.90.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: pjs(a)quicksilver.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051104 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9727 descr: advertised to AS9439 by Quicksilver Internet - AS9727 members: 202.89.128.0/19^19-29, 202.49.240.0/22^22-29, 202.37.90.0/23^23-29, 202.14.217.0/24^24-29, 202.49.59.0/24^24-29, 202.50.176.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)quicksilver.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051114 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 13 Nov '05

13 Nov '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9872 descr: Route set advertised to AS9560 by Actrix - AS9872 members: 202.154.128.0/19^19-24, 203.96.16.0/20^20-24, 203.96.48.0/20^20-24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: mikej(a)connections.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040809 changed: rpsl-admin(a)nzix.net 20040810 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9872 descr: advertised to AS9560 by Actrix Networks - AS9872 members: 202.154.128.0/19^19-29, 203.96.16.0/20^20-29, 203.96.48.0/20^20-29, 202.36.204.0/23^23-29, 192.100.53.0/24^24-29, 202.49.158.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)actrix.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051114 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 13 Nov '05

13 Nov '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.54.142.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051028 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.54.142.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051114 source: NZRR

1 0

paypal phishing site
by Ian Batterbee 11 Nov '05

11 Nov '05

Have seen a few spams that has all the paypal images (even gets the images from the real paypal site) and lists a bunch of dummy IP addresses that my paypal (I don't have one) account was apparently used from recently, and encourages me to click on the given URL, which goes to [http://www.paypal.update-user-form.com/] Any request to *.update-user-form.com gets redirected to [http://www.paypal.update-user-form.com/webscr.php?cmd=LogIn] and the domain resolves to the following six IP addresses: 68.142.234.[52..57], which all seem to belong to Yahoo. God knows how people get away with registering DNS entries for sites that couldn't be used for anything other than phishing attempts.. I guess someone thought update-user-form.com looked innocent enough.

1 0

Re: [nznog] Paradise.Net SMTP server blocked.
by Simon Byrnand 10 Nov '05

10 Nov '05

At 10:31 10/11/2005, Mark Foster wrote: > > "Your server is not an open relay, but you have a user that is > > infected with a mass-mailer trojan/malware" > > > > (and finally a copy of some message headers that prove it) > > >Was this the honest-to-god reason? Yes, that was a verbatim quote from the message. >I thought that most malware did its own MX lookups and relayed directly? >Aka bypassing the SMTP relay provided by infected-parties ISP? I thought so too, but obviously some don't. >Given the sheer volume of smtp-crud that a lot of people see, it wouldnt >suprise me that large blocks get put in sooner rather than later. > >In some respects though, SORBS's policy is actually reasonably well >thought out. Entries get a TTL of 2 days and if now further 'hits' on the >IP are received, the TTL auto-expires and the block comes off. TTL gets >renewed each time a further report is received. The spamcop list auto-removes you after sometime between 12 and 24 hours too, but the problem as I see it is that they rely on unverified user entered "reports" so potentially you could keep getting unfairly listed over and over without any real comeback... Regards, Simon

2 1

Re: [nznog] Paradise.Net SMTP server blocked.
by Simon Byrnand 09 Nov '05

09 Nov '05

At 16:45 10/11/2005, Andrew Stephen wrote: >On 11/10/05, Lesley Walker <lrw(a)clear.net.nz> wrote: > > Simon Byrnand wrote: > > > Not only that, but the sample message header they provided > > > had many of the message fields obfuscated, including the > > > message id tag and the time, making it extremely > > > > The reason they obfuscate some of the fields is that in some > > cases the report could be going to the spammers themselves, > > and the concern is that spammer will be able to identify the > > user who reported them and exact some kind of revenge. > >Ah, yeah. That happens. I received several death threats after >reporting some spam a year or so ago. Nothing happened (and I didn't >really expect it to) but it does make one wary. In my case however it wasn't a person(s) reporting the message, it was one of their honeypot addresses that the spam was sent to, and they claimed in a later email that the obfuscation was to protect the honeypot address. Fair enough, except it didnt seem to dawn on the guy that if I couldn't work it out from my mailserver logs thanks to their obfuscation then I couldn't find the customer with the trojan to do anything about it, and on the other hand that if I could figure it out by deduction (which I did) that the honey pot address would be in my log files anyway and thus compromised if I were a spammer :) Security by obscurity ? :) Regards, Simon

1 0

Re: [nznog] Paradise.Net SMTP server blocked.
by Lesley Walker 09 Nov '05

09 Nov '05

Simon Byrnand wrote: > Not only that, but the sample message header they provided > had many of the message fields obfuscated, including the > message id tag and the time, making it extremely The reason they obfuscate some of the fields is that in some cases the report could be going to the spammers themselves, and the concern is that spammer will be able to identify the user who reported them and exact some kind of revenge. IIRC, the munging is set on a per-user basis by the users reporting spam. Some Spamcop users will argue that the spammer could be using a database to key the message id and timestamp to the recipient address. (I tend to think this is excessively paranoid, but some vigilante anti-spammers probably have good reason to exhibit this level of paranoia.) The other thing to bear in mind is that they have no way of knowing which ISPs are "spam-friendly" (ie very happy to recieve payment for the bandwidth used by spammers), which many Spamcop users regard as being just as evil as the spammers themselves and completely worthy of blocking. > I strongly suggest that people DONT do SMTP level blocks > using spamcop lists, as they are simply not trustworthy > enough, I only use spamcop as a points scoring mechanism > in spamassassin, I've never trusted it for outright > blocking... Indeed, Spamcop's own advice to users of the list includes the comments: "SpamCop encourages SCBL users to tag and divert email, rather than block it outright" and "The SCBL is aggressive and often errs on the side of blocking mail." (Quoting http://www.spamcop.net/bl.shtml) If anyone wants to get into a discussion with Spamcop about the issues, you could try their news server at news.spamcop.net. If you have time to spare, that is. Lesley W

2 1

Apology - Rod Donald Funeral
by Richard Naylor 09 Nov '05

09 Nov '05

A BIG sorry to Operators who may have been affected by higher than usual traffic this morning. As you know we like to issue pre-event warnings of potential traffic or support issues. Today we supported the streaming of the Rod Donald Funeral Webcast, picking up the load mid-event and using anycast routing to distribute the load. So we didn't get much warning either. The decision was made on the phone as we worked setting things up. While not a huge event, it did produce a higher than normal load. There was a steady 45Mbps coming out of our USA server, peaking to 85Mbps. ISPs *really, really* should peer to avoid this cost and also help us service the international viewers. It reflects badly on them internationally. There are at least 4 more significant events before the end of the year, so Operators are strongly urged to peer. Once again - sorry if your traffic graph got a nasty kink in it today. Rich

1 0