- NZNOG - lists.nznog.org

The wacky, weird world of not peering
by Philip D'Ath 21 Mar '07

21 Mar '07

http://computerworld.co.nz/news.nsf/news/60FED800168312AECC2572A0001A299 7 ... Thankfully we have heard that Telecom is reconsidering its approach and we say it is about time. With continued data growth, IP-based voice and video becoming widespread, and an increasing number of networks being developed, it is critical that local data is kept local and the most efficient paths across the network are utilised. Telecom has recently been reported in the media as saying it is seriously looking at and now supports the concept of local internet interconnection. Rumours abound of a June/July timetable. Of course for their customers, and TelstraClear's, one would expect they never stopped local interconnection, but this move would re-integrate Telecom with the rest of the internet at a local level. ...

7 8

Notification of NZRR Database changes
by NZRR Database Notifications 21 Mar '07

21 Mar '07

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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by IHUG - AS7657 members: 124.168.0.0/16^16-29, 203.59.0.0/16^16-29, 203.109.128.0/17^17-29, 203.118.128.0/17^17-29, 203.173.128.0/17^17-29, 203.206.0.0/17^17-29, 203.214.0.0/17^17-29, 210.84.0.0/18^18-29, 202.161.0.0/19^19-29, 203.96.192.0/19^19-29, 203.158.32.0/19^19-29, 203.166.224.0/19^19-29, 203.173.0.0/19^19-29, 203.206.128.0/19^19-29, 203.206.224.0/19^19-29, 203.214.128.0/19^19-29, 203.217.32.0/19^19-29, 203.217.64.0/19^19-29, 202.36.16.0/20^20-29, 202.46.160.0/20^20-29, 202.137.96.0/20^20-29, 203.173.32.0/20^20-29, 203.190.192.0/20^20-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 202.129.80.0/21^21-29, 202.129.96.0/21^21-29, 203.173.48.0/21^21-29, 203.206.168.0/21^21-29, 203.206.176.0/21^21-29, 203.215.0.0/21^21-29, 203.217.0.0/21^21-29, 203.217.16.0/21^21-29, 210.55.248.0/21^21-29, 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.49.240.0/22^22-29, 202.50.188.0/22^22-29, 202.129.68.0/22^22-29, 202.129.76.0/22^22-29, 202.129.108.0/22^22-29, 202.129.116.0/22^22-29, 202.129.120.0/22^22-29, 203.14.168.0/22^22-29, 203.55.228.0/22^22-29, 203.57.140.0/22^22-29, 203.62.212.0/22^22-29, 203.173.56.0/22^22-29, 203.206.164.0/22^22-29, 203.206.184.0/22^22-29, 203.206.192.0/22^22-29, 203.206.204.0/22^22-29, 203.206.220.0/22^22-29, 203.215.8.0/22^22-29, 203.217.12.0/22^22-29, 203.217.28.0/22^22-29, 202.21.136.0/23^23-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.88.0/23^23-29, 202.49.148.0/23^23-29, 202.49.176.0/23^23-29, 202.49.180.0/23^23-29, 202.61.2.0/23^23-29, 202.128.110.0/23^23-29, 202.129.72.0/23^23-29, 202.129.88.0/23^23-29, 202.129.92.0/23^23-29, 202.129.106.0/23^23-29, 202.129.114.0/23^23-29, 203.7.196.0/23^23-29, 203.8.92.0/23^23-29, 203.14.174.0/23^23-29, 203.17.62.0/23^23-29, 203.21.74.0/23^23-29, 203.29.86.0/23^23-29, 203.55.140.0/23^23-29, 203.56.30.0/23^23-29, 203.56.62.0/23^23-29, 203.57.10.0/23^23-29, 203.57.136.0/23^23-29, 203.173.60.0/23^23-29, 203.206.162.0/23^23-29, 203.206.188.0/23^23-29, 203.206.202.0/23^23-29, 203.206.208.0/23^23-29, 203.206.218.0/23^23-29, 203.215.14.0/23^23-29, 203.215.18.0/23^23-29, 203.215.20.0/23^23-29, 203.217.10.0/23^23-29, 210.55.202.0/23^23-29, 192.107.113.0/24^24-29, 192.188.107.0/24^24-29, 198.32.71.0/24^24-29, 199.98.84.0/24^24-29, 202.7.6.0/24^24-29, 202.12.87.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.46.0/24^24-29, 202.36.174.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 202.128.109.0/24^24-29, 202.129.67.0/24^24-29, 202.129.91.0/24^24-29, 202.129.94.0/24^24-29, 202.129.104.0/24^24-29, 202.129.112.0/24^24-29, 202.129.125.0/24^24-29, 202.129.126.0/24^24-29, 202.169.97.0/24^24-29, 202.176.0.0/24^24-29, 203.0.12.0/24^24-29, 203.0.84.0/24^24-29, 203.0.139.0/24^24-29, 203.0.178.0/24^24-29, 203.1.24.0/24^24-29, 203.1.78.0/24^24-29, 203.2.199.0/24^24-29, 203.3.127.0/24^24-29, 203.4.173.0/24^24-29, 203.5.184.0/24^24-29, 203.7.155.0/24^24-29, 203.7.173.0/24^24-29, 203.8.161.0/24^24-29, 203.8.219.0/24^24-29, 203.12.1.0/24^24-29, 203.12.15.0/24^24-29, 203.12.44.0/24^24-29, 203.12.236.0/24^24-29, 203.14.172.0/24^24-29, 203.14.182.0/24^24-29, 203.15.111.0/24^24-29, 203.15.129.0/24^24-29, 203.16.34.0/24^24-29, 203.17.60.0/24^24-29, 203.17.194.0/24^24-29, 203.17.249.0/24^24-29, 203.17.251.0/24^24-29, 203.18.85.0/24^24-29, 203.18.140.0/24^24-29, 203.19.70.0/24^24-29, 203.20.82.0/24^24-29, 203.20.88.0/24^24-29, 203.20.116.0/24^24-29, 203.20.132.0/24^24-29, 203.21.5.0/24^24-29, 203.21.105.0/24^24-29, 203.22.19.0/24^24-29, 203.22.96.0/24^24-29, 203.23.7.0/24^24-29, 203.24.50.0/24^24-29, 203.24.189.0/24^24-29, 203.25.109.0/24^24-29, 203.25.144.0/24^24-29, 203.25.197.0/24^24-29, 203.26.32.0/24^24-29, 203.26.86.0/24^24-29, 203.26.92.0/24^24-29, 203.26.128.0/24^24-29, 203.27.58.0/24^24-29, 203.27.60.0/24^24-29, 203.27.89.0/24^24-29, 203.27.201.0/24^24-29, 203.28.157.0/24^24-29, 203.28.174.0/24^24-29, 203.29.221.0/24^24-29, 203.30.181.0/24^24-29, 203.30.194.0/24^24-29, 203.31.13.0/24^24-29, 203.31.96.0/24^24-29, 203.31.141.0/24^24-29, 203.34.95.0/24^24-29, 203.55.151.0/24^24-29, 203.56.243.0/24^24-29, 203.57.134.0/24^24-29, 203.61.76.0/24^24-29, 203.102.166.0/24^24-29, 203.108.77.0/24^24-29, 203.112.114.0/24^24-29, 203.173.63.0/24^24-29, 203.206.161.0/24^24-29, 203.206.190.0/24^24-29, 203.206.196.0/24^24-29, 203.206.198.0/24^24-29, 203.206.201.0/24^24-29, 203.206.213.0/24^24-29, 203.206.214.0/24^24-29, 203.206.217.0/24^24-29, 203.215.12.0/24^24-29, 203.215.17.0/24^24-29, 210.8.138.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: pshem.k(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060522 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by Ihug Ltd - AS7657 members: 121.90.0.0/16^16-29, 124.168.0.0/16^16-29, 203.59.0.0/16^16-29, 203.173.128.0/17^17-29, 203.206.0.0/17^17-29, 203.214.0.0/17^17-29, 202.129.64.0/18^18-29, 210.84.0.0/18^18-29, 124.6.192.0/19^19-29, 202.161.0.0/19^19-29, 203.158.32.0/19^19-29, 203.166.224.0/19^19-29, 203.173.0.0/19^19-29, 203.206.128.0/19^19-29, 203.214.128.0/19^19-29, 203.217.32.0/19^19-29, 203.217.64.0/19^19-29, 202.46.160.0/20^20-29, 202.73.192.0/20^20-29, 203.173.32.0/20^20-29, 203.190.192.0/20^20-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 203.173.48.0/21^21-29, 203.206.168.0/21^21-29, 203.206.176.0/21^21-29, 203.215.0.0/21^21-29, 203.217.0.0/21^21-29, 203.217.16.0/21^21-29, 210.55.248.0/21^21-29, 202.49.240.0/22^22-29, 203.14.168.0/22^22-29, 203.55.228.0/22^22-29, 203.57.140.0/22^22-29, 203.62.212.0/22^22-29, 203.173.56.0/22^22-29, 203.206.164.0/22^22-29, 203.206.184.0/22^22-29, 203.206.192.0/22^22-29, 203.206.204.0/22^22-29, 203.206.220.0/22^22-29, 203.215.8.0/22^22-29, 203.217.12.0/22^22-29, 203.217.28.0/22^22-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.88.0/23^23-29, 202.49.176.0/23^23-29, 202.49.180.0/23^23-29, 202.128.110.0/23^23-29, 203.7.196.0/23^23-29, 203.8.92.0/23^23-29, 203.14.174.0/23^23-29, 203.17.62.0/23^23-29, 203.21.74.0/23^23-29, 203.29.86.0/23^23-29, 203.55.140.0/23^23-29, 203.56.30.0/23^23-29, 203.56.62.0/23^23-29, 203.57.10.0/23^23-29, 203.57.136.0/23^23-29, 203.173.60.0/23^23-29, 203.206.162.0/23^23-29, 203.206.188.0/23^23-29, 203.206.202.0/23^23-29, 203.206.208.0/23^23-29, 203.206.218.0/23^23-29, 203.215.18.0/23^23-29, 203.215.20.0/23^23-29, 203.217.10.0/23^23-29, 210.55.202.0/23^23-29, 97.64.46.0/24^24-29, 192.107.113.0/24^24-29, 192.188.107.0/24^24-29, 198.32.71.0/24^24-29, 202.7.6.0/24^24-29, 202.8.47.0/24^24-29, 202.12.87.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.46.0/24^24-29, 202.36.174.0/24^24-29, 202.37.136.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 202.128.109.0/24^24-29, 202.169.97.0/24^24-29, 202.176.0.0/24^24-29, 203.0.12.0/24^24-29, 203.0.84.0/24^24-29, 203.0.139.0/24^24-29, 203.0.178.0/24^24-29, 203.1.24.0/24^24-29, 203.1.78.0/24^24-29, 203.2.199.0/24^24-29, 203.3.127.0/24^24-29, 203.4.173.0/24^24-29, 203.5.184.0/24^24-29, 203.7.155.0/24^24-29, 203.7.173.0/24^24-29, 203.8.161.0/24^24-29, 203.8.219.0/24^24-29, 203.12.1.0/24^24-29, 203.12.15.0/24^24-29, 203.12.44.0/24^24-29, 203.12.236.0/24^24-29, 203.14.172.0/24^24-29, 203.14.182.0/24^24-29, 203.15.111.0/24^24-29, 203.15.129.0/24^24-29, 203.16.34.0/24^24-29, 203.17.60.0/24^24-29, 203.17.194.0/24^24-29, 203.17.249.0/24^24-29, 203.17.251.0/24^24-29, 203.18.85.0/24^24-29, 203.18.140.0/24^24-29, 203.19.70.0/24^24-29, 203.20.82.0/24^24-29, 203.20.88.0/24^24-29, 203.20.116.0/24^24-29, 203.20.132.0/24^24-29, 203.21.5.0/24^24-29, 203.21.105.0/24^24-29, 203.22.19.0/24^24-29, 203.22.96.0/24^24-29, 203.23.7.0/24^24-29, 203.24.50.0/24^24-29, 203.24.189.0/24^24-29, 203.25.109.0/24^24-29, 203.25.144.0/24^24-29, 203.25.197.0/24^24-29, 203.26.32.0/24^24-29, 203.26.86.0/24^24-29, 203.26.92.0/24^24-29, 203.26.128.0/24^24-29, 203.27.58.0/24^24-29, 203.27.60.0/24^24-29, 203.27.89.0/24^24-29, 203.27.201.0/24^24-29, 203.28.157.0/24^24-29, 203.28.174.0/24^24-29, 203.29.221.0/24^24-29, 203.30.181.0/24^24-29, 203.30.194.0/24^24-29, 203.31.13.0/24^24-29, 203.31.96.0/24^24-29, 203.31.141.0/24^24-29, 203.34.95.0/24^24-29, 203.55.151.0/24^24-29, 203.56.243.0/24^24-29, 203.57.134.0/24^24-29, 203.61.76.0/24^24-29, 203.102.166.0/24^24-29, 203.108.77.0/24^24-29, 203.112.114.0/24^24-29, 203.118.136.0/24^24-29, 203.173.63.0/24^24-29, 203.206.161.0/24^24-29, 203.206.190.0/24^24-29, 203.206.196.0/24^24-29, 203.206.198.0/24^24-29, 203.206.201.0/24^24-29, 203.206.213.0/24^24-29, 203.206.214.0/24^24-29, 203.206.217.0/24^24-29, 203.215.12.0/24^24-29, 203.215.17.0/24^24-29, 203.215.31.0/24^24-29, 210.8.138.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070322 source: NZRR

1 0

DNS TTLs: trademe and anz
by Simon Lyall 18 Mar '07

18 Mar '07

I'm doing a bit of DNS testing and I start noticing some weird results for a few domains. The two below appear to be specific problems since they are popular and I noticed them but I suspect there are others. The problem is that www.anz.co.nz and www.anz.com have TTLs of zero seconds. This means that *every* DNS look up for them takes either around 40 or 140ms (one server is closer/quicker than the other) since it is never cached. Similarly the TTL for www.trademe.co.nz (and www.oldfriends.co.nz) is just ten seconds so this must be constantly rechecked. Not as bad since their servers are in NZ but still there is a delay. Some companies (like google or yahoo) have very sophisticated systems that constantly check user performance and switch them from datacenter to datacenter in seconds if things start going slow. However unless your company has such a system (and very reliable and nearly DNS servers) then a TTL of a few minutes is good enough for manual updates to quickly propagate. Lower values than that will result in decreased performance for your customers. Even google and yahoo have TTLs of a minute or two. The scary thing is that both sites probably put a lot of time into making the actual pages load as fast as possible. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

10 13

Call for Hosts: NZNOG 08
by Daniel Lawson 14 Mar '07

14 Mar '07

Call for Hosts: NZNOG 08 We are looking for potential hosts for NZNOG 06 in around a year's time. I would like to hear off-list from people who a) have been to at least one NZNOG conference in the past, and b) might be interested in hosting next year's conference. This is not about committing anybody to anything at this stage. It is a good time to start thinking about whether this is a way in which you could contribute to the community, whether as a single hosting organisation or in cooperation with others. I look forward to hearing from you before the 25th of March. Regards, Daniel Lawson NZNOG 08 Conference Organising Committee.

1 1

Re: [nznog] DNS TTLs: trademe and anz
by Ewen McNeill 12 Mar '07

12 Mar '07

In message <45F5DAA1.9070701(a)deanpemberton.com>, Dean Pemberton writes: >I can remember a time when a similar question was raised about zero time >TTLs on records. [...] It was with a bank. [...] >"We want to make sure that each and every request for an IP address >comes to our DNS server. We don't want it to be cached at all as this >can lead to someone hijacking the cache. We like it this way" So if someone _does_ manage to find a way to poison the cache with a record, then they can happily set a long TTL on the poison record and avoid any other lookups. And there's an almost zero chance that there'll be valid cached record there to prevent the poisoned one being cached. Seems to me some people don't think through the logical consequences of their actions. It also seems to me that anyone needing failover in less than about an hour wants a different solution than updating DNS entries (load balancer, anycast, etc). Ewen

5 7

Re: [nznog] ISP's Natting customer pools
by Martin Kealey 11 Mar '07

11 Mar '07

On 20-Feb-2007 Joe Abley wrote: > On 20-Feb-2007, at 17:16, Martin Kealey wrote: > > Question: are there any (DSL?) CPE units for sale or in development > > that will do v6 to v4 translation, plus v6 pass-thru? > > In practical terms (and I'm being only slightly pedantic) there *is* > no v6 to v4 translation. There are tunnels, and there is native IPv6. Are you saying that when a v6 host says "Connect to ::ffff:cfdb:2d24", the answer will invariably be "can't"? Otherwise we're talking about a third option that smells rather like SNAT, but running on steroids. Hence my using the term "translation". It makes sense for this "natting" to occur as far as possible from the v6 source host and as near as possible to the target v4 host, but in any case it can only go as far away as your v6 transit allows. Since we're only starting the game, that means the CPE border kit. Although I asked about doing both "translation and pass-thru", if the ISP at the other end is sensible it should only need to do one of those at a time. -Martin reference: http://xml.resource.org/public/rfc/html/rfc2373.html#anchor11

3 2

Domestic looking glass or traceroute
by Gerard Creamer 09 Mar '07

09 Mar '07

Hi, I'm looking for a New Zealand based looking glass that's on the Internet - so not the WIX or APE ones. The only one I've been able to find that goes is the ICONZ one at NZIX (http://nzix.net/cgi-bin/mrlg-others.cgi) although did also find Simon Lyall's one, which is currently offline, at http://www.usenet.net.nz/lg.cgi (AS7657). I have found a single working traceroute at http://www.kcbbs.gen.nz/cgi-bin/trace (AS9303). There are two others listed at traceroute.org, but neither is working. Is it just there there aren't many of these about, or are they just a well guarded secret? I found a few posts on the topic to this list in July last year (http://list.waikato.ac.nz/pipermail/nznog/2006-July/011929.html) but it didn't seem to go anywhere. If anyone knows of any others based in New Zealand (there are zillions elsewhere on the internet) I would greatly appreciate knowing where! Specifically I'm looking for traces from Orcon and Telecom / Xtra to 210.4.208.1, but the more data I can get to see why it seems that more traffic is coming in through our expensive upstream than we thought would the better :^) Cheers, Gerard

3 3

bind IPv6 configurator
by Matthew Poole 08 Mar '07

08 Mar '07

Does anyone know if there are any websites that will create a bind reverse zone file for a given IPv6 range? I can cope with creating the forward entries, but trying to work out the correct zone naming (not to mention the actual resource entries) for the reverse is more than my paw widdle bwain can cope with at present. -- Matthew Poole "Don't use force. Get a bigger hammer."

2 1

JABL announcement: dynablock & Spamhaus PBL
by Craig Whitmore 08 Mar '07

08 Mar '07

This came from the SPAM-L mailing list. If ppl are using RBL's on their mail servers they might want to read below. ------------------------------------------------------------------------- The following text was sent to list(a)njabl.org on Jan 19, 2007. Judging from the number of DNS queries still being handled for dynablock.njabl.org, the message doesn't seem to have made it to a wide enough audience. If you use or know people who use dynablock.njabl.org, this is important information: With the advent of Spamhaus's PBL (http://spamhaus.org/pbl/) dynablock.njabl.org has become obsolete. Rather than maintain separate similar DNSBL zones, NJABL will be working with Spamhaus on the PBL. Effective immediately, dynablock.njabl.org exists as a copy of the Spamhaus PBL. After dynablock users have had ample time to update their configurations, the dynablock.njabl.org zone will be emptied. Other NJABL zones (i.e. dnsbl, combined, bhnc, and the qw versions) will continue, business as usual, except that combined will eventually lose its dynablock component. If you currently use dynablock.njabl.org we recommend you switch immediately to pbl.spamhaus.org. If you currently use combined.njabl.org, we recommend you add pbl.spamhaus.org to the list of DNSBLs you use. You may also want to consider using zen.spamhaus.org, which is a combination zone consisting of Spamhaus's SBL, XBL, and PBL zones. ---------------- Thanks Craig

1 0

Re: [nznog] RFC822 (Identification of sender in email)
by Stoo Brighting 05 Mar '07

05 Mar '07

Hey, if you're going to quote me, at least quote me correctly. I didn't say it was unmonitored, we do monitor all bounces we get in order to process the NDR's (thousands each day) Like I said on the phone, our emails have completely valid envelope fields, and we update our database to "clean" out the bad email addresses that people often like to sign up with. This doesn't break any RFC that I know of. We'd just prefer that you don't reply to our CRM messages via SMTP, that's all - hence the "please do not reply to this" at the bottom of all our outbound emails, and the auto-responder if you do happen to send mail to these addresses. If this breaks an RFC, point me at the appropriate place, and I'll change things to fit them. As for being cocky, I can handle that, I've been called worse. Cheers, Stoo Misc small online company. -----Original Message----- From: John @ netTRUST [mailto:john(a)nettrust.net.nz] Sent: Tuesday, 6 March 2007 2:39 p.m. To: Craig Whitmore; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] RFC822 (Identification of sender in email) I've just had a call from a rather cocky person at the company. They claim it is allright and common. I disagree, with the exception that it is common among spammers*. Hence why I'm asking other NZNOG members. Reply emails go to an auto responder which the company person says is unmonitored. This issue was bought to my attention when I wrote an email to this company, though as we handle (I estimate) several thousand emails per day from this company, I ahve decided to investigate the matter further. *I am in no way suggesting said company is a spammer, but we're under constant pressure from customers to increase the level of 'protection' and looking at their emails, they could quite possibly score a few bayes points. > > In investigating an issue involving a large online NZ company's outbound > > email - I read RFC822 which I have quoted below. > > > > I note that this company is currently making use of apparently > > unmonitored return addresses which generate an auto reply. > > Are you saying they are sending (MFROM) Addresses which don't exist (ie > cannot be bounced back to etc). Or MFROM a valid email address which no one > reads (ie noreply(a)XXXXX) > > Thanks > Craig _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1