- NZNOG - lists.nznog.org

Re: [nznog] makana.co.nz spam ?
by Mark Foster 01 Dec '04

01 Dec '04

Their Pri NS appears to have IP 202.27.187.82, which based on traceroute is carried via Telstraclear to Snap. Further, if you whois you'll see that its clearly Snap aka Netaccess Christchurch. You may like to try abuse(a)snap.net.nz as a guess. But i've not heard of them before, if it helps. Mark. On Thu, 02 Dec 2004 13:27:08 +1300, Simon Byrnand <simon(a)igrin.co.nz> wrote : > Hi All, > > Has anyone else receved spam from "Makana Confections" <sales(a)makana.co.nz> > recently ? (Or in the past) > *snipped*

1 0

makana.co.nz spam ?
by Simon Byrnand 01 Dec '04

01 Dec '04

Hi All, Has anyone else receved spam from "Makana Confections" <sales(a)makana.co.nz> recently ? (Or in the past) They seem to be at it again, sending unsolicited "promotions" of their products despite previous complaints. Back in April this year they spammed hundreds of our customers (including me personally) with almost identical material to this latest batch, and at the time I forwared abuse complaints to the only relevant email addresses I could find, including soa(a)saraden.co.nz, postmaster(a)saraden.co.nz and abuse(a)saraden.co.nz who going by domainz records appear to be their webhost. At no time did I ever receive any response. Thanks to the wonders of "private" APNIC entries for NZGATE ranges where the address block that the sending mail server resides, its hard to find much more information ;-) (Hopefully that will change if APNIC goes ahead with making the private entries public again) Anybody heard of these guys ? Sent complaints to them before ? Regards, Simon Byrnand iGRIN Internet

1 0

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

01 Dec '04

In message <20041128083138.GB27487(a)walnut.gen.nz>, Richard Hector writes: >On Sat, Nov 27, 2004 at 12:20:03PM +1300, Ewen McNeill wrote: >> 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 -- [bounces because SPF check failed at ispb MX] > >Perhaps I'm a little confused, but if usera is rejecting mail from >servers that he has arranged to forward him mail, that's his own silly >fault? usera doesn't run the mail servers at ispb (or ispa for that matter). It is ispb's mail servers that are doing the SPF check, and rejecting the message, because it's been forwarded in a way that is not compliant with SPF. Other than complaining to ispb -- and they probably wouldn't even know to do so -- usera/userb can do little to influence the message being accepted or rejected at ispb. Viz: 1. spfprotecteddomain MX -> ispa MX: mail from: user(a)spfprotecteddomain rcpt to: usera(a)ispa Result: message accepted (passes SPF check if one is done) 2. ispa configuration for usera says "forward to userb(a)ispb" 3. ispa MX -> ispb MX: mail from: user(a)spfprotecteddomain rcpt to: userb(a)ispb Result: SPF check fails because ispa MX is not in the SPF from list, and message is rejected (and bounced by ispa MX back to user(a)spfprotecteddomain). SPF's answer to this is that mail servers should rewrite the from address -- complete with lots of magic about how it should be done (still being debated). Rewriting it to be "mail from: usera(a)isap" would work just about as well in practice in most situations (bounces go to the "wrong" place, but bounces are largely broken by all the abuse of them going on anyway). This is what procmail and some other things do. FWIW, this is not a theoritical situation. This is really happening right now. And I ended up relaxing some of my SPF statements as a "work around". As I said in the beginning I'd like to see more ISPs that offer "mail forwarding" services to their customers forward that mail in a way that won't cause SPF rejections further down the track. Like it or not SPF is being implemented, and trying to ignore it will not stop your customers mail being bounced. Ewen

3 2

NZNOG '05 Progress and Logo
by Jamie Curtis 01 Dec '04

01 Dec '04

