- NZNOG - lists.nznog.org

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

RE: [nznog] Sendmail Question
by Regan Murphy 25 Nov '04

25 Nov '04

You would probably lose a lot of mail that way. E.g. From: NZRR Database Notifications <rpsl-admin(a)nzix.net> Precedence: bulk Message-Id: <E1CXQJJ-0007Ps-00(a)zoff.wix.net.nz> From: Sun Microsystems <sun-events(a)see.sun.com> Message-id: <0I7P002S8ZMRCO(a)olm-ms2.sun.com> Message-ID: <880B6B3B42770C4E92F35D85732893A0EB910C(a)aklemail01.salesforce.co.nz> From: Fly Buys Service Centre <contactus(a)mailus.co.nz> A lot of mailservers are on subdomains masquerading as the root domain. Also some organisations send mail for different domains (legit ones) from the same mailserver. -- Regan -----Original Message----- From: Dan Clark [mailto:dan(a)scarfies.net] Sent: Friday, 26 November 2004 11:17 a.m. To: 'nznog' Subject: [nznog] Sendmail Question 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 _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

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

25 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: - Date: Fri, 26 Nov 2004 10:24:47 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0411261013430.9968(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: initially peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR REPLACED BY: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: PNIX peering at '218.100.21.10' descr: see Citylink RT job #1487 descr: APE peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 import: from AS9281 accept ANY AND NOT fltr-bogons export: to AS9281 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR

1 0