- NZNOG - lists.nznog.org

Re: [nznog] Telecom FaxRight
by Kenneth Wells 25 Jul '06

25 Jul '06

TelstraClear's "FaxCheck" was still operational last time I checked - 0508500499 - give that a go. Regards, Kenneth Wells -----Original Message----- From: Antonio Broughton [mailto:anacarda(a)flerwin.net] Sent: Tuesday, 25 July 2006 8:29 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Telecom FaxRight Ian Batterbee wrote: > Does anyone know what happened to Telecom's Faxright service which I'm > pretty sure used to be 0800 108 208 ?. It gives number disconnected at > the moment.. I'm not sure if I have the number wrong or if it has been > shut down. > > yea, it was shutdown i think last month? or something this month... they had a heading about the closure for a cpl months before hand... we are thinking of making a similar one in asterisk for ourselves :P -- Antonio Broughton _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Telecom FaxRight
by Ian Batterbee 24 Jul '06

24 Jul '06

Does anyone know what happened to Telecom's Faxright service which I'm pretty sure used to be 0800 108 208 ?. It gives number disconnected at the moment.. I'm not sure if I have the number wrong or if it has been shut down.

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 24 Jul '06

24 Jul '06

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:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.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-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060629 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.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-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060725 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 24 Jul '06

24 Jul '06

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:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.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-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060629 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.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-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060725 source: NZRR

1 0

Re: [nznog] SMTP Server Callbacks, the Devil or a Godsend?
by Ewen McNeill 24 Jul '06

24 Jul '06

In message <040c01c6af00$812193c0$de0dea3c(a)office.orcon.net.nz>, "Craig Whitmore" writes: >I have been looking into callbacks lately for SMTP (to reduce spam) and have >noticed a few things with a number of large nz sites who send out email. This is the scheme where upon receiving an inbound MAIL FROM:/RCPT TO: the mail server then connects back to the MX for the claimed domain and issues a MAIL FROM:/RCPT TO: as if it were going to send a reply? I'm pretty wary of such schemes because of the potential for looping (eg, A connects to B, B connects to A to verify, A connects to B to verify, ...), and because the "callback" action looks pretty much like an address verification probe for, eg, a spam list. (Once upon a time SMTP had a VRFY action which could be used to confirm addresses, but pretty much everyone turns that off due to abuse.) Aside from that some way of being sure the originator is a "real" address, preferably without requiring a separate connection, is a nice idea. One scheme I've seen a fairly large mail source (Yahoo? AOL? I forget) was to test for postmaster(a)domain instead, on the basis that the address should exist and at least they'd have somewhere to send reports of problems. That seems marginally less bad than trying the originator of the message. >A number of sites send from email addresses which don't exist. Including some newsletter mailouts that I'm aware of. Your (Craig's) list is by no means complete. Personally I'd be reasonable keen to see such mail refused as a general industry policy. Because they inevitably seem to send out (regularly) to large numbers of addresses which ceased to exist a long time ago, or never existed (hotmale.com, anyone?). The ones with valid sender addresses which have, eg, full mailboxse are only marginally less annoying. Especially given that automatic bounce processing systems have existed for a long time. I think using some sort of sender address verification scheme and then papering over it with a whitelist to allow those that fail to still send mail rather misses the point. But then I also think that email is virtually a lost cause these days, at least in the "anyone can forge anything" SMTP form. Ewen

2 1

Spectrum Allocations for Broadband Wireless Access Discussion (with refreshments!)
by Jonathan Brewer 24 Jul '06

24 Jul '06