Hi all, Preparation for the NZNOG conference is progressing well with the organising committee working hard on pinning down the final details of the programme. We are currently aiming to open registrations, along with a new look website, sometime next week. One critical component still missing is a logo for this years conference. If there are any of you who feel like getting creative, please feel free to submit logos to me via e-mail. If your logo is chosen as the best, you can expect much kudos at the bar, possibly along with a few free drinks ! As we need the page ready ASAP, logos will need to be submitted as soon as possible, but no later than first thing Monday. Last years logo can be found on the old site: http://www.nznog.org/2004/ Cheers Jamie ----------------------------------------------------------------------- Jamie Curtis office: G.1.01 WAND Group, Dept of Computer Science phone: +64 7 838 4136 University of Waikato, mobile: +64 21 392 102 Hamilton, fax: +64 7 858 5095 New Zealand email: jamie(a)wand.net.nz -----------------------------------------------------------------------

1 0

Rescue from alligators in the swamp - note from APNIC
by John Tran 30 Nov '04

30 Nov '04

Hello all, First, as a general note, it is worth mentioning that there are several staff at the APNIC Secretariat who keenly follow the discussions on NZNOG. Currently, we have been closely following the discussion on the effects of implementing the 'whois privacy' policy on address ranges in use in New Zealand. This email is intended to clarify some of the issues raised, to provide explanations, and to try to identify a path forward. As there have been quite a lot of issues raised, I apologise in advance for the length of this reply. 1) Creating and changing policies --------------------------------- It is not necessary to be a member of APNIC to be involved in the policy making process. Anyone can propose policy changes and take part in the policy discussions. Also, you dont have to attend the meetings to take part. APNIC provides facilities for people not present to take part in discussions while the meetings are actually taking place. In addition, everyone is welcome to join the APNIC mailing lists where policies are proposed and discussed. The main list used to discuss the management of Internet resources is the Policy Special Interest Group (SIG) mailing list. A description of the Policy SIG is available at: http://www.apnic.net/meetings/archive/sigs/policy.html Details of how to subscribe to this and other APNIC mailing lists is available at: http://www.apnic.net/community/lists/ It is highly recommended that anyone holding resources does subscribe to this list (and others) so that they can voice their opinions and give feedback when policies are circulated for comment. You can also find a list of active policies under discussion at: http://www.apnic.net/docs/policy/proposals/ Feedback and participation in developing policies from the NZ community is very much appreciated. 2) Membership fees and criteria for portable allocations and assignments ------------------------------------------------------------------------ The fees for membership can be found here: http://www.apnic.net/member/feesinfo.html The criteria for a minium allocation (/21*) of portable address space are as follows: - the applicant must have used a /23 from their upstream provider or demonstrate an immediate need for a /23; - the applicant must have complied with applicable policies in managing all address space previously allocated to it; - the applicant must demonstrate a detailed plan for use of a /22 within a year; and commit to renumber from previously deployed space into the new address space within one year. [* it is worth noting that the size of the minimum allocation and the criteria for obtaining an allocation were recently lowered from a /20 to a /21 as a result of input and consensus from the community] More information is here: http://www.apnic.net/docs/policy/add-manage-policy.html#9.3 If you wish to obtain a portable assignment of address space as a multihomed organisation you can apply under the small multi-homing assignment policy. The criteria are: - the requestor must be currently multihomed with provider-based addresses, or demonstrates a plan to multihome within one month; and - agree to renumber out of previously assigned address space. The small multi-homing assignments are available to both members and non-members. 3) National Internet Registries (NIRs) -------------------------------------- APNIC recognises NIRs which operate within certain economies. Prospective NIRs must meet specific criteria and adopt the operational policies detailed in: http://www.apnic.net/docs/policy/nir-criteria.html and http://www.apnic.net/docs/policy/operational-policies-nirs.html 4) Whois database privacy policy -------------------------------------- Details of and the motivations for this policy are documented at: http://www.apnic.net/docs/policy/proposals/prop-007-v001.html In summary, the policy means that all non-portable assignments and non-portable sub-allocations will be private by default. Details of these resources remain registered in the whois database but are just not visible to the public. They can be made visible by the custodian of the allocation object through MyAPNIC, to which all APNIC members have access. 5) Next steps ------------- Under the database privacy policy, all non-portable assignments and non-portable sub-allocations that have not been specifically marked as public have now been made private. However, because some allocations and assignments within certain ranges appear to have been considered 'portable' by default from earlier practices in New Zealand, APNIC will restore the affected ranges from private to public. The ranges in question are: - 202.27.0./16 - 202.36.0.0/16 - 202.37.0.0/16 - 202.49.0.0/16, and - 202.50.0.0/16 Anyone holding addresses from these ranges that they wish to be made private, should contact APNIC helpdesk. The update will be done this week. 6) NZTelecom custodianship -------------------------- In regard to the wider issue of NZTelecom as a custodian of the ranges listed above, APNIC operated in good faith, trying to promote aggregation and provide a clearer framework for the custodianship of address space in New Zealand. That said, clearly there are now major concerns being expressed on this mailing list concerning portability of blocks within these ranges. The APNIC Secretariat will examine the records within these ranges and will work with NZTelecom, affected parties, and the community to find an appropriate solution. The solution will not happen overnight but the process is beginning immediately. Of course, APNIC will keep the New Zealand community fully up to date on the progress of the discussions. The APNIC Secretariat would be happy to assist anyone with concerns. If you want to discuss your concerns with us, please call the helpdesk on +61-7-3858-3188 or send email to <helpdesk(a)apnic.net>. 7) The past and the future -------------------------- Clearly, much of this stems back to a time when the framework for allocating and assigning resources was much less defined than it is today. The RIRs, with the community, are trying to provide a responsible framework for managing resources, both historical and existing resources. Some of you may be aware of the ERX transfer project in which resources in use in this region were previously registered in the ARIN database and are now being transferred to the APNIC database and are now managed by APNIC. More information about this project is available at: http://www.apnic.net/db/erx/ Many other steps are being taken. One such example is the policy recently implemented to support transfers of historical address space: http://www.apnic.net/docs/policy/proposals/prop-006-v001.html Others recently approved by the community, but yet to be implemented are: * Recovery of unused address space: http://www.apnic.net/docs/policy/proposals/prop-017-v001.html * Protecting historical records in the whois database: http://www.apnic.net/docs/policy/proposals/prop-018-v001.html I would strongly urge anyone who is a custodian of Internet resources to read these policies and to contact APNIC if they have any queries. Finally it is worth mentioning that four APNIC staff members will be at the forthcoming NZNOG meeting, and will be happy to meet with people and to provide a forum for discussing these issues. Regards Son ____________________________________________________________________ Resources Services Manager <Son(a)apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk(a)apnic.net Please send Internet Resource Requests to <hostmaster(a)apnic.net> _____________________________________________________________________

