- NZNOG - lists.nznog.org

Hector Protector
by Peter Macaulay 29 Nov '04

29 Nov '04

Off topic, but be charitable. Netsafe have launched their cybersafety ambassador http://www.netsafe.org.nz/hector_protector/hector_protector_default.aspx Please give it a work out. It is pretty important that they have this right, the last thing we want it to have a kid's safety tool able to be hi-jacked. I am happy to pass on comments. -- Peter Macaulay Executive Director InternetNZ Direct +64 4 495 2113 Skype petermacaulay Mobile +64 21 488 485 -- Peter Macaulay Executive Director InternetNZ Direct +64 4 495 2113 Skype petermacaulay Mobile +64 21 488 485

7 8

The Lycos "anti spam screen saver"
by Juha Saarinen 29 Nov '04

29 Nov '04

http://www.theregister.co.uk/2004/11/26/lycos_europe_spam_blitz/ http://news.bbc.co.uk/2/hi/technology/4051553.stm Tempting as it may be to fight abuse with abuse... it doesn't seem right. -- Juha

3 2

What characterises an NGN?
by Juha Saarinen 28 Nov '04

28 Nov '04

Wrote a bit about Telecom's NGN variant here: http://computerworld.co.nz/news.nsf/UNID/C740B2DD592E9EDDCC256F58000FBD33 I'm curious as to what the NOG thinks of this approach. If I look at: http://www.iec.org/online/tutorials/next_gen/ an NGN is defined as: "The next-generation network seamlessly blends the public switched telephone network (PSTN) and the public switched data network (PSDN), creating a single multiservice network. Rather than large, centralized, proprietary switch infrastructures, this next-generation architecture pushes central-office (CO) functionality to the edge of the network. The result is a distributed network infrastructure that leverages new, open technologies to reduce the cost of market entry dramatically, increase flexibility, and accommodate both circuit-switched voice and packet-switched data." Is it fair to assume that pushing CO functionality to the network edge requires an end-to-end managed solution? -- Juha

4 4

Re: Fw: [nznog] Rescue from alligators in the swamp
by Ewen McNeill 28 Nov '04

28 Nov '04

In message <Pine.LNX.4.56.0411281830110.22205(a)green.darkmere.gen.nz>, Simon Lyall writes: >Currently I can get a domain for less than $US 20 per year and that will >get injected in the "DNS routing table" of every provider in the world. >I fail to see why a block of IP addresses should cost more. (a) scarcity: the number of possible IP addresses (4 billion) is rather less than the number of possible domain names (37 ** 63 per name segment) (b) impact on other people's systems: a DNS delegation just sits quitely on a couple of DNS servers in a corner, minding its own business, until someone happens to ask about it; a prefix advertised into the global routing table ends up occupying space in every router in the world with a "full table" and being shuttled around between them fairly often. More DNS delegations means bigger hardware at Verisign (or whoever); more prefixes (eventually) means bigger hardware for all routers that make up the Internet. 2 ** 24 (all possible /24s advertised) is a big number, even at only 64 bytes per routing entry (2 ** 30 bytes of memory). (c) volume: a block of IP addresses consists of multiple addresses; at the US$1250/year mark, that's over 1000 usable addresses. If you were to get 1000 $20 domain names, it'd cost more than US$1250/year :-) (d) scale: the many millions of .com domain names pay for the registry; the few thousand APNIC members need to pay for APNIC to run With all that said, I do sympathise with those with smaller-than-/22 requirements for whom portability and/or the ability to multihome would be useful. And if there's some appropriate way that smaller applications can be fitted within APNIC's requirements it'd be worth considering. However my recollection of what the University of Waikato was doing was that it was largely making allocations along the lines of the proposed "national internet registry" -- at least from the point of view of those receiving the allocations -- and 10 years later, it didn't turn out quite as smoothly as one might have hoped. So if it is done some thought will need to be given as to how one will ensure the "portable" assignments will remain "portable" for an extended period of time. Ewen

3 4

Rescue from alligators in the swamp
by FX Networks 28 Nov '04

28 Nov '04

Given today's discussion about address space etc, FX Networks is prepared to allocate equivalent address space to any ISP that is affected by this policy. reply to this address offlist if you wish to stop using old swamp space.

12 16

Fw: [nznog] Rescue from alligators in the swamp
by Keith Davidson 28 Nov '04

28 Nov '04

