- NZNOG - lists.nznog.org

Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by Michael Hallager 20 Oct '04

20 Oct '04

> This makes a lot of sense, though, technically. Why connect the user at > 8Mbits/sec down and churn out a boatload of RF bollocks from the copper, > when they're only buying a 256Kbits/sec "broadband" connection? May as > well make it 256Kbits/sec right at the start. This will probably enhance > overall network stability somewhat. It does lead automatically to point 3, > however... Good point. Here I have to use two micro filters in series to have a useable phone. (On the ADSL line). Anyone else have this experience? Michael Hallager

1 0

RE: [nznog] FYI: Telecom changes the ADSL playing field again...
by Regan Murphy 20 Oct '04

20 Oct '04

>From: Juha Saarinen [mailto:juha(a)saarinen.org] >Sent: Thursday, 21 October 2004 9:39 a.m. > >What's so badly b0rk3d about DSLAM rate-limiting >and the new QoS implementation that causes latency >to jump like that? Anyone know? "QoS also provides mechanisms for the network to control the delay characteristics (both latency and jitter) of high-priority traffic. Together, prioritization and delay control enable the transmission of real-time voice and video streams." The key word there is "control" (not "reduce" or "limit"). Maybe the latency is applied by design rather than being a fault of the DSLAMs. -- Regan

1 0

Re: Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by Jonny Martin 20 Oct '04

20 Oct '04

> What's so badly b0rk3d about DSLAM rate-limiting and the new QoS > implementation that causes latency to jump like that? Anyone know? If they're dropping the DSL line rate down to plan speed then your bits will take longer to wander to the exchange. It makes quite a significant difference when moving from 8 odd Mbit/s down to 256kbit/s downstream. Can't really take jibes at Telecom for this. If they are taking this approach, then the slower line rates will also mean less RF inteference in the cable binders, which means more robust [albeit slow and piddly] DSL connections. This is how most, if not all, providers work in Australia. Cheers, Jonny.

1 0

RE: Voyager changing AS number
by Booker, Chris 19 Oct '04

19 Oct '04

Hi, Notification that AS4740 Voyager will change to AS703 (MCI Asia Pac) on Thursday 21/10/2004 at 05.30. I am writing to you as the contact point for peering between your AS and our legacy AS 4740 (Voyager) at the Auckland Peering Exchange. If you are not the best contact for peering in your organisation I would appreciate it if you could pass this e-mail on to the right person. MCI acquired Voyager some time ago and we have recently built a new hub in Auckland. We are migrating our peering links to the new site. As part of the move we would like to change the AS on our side to AS703. Our routing policy with respect to your AS will remain the same - we will treat you as a national peer. We will advertise our New Zealand prefixes to you and we will advertise your prefixes to our New Zealand customers. Our peering committee is currently reviewing our peering arrangements in New Zealand and you may hear from a member of our engineering team in the future with regards to that review. Our proposed date time for migration is this Thursday at 0500 New Zealand time. The only change required at your end should be for you to change the remote AS from 4740 to 703. Our IP address will remain the same. I'd appreciate it if you could contact me to let me know if this works for you. Thanks for your time. Regards Christopher Booker Implementation Engineering MCI Australia Email <mailto:chris.booker(a)au.mci.com> chris.booker(a)au.mci.com Tel: + 61 2 9434 5967 Fax: + 61 2 9434 5970

1 0

Invitation to Cisco ISP Update Seminar
by Arron Scott 19 Oct '04

19 Oct '04

Hi all I have asked the List owner for his opinion on whether this may be construed as sales content, so I hope this does not find dis-favour with anyone. Cisco has our primary ISP Consulting Engineer for Australia/New Zealand in Auckland next week, and would be please to invite any ISP staff to attend the following Product Update and Technology Seminar. Attendance is at no cost, and morning tea is included. Please RSVP to browns(a)cisco.com if you would like to attend. ISP's Technology Update Dear All Cisco systems is pleased to invite you a ISP Technology Update Date: Wednesday 27th October Time: 9am to 12.00 Location: Level 16, ASB Building , 135 Albert Street, Auckland During this update we will cover; . IOS software enhancements . 7301 and 7206 NPE-G1. . 10K with PRE-2. . BRAS and LNS Platform update . New RADIUS functionality . Policy management and integration . SSG enhancements . Netflow developments . Core routing update . CRS-1 and IOS-XR . 12000 update RSVP: browns(a)cisco.com We look forward to your participation Arron Scott (CCIE #4099) Phone: +64(9)3551951 Systems Engineer Mobile: +64(21)883163 Cisco Systems New Zealand Ltd. Fax: +64(9)3584442 Level 25, 135 Albert St, Auckland eMail: ascott(a)cisco.com

