- NZNOG - lists.nznog.org

SPF Records
by Craig Whitmore 19 Oct '04

19 Oct '04

Hi folks. We have noticed a number of domains in NZ have entered in their NS's domain.co.nz IN TXT "v=spf1 mx -all" This means domain.co.nz will never attempt to send emails at all. (but valid emails are trying to be sent). I've talked to a couple of domain holders who had this and they've fixed them but most said it was done ages ago and they where playing and never expected it to catch on (but it has a lot looking at the number) We (Orcon) have started to use SPF (for testing inbound email) and found it helps with identifying spam. _ALOT_ of people have published valid SPF records. Thanks Craig Whitmore Orcon Internet

11 14

Re: [nznog] SPF Records
by Ewen McNeill 18 Oct '04

18 Oct '04

In message <200410190425.i9J4PvGX007457(a)mailserv.waikato.ac.nz>, "Barry Murphy" writes: >I've wanted to setup SPF in the past but have always wondered what happens >when you have a roaming user sending via paradise for example. The best solution for roaming users is (SASL authenticated) relaying via a central mail server that is listed with SPF. Most commonly used mail clients (and some mail servers) will do SASL authentication these days, and many MTAs can be configured to do SALS authenticated mail relaying. Pushing mail through a central mail server like this is also useful if you are doing other processing on that mail server (eg, statistics, storing copies of messages, etc). >Would one need to know every internet facing ip for all ISP's mailservers? SPF also allows for "include" options, so that you can include (by reference) the SPF records published by the ISPs that are being used. You could, eg, "include" the SPF records of all ISPs used by roaming users. It'd be looser than ideal, but still much better than nothing. If that still isn't sufficient (eg, you have roaming users doing direct-to-remote-server SMTP), you could perhaps list all those ISP dialup subnets (in CIDR fashion). Again this is not ideal, but narrowing it down to a few /22s or even /20s compared with "the whole internet" is still an improvement. With some combination of these it should be possible to list a "much better than nothing" SPF record and then focus on tidying things up so it can be tighter (perhaps eventually down to just "v=spf1 mx -all"). More details at the SPF wizard: http://spf.pobox.com/wizard.html?mydomain=example.com Ewen

1 0

RE: [nznog] Mailwasher and its Forged Bounces
by neil gardner 18 Oct '04

18 Oct '04

Longtime listener, first time poster (on this topic anyway) _IF_ it's possible to reliably (and easily) identify the MailWasher bounces, why not just use that to identify customers using it, and block them from your mail server for a while (Hell, even disable their account perhaps) BUT, and this is the important bit, Send an email to the MW developers telling them that as an ISP you are blocking customers that use their software in this way. Suggest that users of their software will find their Intarwebthingy disabled. Sure the developers may not like taking out neat features, but they probably won't like fielding calls from users who get their net killed because of their product either. Cheers - N. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

3 2

Mailwasher and its Forged Bounces
by Lennon - Orcon 18 Oct '04

18 Oct '04