I agree in principle with Joe, APNIC are pretty easy to deal with, and for any reasonable robuts requirer of numbers, the costs are hardly prohibitive at US$2,000 one-off, plus US$1,250 per annum. But I guess the argument is that some people have a class C or 2 that they pay nothing for currently and would like to continue to pay nothing. As I said in my previous email, InternetNZ would be happy to step up to the plate if there really is a need - but I doubt we'd be in the business of supplying free number blocks. Keith Davidson Joe Abley stated: > As far as I can see, it's APNIC's job, and they're doing it pretty well > already. > > There seem to be a lot of people assuming that APNIC are hard to deal with > (or that the policies are unreasonable) without ever having tried to deal > with them, or to find out what the policies actually are. > > The economics are pretty simple for ISPs and largish multi-homed > companies: you can pay the cost of renumbering every time you change > provider, or you can pay the membership fees at APNIC and obtain > provider-independent resources. Choose the option that suits your budget. > > Regardless of how much someone might think that every two-person company > deserves provider-independent address space, the unfortunate reality is > that this doesn't scale (and the problem is the routing system, not > address space scarcity). > > > Joe

6 6

Notification of NZRR Database changes
by NZRR Database Notifications 28 Nov '04

28 Nov '04

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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: Notification of NZRR Database changes (fwd) - Date: Mon, 29 Nov 2004 09:57:27 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0411290955550.12055(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW DELETED: route-set: AS9560:RS-ROUTES:AS5767 descr: Route set advertised to AS9560 by Xxx Ltd - AS5767 members: 222.43.45.0/22^22-27 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)lpnz.org mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041129 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 28 Nov '04

28 Nov '04

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: route-set: AS9560:RS-ROUTES:AS5767 descr: Route set advertised to AS9560 by Xxx Ltd - AS5767 members: 222.43.45.0/22^22-27 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)lpnz.org mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041129 source: NZRR

1 0

Re: SPF and mail forwarding (was Re: [nznog] Sendmail Question)
by Ewen McNeill 27 Nov '04

27 Nov '04

In message <8AC558B6BC09CD42BCAF3C667E2A88CC0FC838(a)red.IFM.local>, Philip D'Ath writes: >Ewen McNeill writes: >>It would be very helpful if operators that provide a mail forwarding >>service (eg, just about every ISP that provides mail services) were to >>do the forwarding in a SPF-compatible manner. > >Wouldn't it be easier to just get those people using SPF that forward >through an ISP to include their ISPs server in the permitted list (which >is what we do)? Alas, this doesn't solve the problem except if you do what I resorted to doing -- for now anyway -- and say "the mail could come from any mail server I guess" ("?all" at the end of the SPF record). Why? To take an actual recent example, I host the Wellylug mailing list and website. The Wellylug website has a feature whereby users can subscribe to "meeting reminders", sent out by email shortly before the monthly meetings. usera(a)ispa was one address so subscribed. Unfortunately usera(a)ispa actually forwards mail to userb(a)ispb, without rewriting the envelope from address -- unknown to anyone else until the mail bounced because the SPF check failed (due to the message now coming from a mail server which wasn't in the SPF list for the domain in the envelope from). Given N subscribers to such a list, at M ISPs, the list of "mail servers the mail might come from" soon grows without bound, especially if one considers that the mail may be forwarded more than once (and yes, I encounter multiple forwards fairly often). As I said, this "what happens to forwarded mail" issue is the single biggest (and most contraversal) problem with SPF. And given that more sites are doing SPF checks it would be very helpful if more ISPs that provide mail forwarding services to their customers did so in a SPF-compatible way. Ewen PS: You might argue that users subscribing to such services should subscribe their final destination address, rather than one that forwards on to another account. However even ignoring the reasons why one might wish to subscribe an address the forwards somewhere else, the chances of all users acquiring such clue to do so seems... low.

2 1

SPF and mail forwarding (was Re: [nznog] Sendmail Question)
by Ewen McNeill 27 Nov '04

27 Nov '04

In message <001801c4d402$0e7ad2d0$0100000a(a)lennons>, "Lennon - Orcon" writes: >We have SPF and SRS implemented on our email servers and yes it does work. Unfortunately there are also a considerable number of systems (including in New Zealand) which forward mail without rewriting the envelope from address, which is required by SPF. This means that when the mail is forwarded it suddenly appears to be coming from a mail server that isn't authorised to send messages for that domain, which results in it being rejected and bounced back to the originator. I've had to relax the SPF statements for some of the domains that I manage in order to compensate for this problem (changing from "-all" to "?all" -- ie, "won't come from anywhere else" to "umm, I guess you might see it from some others too"). It would be very helpful if operators that provide a mail forwarding service (eg, just about every ISP that provides mail services) were to do the forwarding in a SPF-compatible manner. Something like procmail's approach (forward message on with envelope from of the account triggering the forward) is sufficient -- you don't have to do SPF's convoluted envelope from rewriting if you don't want to. I suspect this issue (mail forwarding) will continue to be the biggest obstacle to widespread SPF adoption for quite some time. Ewen

3 2