1 0

SPF Records
by Craig Whitmore 19 Oct '04

19 Oct '04

Hi folks. We have noticed a number of domains in NZ have entered in their NS's domain.co.nz IN TXT "v=spf1 mx -all" This means domain.co.nz will never attempt to send emails at all. (but valid emails are trying to be sent). I've talked to a couple of domain holders who had this and they've fixed them but most said it was done ages ago and they where playing and never expected it to catch on (but it has a lot looking at the number) We (Orcon) have started to use SPF (for testing inbound email) and found it helps with identifying spam. _ALOT_ of people have published valid SPF records. Thanks Craig Whitmore Orcon Internet

11 14

Re: [nznog] SPF Records
by Ewen McNeill 18 Oct '04

18 Oct '04

In message <200410190425.i9J4PvGX007457(a)mailserv.waikato.ac.nz>, "Barry Murphy" writes: >I've wanted to setup SPF in the past but have always wondered what happens >when you have a roaming user sending via paradise for example. The best solution for roaming users is (SASL authenticated) relaying via a central mail server that is listed with SPF. Most commonly used mail clients (and some mail servers) will do SASL authentication these days, and many MTAs can be configured to do SALS authenticated mail relaying. Pushing mail through a central mail server like this is also useful if you are doing other processing on that mail server (eg, statistics, storing copies of messages, etc). >Would one need to know every internet facing ip for all ISP's mailservers? SPF also allows for "include" options, so that you can include (by reference) the SPF records published by the ISPs that are being used. You could, eg, "include" the SPF records of all ISPs used by roaming users. It'd be looser than ideal, but still much better than nothing. If that still isn't sufficient (eg, you have roaming users doing direct-to-remote-server SMTP), you could perhaps list all those ISP dialup subnets (in CIDR fashion). Again this is not ideal, but narrowing it down to a few /22s or even /20s compared with "the whole internet" is still an improvement. With some combination of these it should be possible to list a "much better than nothing" SPF record and then focus on tidying things up so it can be tighter (perhaps eventually down to just "v=spf1 mx -all"). More details at the SPF wizard: http://spf.pobox.com/wizard.html?mydomain=example.com Ewen

1 0

RE: [nznog] Mailwasher and its Forged Bounces
by neil gardner 18 Oct '04

18 Oct '04

Longtime listener, first time poster (on this topic anyway) _IF_ it's possible to reliably (and easily) identify the MailWasher bounces, why not just use that to identify customers using it, and block them from your mail server for a while (Hell, even disable their account perhaps) BUT, and this is the important bit, Send an email to the MW developers telling them that as an ISP you are blocking customers that use their software in this way. Suggest that users of their software will find their Intarwebthingy disabled. Sure the developers may not like taking out neat features, but they probably won't like fielding calls from users who get their net killed because of their product either. Cheers - N. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

3 2

Mailwasher and its Forged Bounces
by Lennon - Orcon 18 Oct '04

18 Oct '04