Hi Folks, InternetNZ have kindly arranged for a neutral venue, webcasting, and refreshments to be provided for a discussion of Spectrum Allocations for Broadband Wireless Access. This discussion is to take place ***Thursday, 27 July*** at InternetNZ, 10th floor meeting room, 5-6:30PM. It will be an informal but structured discussion that will cover the main points of the paper. I think all of our responses will benefit by talking things through over a liquid refreshment or two. Important links: The discussion paper: http://www.rsm.govt.nz/spp/bwa/discussion/index.html InternetNZ location: http://www.internetnz.net.nz/about/contact/ Thursday Night Curry: http://wellington.thursdaynightcurry.com/ (discussion will continue here) Please feel free to contact me or Nick Wallingford of InternetNZ [nickw(a)internetnz.net.nz] if you have any questions. Best Regards, Jonathan Brewer ------------------------- Araneo Limited 230B Left Bank 116 Cuba Street Wellington 6011 Ph: 04 978 7350 Fx: 04 978 7355 http://www.araneo.net.nz/ -------------------------

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 24 Jul '06

24 Jul '06

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. --- OBJECT BELOW CREATED: aut-num: AS38178 as-name: NZRR-AS38178 descr: e-cast descr: APE peering at '192.203.154.31' descr: see Citylink RT job #6482 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS38178 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: brian(a)e-cast.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060725 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS38178 descr: Route set advertised to AS9560 by e-cast - AS38178 members: 202.36.36.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: brian(a)e-cast.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060725 source: NZRR

1 0

SPF record Errors
by Craig Whitmore 23 Jul '06

23 Jul '06

I have compiled a list of Domains which have "Broken SPF Records". These are domains which have SPF records which are invalid due to a number of reasons (explained on the website). This is not a complete record, but a large number of them. The RFC (RFC 4408) says if a SPF record is invalid (and a Mail Server is properly checking for them) then it is valid to reject email from that Domain completely (something which most people won't want on a Domain) Please note there is a LOT of domains listed which have "v=spf2.0 ... etc" which isn't a SPF nor Sender-ID record, and people should fix them up or delete them as they do nothing. Please See: http://spam.co.nz/spf/broken/. There is a number of .nz and NZ related Domains on this list so if you have any relationship with them, you might want to get them fixed. More and More large companies in NZ have correct SPF records (Xtra,Trademe,ICONZ,Datacom) Thanks Craig Whitmore http://www.spam.co.nz

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 23 Jul '06

23 Jul '06

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:AS23655 descr: advertised to AS9439 by Snap Internet Limited - AS23655 members: 132.181.0.0/16^16-29, 202.124.96.0/19^19-29, 203.97.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 203.96.112.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060213 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23655 descr: advertised to AS9439 by Snap Internet Limited - AS23655 members: 132.181.0.0/16^16-29, 202.124.96.0/19^19-29, 210.5.48.0/21^21-29, 203.97.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 203.96.112.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060724 source: NZRR

1 0

WDANZ and Brendan Battles
by Justin Cook 20 Jul '06

20 Jul '06

Hello everyone. Apologies for interrupting your usual off-topic banter, but I'd like to take a moment to talk about something I experienced today. I've promised Dennis from the WDANZ that I would share this experience with other people in the industry. Today the noted spammer Brendan Battles called, despite being asked in the past not to contact me. Brendan was trying to solicit membership to the WDANZ. Again. This is the fourth call I've had from them about it, and it's getting old. After explaining to Brendan that since finding out it was a for-profit organisation rather than a community that I wasn't interested, he proceeded to tell me in an obnoxious tone that he "didn't like my attitude". I told him what I thought of his sales approach and rung off. A few minutes later he called again to blow me a torrent of abuse and I was forced to reiterate my desire not to be contacted. Boy Brendan, your cold-calling is pretty hot. Although I can't confirm the veracity of what the WDANZ is trying to provide to our industry I can only start to guess how ineffective this marketing campaign will be with the rest of you. Unfortunately I've been unable to finger a single service I want from the WDANZ as their offerings seem quite slim, it would appear that their approach is one where the marketing effort outstrips the services delivered. Very disappointing. Also if anyone else has experienced out-of-the-blue abusive phone calls from Brendan Battles please feel free to email me and let off some steam. God knows we can probably have a good laugh. Cheers Justin -- *Justin Cook* Developer http://www.skull.co.nz/ *Skype* justincookskull <skype:justincookskull?call> My status <skype:justincookskull?call>

2 1