3 3

Citynet, TelstraClear, Telecom, Orcon
by Joshua Brady 30 Nov '04

30 Nov '04

Could someone from Citynet, TelstraClear, Telecom, Orcon please contact me off-list please. Regards, Joshua Brady

1 0

IPv6 transit in .nz
by Lincoln Reid 30 Nov '04

30 Nov '04

Hi, Is anyone here able to offer international IPv6 transit in New Zealand currently? Ultimately I would like to start publishing AAAA records for some of our infrastructure, which means there is a little more pressure on to provide connectivity more compelling than through a tunnel broker eg. ~500ms, sometimes lossy, sometimes entirely broken. My experience as an end user through a tunnel broker accessing sites with AAAA records like www.apnic.net or www.isc.org is that the performance is often bad enough for me to kill my IPv6 connectivity to maintain sanity. Our requirements are very modest, even a shared 512 kbit is probably fine as long as it works most of the time. If anyone has any pointers get in touch. Cheers, -- Lincoln Reid Systems Engineer LinuxNet - AS18119 lincoln(a)linuxnet.co.nz Phone: +64 4 939 2200 Fax: +64 4 939 2201

1 0

Outage Notifications in a standardised format
by Jamie Baddeley 30 Nov '04

30 Nov '04

Hi people, I'm looking the various ways and means I get notified of early warnings/network outages, and I'm thinking that there's got to be a better way. This better way would probably involve an agreed information format (e.g XML, RSS etc) between all parties. Even just a standard email template. I'd be keen to herd a working group to come up with a standard mechanism for telling each other that the smoke has leaked out (or is about to), and that the rubber band fell off. Add some funkiness, and letting customers know would be so much easier. As usual, however, the usefulness of this is proportional to the number of network operators who agree to the standard...This is an open request to TelstraClear and Telecom - are you interested in working together on this? Can I have a show of hands from those in the NOG who'd be keen to work together to draft a standardised way of Outage Reporting. If we can get enough people together, and do some planning between now and February, then doing a BOF at the conference in February would be the way to go. And by all means, if such a standard already exists, then please point me in the direction of it.. Hands up? jamie --

