November 2004 - NZNOG - lists.nznog.org

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

RE: SPF and mail forwarding (was Re: [nznog] Sendmail Question)
by Philip D'Ath 26 Nov '04

26 Nov '04

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)? In which case, it is more an issue of educating people who use SPF to include all servers, rather than getting every provider to change their email system. -----Original Message----- ... 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. ...

1 0

Sendmail Question
by Dan Clark 26 Nov '04

26 Nov '04

Hi Guys, Just wondering if anyone has seen the ability to configure sendmail to match from address to the msg id field (after the @) or weather or not it should do this by default. eg: Nov 26 10:55:24 mail sm-mta[15318]: iAPLtBa7015318: from=<forest.stein_rk(a)fyna.com.au>, size=982, class=0, nrcpts=1, msgid=<53fc01c4d339$34ac1af3$45006654(a)africon.co.za>, proto=SMTP, daemon=MTA, relay=[65.126.46.48] I would imagine a hell of alot of SPAM would be returned if our mail server was matching @fyna.com.au with the @africon.co.za and finding that they dont match? I hope I'm on the right track here. Regards Dan Clark

4 3

RE: [nznog] [Inetnum object]
by Donald Neal 26 Nov '04

26 Nov '04

> David Robb wrote: > > >I just got this from APNIC. Anyone else get one? > > > >My initial reaction is "say WHAT!?" > > > >Are Telecom trying to assert authority over IP space which > I'd like to see > >a whole lot of justification as to why it's "theirs". > > One simple answer is that it long has been, and before that was held by The University of Waikato. That Telecom hold a lot of New Zealand's address space isn't a new issue. (See, for instance, the archive for this list for June 1998.) - Donald Neal Donald Neal |Presbyopia - inability to see what Technical Specialist | bishops are for. Operations Engineering | 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." ------------------------------------------------------------------------------

9 8

[Inetnum object]
by David Robb 25 Nov '04

25 Nov '04

I just got this from APNIC. Anyone else get one? My initial reaction is "say WHAT!?" Are Telecom trying to assert authority over IP space which I'd like to see a whole lot of justification as to why it's "theirs". ---------- Forwarded message ---------- Hello, It has been brought to our attention that your organisation's maintainer is currently protecting the following resources: inetnum: 202.49.252.0 - 202.49.255.255 <stuff skipped> However NZTelecom has full authority over the following blocks: 202.27.0.0/16 202.36.0.0/16 202.37.0.0/16 202.49.0.0/16 202.50.0.0/16 Therefore as these assignments are from NZTelcom's blocks in one week's time the maintainer protecting these assignments will be changed to the maintainer of NZTelecom. Please approach NZTelecom for further updates required for these assignments. If you have any question regarding this matter please do not hesistate to contact the APNIC helpdesk at: <helpdesk(a)apnic.net> To discuss this matter further in person a staff member of APNIC will be attending NZNOG5 in Hamilton 2 - 4 February 2005. Regards, APNIC Secretariat

4 3