I've been looking lately and a "large" number of double bounces to postermaster are caused by people who use "MailWashers" to Bounce Spam. I rmember the days when I could read every message to postmaster(a)isp.co.nz They are quite easy to spot as they all have the format of: mail.local: unknown name: username 550 username(a)domain.co.nz ... User unknown Coming from MAILER-DAEMON(a)domain.co.nz (usually the ISP's one) (and forging the email (which I presume is against all ISP's T&C) In mailwashers FAQ it says: ------- Do the spammers know I am bouncing email? No, spammers do not know you are bouncing messages. Bounced messages look just like a returned mail message you would receive if you sent an email to an incorrect address. --------- If I can tell if someone if using mailwasher.. why cannot the spammers? Even so I would think 99.9% of all emails bounced via this program don't get back to the spammers anyway (they don't use proper from addresses or use someone else's domain to send from (anyone in NZ using/looking at using SPF? to stop this type of thing) What I am trying to say (if not very well). What do people think of this feature of mailwasher. I've emailed the writer a few times for comments over the last few years and heard nothing from him. Have ISP's complained to uses using it? stopped people using it? or what? Thanks Craig Whitmore

12 19

Ihug Prefix list update
by Sainesh Singh 17 Oct '04

17 Oct '04

Please update domestic filters for Ihug. APE details: AS7657 192.203.154.36 192.203.154.37 Updated list can be found at: http://www.ihug.net/ihug-prefix-list and is included below. Cheers, Sainesh Singh Ihug Engineering ip prefix-list ihug-networks permit ip prefix-list ihug-networks description ihug peering prefix-list contact: noc(a)ihug.co.nz : Updated 2004-10-18 ip prefix-list ihug-networks permit 192.107.113.0/24 ip prefix-list ihug-networks permit 202.21.130.0/24 ip prefix-list ihug-networks permit 202.21.136.0/23 le 24 ip prefix-list ihug-networks permit 202.36.44.0/24 ip prefix-list ihug-networks permit 202.36.94.0/23 le 24 ip prefix-list ihug-networks permit 202.36.230.0/24 ip prefix-list ihug-networks permit 202.36.231.0/24 ip prefix-list ihug-networks permit 202.37.182.0/24 ip prefix-list ihug-networks permit 202.49.33.0/24 ip prefix-list ihug-networks permit 202.49.46.0/23 le 24 ip prefix-list ihug-networks permit 202.49.63.0/24 ip prefix-list ihug-networks permit 202.49.148.0/23 le 24 ip prefix-list ihug-networks permit 202.49.176.0/23 le 24 ip prefix-list ihug-networks permit 202.49.178.0/24 ip prefix-list ihug-networks permit 202.49.180.0/23 le 24 ip prefix-list ihug-networks permit 202.49.186.0/24 ip prefix-list ihug-networks permit 202.49.249.0/24 ip prefix-list ihug-networks permit 202.50.84.0/24 ip prefix-list ihug-networks permit 202.50.103.0/24 ip prefix-list ihug-networks permit 202.50.188.0/22 le 24 ip prefix-list ihug-networks permit 202.50.255.0/24 ip prefix-list ihug-networks permit 203.96.192.0/19 le 24 ip prefix-list ihug-networks permit 203.109.128.0/17 le 24 ip prefix-list ihug-networks permit 203.109.130.0/24 ip prefix-list ihug-networks permit 203.109.132.0/22 ip prefix-list ihug-networks permit 203.109.133.0/24 ip prefix-list ihug-networks permit 203.109.134.0/24 ip prefix-list ihug-networks permit 203.109.135.0/24 ip prefix-list ihug-networks permit 203.109.144.0/20 ip prefix-list ihug-networks permit 203.109.157.0/24 ip prefix-list ihug-networks permit 203.109.192.0/21 ip prefix-list ihug-networks permit 203.109.198.0/24 ip prefix-list ihug-networks permit 203.109.199.0/24 ip prefix-list ihug-networks permit 203.109.230.0/24 ip prefix-list ihug-networks permit 203.118.128.0/18 le 24 ip prefix-list ihug-networks permit 203.118.144.0/20 ip prefix-list ihug-networks permit 203.118.160.0/20 ip prefix-list ihug-networks permit 203.118.164.0/22 ip prefix-list ihug-networks permit 203.118.168.0/21 ip prefix-list ihug-networks permit 203.173.128.0/17 le 24 ip prefix-list ihug-networks permit 203.173.170.0/23 ip prefix-list ihug-networks permit 203.173.192.0/19 ip prefix-list ihug-networks permit 203.173.224.0/20 ip prefix-list ihug-networks permit 203.173.240.0/21 ip prefix-list ihug-networks permit 210.55.110.0/24 ip prefix-list ihug-networks permit 210.55.184.0/24 ip prefix-list ihug-networks permit 210.55.202.0/23 le 24 ip prefix-list ihug-networks permit 210.55.248.0/21 le 24

1 0

ACCC (Aus): Draft report on Internet Interconnection
by Simon Lyall 17 Oct '04

17 Oct '04

I havn't read it all yet but people may find it interesting. http://www.accc.gov.au/content/index.phtml/itemId/543536/ "The Australian Competition and Consumer Commission has issued a draft report seeking comment on whether internet interconnection arrangements should be subject to a two year period of monitoring..... " -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.

2 1

Updated monitoring pages from Team Cymru
by Rob Thomas 13 Oct '04

13 Oct '04

[ Apologies to those of you who receive this note in multiple forums. ] Hi, team. We are pleased to announce some updated monitoring, as well as some new monitoring, on our web site. This includes aesthetic fixes as well as increased visibility. Our DNS monitoring now has increased visibility as well as a new look and feel. Gone are the multiple pages for each zone, replaced with a single page that will have additional zones soon. You'll find it at the following URL. <http://www.cymru.com/DNS/dns.html> The times are DNS query response times, and the query responses are checked for correctness. Clicking on the query response time will bring you to a more detailed, graphical view of the query responses for the given pod and name server combination. We've updated our network monitoring to include several new components. This includes pod to pod ICMP, TCP, and UDP monitoring. It also includes traffic graphs for a select few Darknet pods, and our new Internet Garbage Meter. :) <http://www.cymru.com/Reach/index.html> For more on Darknets, from which our Darknet monitoring and Internet Garbage Meter are generated, please see our Darknet Project page at the following URL. <http://www.cymru.com/Darknet/> We hope you find this of use. Comments and suggestions are always welcome! Thanks! Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

Re: [nznog] ICONZ
by Michael Hallager 12 Oct '04

12 Oct '04

Their helpdesk has told me it is a BGP4 fault and it is at Orcon's end, which it appears is news to Orcon. > Call the helpdesk? Call the noc? Paths look fine to me in a traceroute from > both providers. Michael Hallager (SNIP)

2 1

Re: Re: [nznog] linux.jetstreamgames.co.nz
by Jonny Martin 12 Oct '04

12 Oct '04

> "WIX peers only" mirror, much like ftp.nz.debian.org? I notice the "your ISP > is broken" message is still broken: > Looks like peering with the APE route servers wont > actually fix it. "...MAY be able to fix this problem for you... at the APE OR the WIX" - doesn't seem to me that it's broken. Seems quite reasonable as a generic sorry-no-peering-at-the-appropriate-place-and-we're-not-paying-for-the-traffic message. Cheers, Jonny.

18 23

RE: [nznog] Windows Update Server Selection
by Craig Humphrey 12 Oct '04

12 Oct '04

We've worked with Akamai and the best I can ascertain is that it directs you to the "best" location, where best isn't always the physically nearest server, since it may not have the content you're after. I think it uses similar ideas to what some of the distributed p2p clients do. Get enough requests from a "region" and you move the content (or a copy of the content) closer to that region. But that's just my understanding. > -----Original Message----- > From: Craig Whitmore [mailto:lennon(a)orcon.net.nz] > Sent: Wednesday, October 13, 2004 1:24 PM > To: jon.brewer(a)araneo.net.nz > Cc: nznog(a)list.waikato.ac.nz > Subject: RE: [nznog] Windows Update Server Selection > > It is based on Akamai (where download.microsoft.com is > pointing). But for > some reason.. they seem to move it around ALL the time. Anyone from > Microsoft/Akamai comment/can find out WHY its switching > around all the time > (with us it changes every 20-30 mins.. NZ..Australia.. US.. > Australia....) > Instead of just going to the Akamai Servers in NZ > > Thanks > Craig Whitmore > Orcon Internet

1 0