1 0

Request for historical info
by Barry Murphy 30 Nov '04

30 Nov '04

Hi, I'm trying to gather some data of prices of the internet for the last 10+ years. What I'm looking for is the following for every year you can remember: Year: Monthly hours: ISP price: Product: ADSL/Dial-up Telecom rental price: Any further historical info would be great too, i.e. when the internet was first introduced as a commercial product in NZ, etc. Please reply off list, I'll be publishing the info and advising at a later stage. Thanks Barry

1 1

RE: [nznog] What characterises an NGN?
by Donald Neal 30 Nov '04

30 Nov '04

> -----Original Message----- > From: Juha Saarinen [mailto:juha(a)saarinen.org] > Sent: Monday, 29 November 2004 12:43 p.m. > To: NZ NOG > Subject: [nznog] What characterises an NGN? > > Wrote a bit about Telecom's NGN variant here: > > http://computerworld.co.nz/news.nsf/UNID/C740B2DD592E9EDDCC256 > F58000FBD33 > > 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. [...]" > > Is it fair to assume that pushing CO functionality to the > network edge > requires an end-to-end managed solution? There seem to be three different questions here. The first concerns what an NGN is. Once upon a time telcos ran phone networks. When they added data services, like X.25, they built separate networks to provide those services. An NGN is about putting together the necessary bits to build a network which carries voice and data over one network instead of several. The pieces tend to include an MPLS core, aggregation devices, and so on. It's tempting to say that they're standard hardware rather than the high-cost proprietary stuff telcos used in the past. But in real life there aren't many really big Junipers outside the carrier space. Anyway, the key point about it is that a telco only has one of it, which provides a range of services. There will be cases where limitations to equipment may dictate how a service can be provided, and others where the telco has some choices. "What the NOG thinks of this approach" may well be influenced by what it is an approach to. It's not clear to me, looking at the article, wha the service is that's being decribed. If the service in question is multipoint VPN's, then it seems to me to make perfect sense that customer routing information has to be shared with the carrier. Otherwise how would the carrier's provider edge routers work out where to send the customer's packets? If the service is point to point tunnelling, that's a different matter. As to whether pushing CO functionality to the network edge requires an end-to-end managed solution, I suspect the real-life answer to be "yes". But with a couple of provisos. The first is that 'end-to-end' for a carrier may not be the same as 'end-to-end' for the customers of the carrier, or for the customers of the customers of a carrier. If a telco is going to sell multiple services over a single piece of wire carrying IP packets, it does make sense for the telco to apply whatever shaping, policing etc, policies it's going to use at the customer premises. I don't immediately see how that could be done without putting a telco-administered box at the customer's premises. But if "A customer can choose to tag their own traffic to the correct QoS value, or Telecom can do this for them in the endpoints", then presumably a customer can mark their own traffic and then have Telecom's box on their premises act simply as Telecom's check that their marking matches whatever the service is supposed to be. The second proviso is really the previous question again. It's quite possible to run lower-quality services over the same, or most of the same infrastructure. I'd be very surprised to see all customers getting the same level of management regardless of what they're paying. All opinions mine only. All comments relate to telco networks in general except where I quote the original article. - Donald Neal Donald Neal |Hydrangea - warning by the Lone Technical Specialist | Ranger's colleague NGN Operations | Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

1 0