Just a reminder for those of you who would like to attend, you can
still enrol. The $50 is primarily for food.
The Number Administration Deed (NAD) Management Committee and Internet
NZ are holding a joint seminar on ENUM on Monday 24 November 2003 from
9.00 am - 5.00 pm. The venue is the Level 2 West Lounge at Westpactrust
Stadium in Wellington.
Tony Holmes of BT is attending as guest speaker. He intends to discuss
the following topics:
1. Introduction to ENUM.
2. ENUM Specifications, Rules and Recommendations.
3. An overview of what's happening across the globe.
4. Experience, issues and problems from the UK ENUM trial.
5. The focus for New Zealand - discussion on 'what needs to happen next'.
Representatives from the Ministry of Economic Development will also
attend to present their views on ENUM.
Cost $50.00 per person, which includes the full day ENUM seminar plus
morning tea, lunch and afternoon tea.
Registration and Contacts
Jennifer Neeley (M-co)
Phone: 04 498 0026
Fax: 04 473 6950
Direct +64 4 495 2113
ICONZ have updated their domestic peering advertisements.
Any that currently peer with ICONZ please update your prefix lists
with attached file or use URL supplied.
If there is anyone who would like to peer with ICONZ across APE or WIX
please send an email to noc(a)iconz.net
Phone: 09 977 3500
People who are receiving IP space from Global Gateway would be well advsied to
check that their IP addresses have not been hijacked by Xtra:
bash-2.05b# nslookup 126.96.36.199
Note: nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead. Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
188.8.131.52.in-addr.arpa name = 210-55-169-1.ipnets.xtra.co.nz.
Authoritative answers can be found from:
169.55.210.in-addr.arpa nameserver = alien.xtra.co.nz.
169.55.210.in-addr.arpa nameserver = terminator.xtra.co.nz.
Reminds me of the "old days" when Xtra started up....
Vivid Computers Ltd
The NZNOG '04 arrangements are coming along well and registration is
now open at www.nznog.org.
We're pleased to have Geoff Houston (Telstra Aust/APNIC) and Philip
Smith (CISCO) as invited speakers. See the conference web pages for
more details. Other details about the conference, including the the
on campus accommodation etc are also on the web page.
It's still possible to put in a talk or tutorial proposal. Please
send them to talks(a)nznog.org.
We're about to send out letters to various folks asking for
sponsorship. We're not looking for lots of money, just ways to add
value to the conference through materials, extra international
speakers, the bar, etc. If you have any contacts that we could write
to please let me know.
It's a huge help if people sign up early. The conference fee is lower
if you sign up early. Also, there is only limited accommodation with
in-room network access, if you want that I suggest you sign up quick!
[ Apologies to those who have received this post in other fora. ]
The numerous Team Cymru bogon projects have been updated to reflect the
following IANA allocations on November 15, 2003:
83/8 Nov 03 RIPE NCC
84/8 Nov 03 RIPE NCC
IANA allocations change over time, so please check regularly to ensure
you have the latest filters if you are not using the bogon BGP feed(s).
We do announce updates to the bogon projects to the FIRST community, as
well as on lists such as NANOG, isp-routing, isp-security, isp-bgp,
cisco-nsp, and bogon-announce. We can not stress this point strongly
enough - these allocations change. If you do not adjust your filters,
you will be unable to access perhaps large portions of the Internet.
Worse yet, you may end up blocking access for people who transit through
Please do not blindly apply any filters or blocks to your network
without carefully considering the ramifications of doing so.
As a point of reference, the master Bogon Reference Page can be found
A quick summary of the documents and projects that have been updated
include the following:
The Bogon List
The Text Bogon List, Unaggregated
The Text Bogon List, Aggregated
Secure BIND Template
Secure IOS Template (Cisco)
Secure BGP Template (Cisco)
Secure JUNOS Template (Juniper)
Secure JUNOS BGP Template (Juniper)
Ingress Prefix Filter Templates, Loose and Strict (Cisco)
Ingress Prefix Filter Template, Loose (Juniper)
Ingress Prefix Filter Template, Strict (Juniper)
Bogon route-server *
Bogon (bogons.cymru.com) zone
Bogon prefix monitoring
* All of the bogon peers have received the appropriate BGP prefix
Please feel free to contact Team Cymru with any comments, questions, or
Rob, for Team Cymru.
ASSERT(coffee != empty);
On 17 Nov 2003 11:25 UTC "Barry Murphy" <barry(a)unix.co.nz> wrote:
| I received the same message 8 times to the same address with about
| 2-3 per hour. My spamassasin picked them up but the strange thing was
| they all came from different IP addresses and I couldn't traceroute
| any of them...
You've assumed the handoff between received lines was valid; it wasn't.
The "earlier" received line in each case was totally bogus: there is
now a variety of custom "spamware" that forges a Received: header and
carefully matches the fake details to the reverse DNS of the proxy or
trojan machine that the spammer is actually sending from. That makes it
almost impossible to know that the line is is in fact forged, unless you
spot some little detail that they get wrong ... like (as in some of the
cases that you quoted), the fact that the fake sending IP in the forged
header is in a block that's either unannounced or completely unroutable!
| IP addresses they were sent from:
184.108.40.206 IANA Reserved
220.127.116.11 Assigned but not announced
18.104.22.168 IANA Reserved
22.214.171.124 IANA Reserved
126.96.36.199 Interop Show Network
188.8.131.52 UUNET Internet Africa
| the messages were stopped as they were listed in blacklists.
Blocklist tests are normally done on the most recent Received: line,
as unless that line is OK, previous lines cannot usually be trusted.
| The thing I don't understand is that there was no consistency, all
| the emails from different IP's, all different forged header fields,
| all not tracerouteable and within 30 minutes of each other to an
| address only listed on a new zealand website.
I can traceroute to some of the IPs you listed so it may be that
traceroute packets have been blocked at your gateway. There are
currently very some good reasons why network administrators do that!
Because of the level of filtering, spammers now try to send the same
mail from different proxies/zombies to be sure of getting it through.
Different IPs are in different blocklists, and spammers can't tell
what blocklist your ISP - or that of any other victim - uses. They
can't even tell whether mail gets through at all because many systems
are now configured to drop the mail rather than reject it. I won't
pass comment on that policy, but we all know it happens. Hence to get
better delivery figures, spammers now have to send out multiple copies.
Their systems randomise all the variable factors - fake mail client,
fake origin, fake sender name, random subject line etc, and loads of
random garbage text in the spam body to foil any checksum detection
of bulk mailing.
| Weird, sounds very much like the spam system explained on the list
| not too long ago.
While it may well use that system, multiple proxy/trojan sending boxes
are now becoming a standard spammer-modus-operandi!
Joe Abley <jabley(a)isc.org> replied:
| It seems to be fairly commonplace these days for (a) spam to be
| vectored through widely-distributed sets of open proxies or infected
| windows drones and (b) for unallocated or normally unadvertised space
| to be advertised transiently in order to provide temporary addresses
| to bind SMTP clients to.
(a) is normal, for sure, but (b) - although theoretically trivial to
do - is not yet in common use. Bogus announcements would need to be
visible every place the spammer wanted to send to, and would then be
visible at the route-collectors which report into systems like RIPE's
RIS server and that in turn would allow them to be identified from a
lookup at http://www.ripe.net/ripencc/pub-services/np/ris/index.html
Contribute to the SpamCon Legal Fund!! http://www.spamcon.org/legalfund/
Anyone else receive this subject on the 14th...
"AMERICAN STOCK MARKET: TRHL Retains Sky Investor Relations...edita", where edita was changed with multiple names.
Not strange that I received spam, however I received the same message 8 times to the same address with about 2-3 per hour. My spamassasin picked them up but the strange thing was they all came from different IP addresses and I couldn't traceroute any of them...
All of them stop at 184.108.40.206 (Global-gateway)
traceroute to 220.127.116.11 (18.104.22.168), 64 hops max, 44 byte packets
1 gateway (22.214.171.124) 1.679 ms 2.403 ms 1.358 ms
2 fe0-0.cr1.idc.orcon.net.nz (126.96.36.199) 0.863 ms 0.872 ms 0.852 ms
3 fe-1.qos2.idc.orcon.net.nz (188.8.131.52) 1.134 ms 1.004 ms 1.128 ms
4 184.108.40.206 (220.127.116.11) 1.774 ms 1.906 ms 1.567 ms
5 18.104.22.168 (22.214.171.124) 39.962 ms 93.651 ms 6.643 ms
6 ge-0-3-0-6.akbr3.global-gateway.net.nz (126.96.36.199) 6.165 ms !N^C
Ip addresses they were sent from:
In all cases the messages were stopped as they were listed in blacklists.
RCVD_IN_NJABL (0.9 points) RBL: Received via a relay in dnsbl.njabl.org
[RBL check: found 188.8.131.52.dnsbl.njabl.org.,]
RCVD_IN_UNCONFIRMED_DSBL (0.5 points) RBL: Received via a relay in unconfirmed.dsbl.org
[RBL check: found 184.108.40.206.unconfirmed.dsbl.org.]
RCVD_IN_BL_SPAMCOP_NET (3.0 points) RBL: Received via a relay in bl.spamcop.net
[RBL check: found 220.127.116.11.bl.spamcop.net.]
They were also stopped because of forged headers, some having forged froms, forged MUA Outlook, etc.
The thing I don't understand is that there was no consistency, all the emails from different IP's, all different forged header fields, all not tracerouteable and within 30 minutes of eachother to an address only listed on a new zealand website.
Weird, sounds very much like the spam system explained on the list not too long ago.
-----BEGIN PGP SIGNED MESSAGE-----
I'm trying to get a better understanding of how the DSL network is
integrated together in New Zealand. I'm hoping someone can help
explain to me why their is such big latency gaps in some of the
Below is the output from a traceroute between me on Ihug Jetstart DSL
and an Xtra Jetstream connection with a Static IP.
1 192.168.1.2 (192.168.1.2) 0.299 ms 0.148 ms 0.142 ms
2 203-118-173-1.adsl.ihug.co.nz (18.104.22.168) 56.506 ms 57.695
ms 60.022 ms
Is 22.214.171.124 an Ihug router or a Telecom router?
3 192.168.253.225 (192.168.253.225) 66.866 ms 58.911 ms 61.027 ms
4 192.168.254.42 (192.168.254.42) 70.011 ms 69.028 ms 59.954 ms
5 v-93-tig-nz-akl-core-1.ihug.net (126.96.36.199) 70.147 ms
69.346 ms 68.020 ms
6 203-109-156-98.ihug.net (188.8.131.52) 69.904 ms 67.363 ms
7 a5-0-0-40.akcr5.global-gateway.net.nz (184.108.40.206) 210.854 ms
203.399 ms 185.586 ms
This is my real question... why is this such a big lag between 6 & 7.
140ms seems to be very high? Is there some type of bandwidth gap
between Ihug and Global Gateway?
Everything below this point is irrelevant....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----