I've been looking lately and a "large" number of double bounces to postermaster are caused by people who use "MailWashers" to Bounce Spam. I rmember the days when I could read every message to postmaster(a)isp.co.nz They are quite easy to spot as they all have the format of: mail.local: unknown name: username 550 username(a)domain.co.nz ... User unknown Coming from MAILER-DAEMON(a)domain.co.nz (usually the ISP's one) (and forging the email (which I presume is against all ISP's T&C) In mailwashers FAQ it says: ------- Do the spammers know I am bouncing email? No, spammers do not know you are bouncing messages. Bounced messages look just like a returned mail message you would receive if you sent an email to an incorrect address. --------- If I can tell if someone if using mailwasher.. why cannot the spammers? Even so I would think 99.9% of all emails bounced via this program don't get back to the spammers anyway (they don't use proper from addresses or use someone else's domain to send from (anyone in NZ using/looking at using SPF? to stop this type of thing) What I am trying to say (if not very well). What do people think of this feature of mailwasher. I've emailed the writer a few times for comments over the last few years and heard nothing from him. Have ISP's complained to uses using it? stopped people using it? or what? Thanks Craig Whitmore

12 19

Ihug Prefix list update
by Sainesh Singh 17 Oct '04

17 Oct '04

Please update domestic filters for Ihug. APE details: AS7657 192.203.154.36 192.203.154.37 Updated list can be found at: http://www.ihug.net/ihug-prefix-list and is included below. Cheers, Sainesh Singh Ihug Engineering ip prefix-list ihug-networks permit ip prefix-list ihug-networks description ihug peering prefix-list contact: noc(a)ihug.co.nz : Updated 2004-10-18 ip prefix-list ihug-networks permit 192.107.113.0/24 ip prefix-list ihug-networks permit 202.21.130.0/24 ip prefix-list ihug-networks permit 202.21.136.0/23 le 24 ip prefix-list ihug-networks permit 202.36.44.0/24 ip prefix-list ihug-networks permit 202.36.94.0/23 le 24 ip prefix-list ihug-networks permit 202.36.230.0/24 ip prefix-list ihug-networks permit 202.36.231.0/24 ip prefix-list ihug-networks permit 202.37.182.0/24 ip prefix-list ihug-networks permit 202.49.33.0/24 ip prefix-list ihug-networks permit 202.49.46.0/23 le 24 ip prefix-list ihug-networks permit 202.49.63.0/24 ip prefix-list ihug-networks permit 202.49.148.0/23 le 24 ip prefix-list ihug-networks permit 202.49.176.0/23 le 24 ip prefix-list ihug-networks permit 202.49.178.0/24 ip prefix-list ihug-networks permit 202.49.180.0/23 le 24 ip prefix-list ihug-networks permit 202.49.186.0/24 ip prefix-list ihug-networks permit 202.49.249.0/24 ip prefix-list ihug-networks permit 202.50.84.0/24 ip prefix-list ihug-networks permit 202.50.103.0/24 ip prefix-list ihug-networks permit 202.50.188.0/22 le 24 ip prefix-list ihug-networks permit 202.50.255.0/24 ip prefix-list ihug-networks permit 203.96.192.0/19 le 24 ip prefix-list ihug-networks permit 203.109.128.0/17 le 24 ip prefix-list ihug-networks permit 203.109.130.0/24 ip prefix-list ihug-networks permit 203.109.132.0/22 ip prefix-list ihug-networks permit 203.109.133.0/24 ip prefix-list ihug-networks permit 203.109.134.0/24 ip prefix-list ihug-networks permit 203.109.135.0/24 ip prefix-list ihug-networks permit 203.109.144.0/20 ip prefix-list ihug-networks permit 203.109.157.0/24 ip prefix-list ihug-networks permit 203.109.192.0/21 ip prefix-list ihug-networks permit 203.109.198.0/24 ip prefix-list ihug-networks permit 203.109.199.0/24 ip prefix-list ihug-networks permit 203.109.230.0/24 ip prefix-list ihug-networks permit 203.118.128.0/18 le 24 ip prefix-list ihug-networks permit 203.118.144.0/20 ip prefix-list ihug-networks permit 203.118.160.0/20 ip prefix-list ihug-networks permit 203.118.164.0/22 ip prefix-list ihug-networks permit 203.118.168.0/21 ip prefix-list ihug-networks permit 203.173.128.0/17 le 24 ip prefix-list ihug-networks permit 203.173.170.0/23 ip prefix-list ihug-networks permit 203.173.192.0/19 ip prefix-list ihug-networks permit 203.173.224.0/20 ip prefix-list ihug-networks permit 203.173.240.0/21 ip prefix-list ihug-networks permit 210.55.110.0/24 ip prefix-list ihug-networks permit 210.55.184.0/24 ip prefix-list ihug-networks permit 210.55.202.0/23 le 24 ip prefix-list ihug-networks permit 210.55.248.0/21 le 24

1 0