An interesting topic for discussion:
Telecom is installing new equipment in its ADSL network, which handles
traffic congestion in a slightly different way than previously.
Overview
Telecom is installing new equipment in its network, which handles traffic
congestion in a slightly different way than previously.
When a traffic burst exceeds the rated capacity of that connection, any
overflow data is now queued temporarily and sent as soon as the congestion
is cleared - normally within …
[View More]milliseconds. This change should enhance the
experience for most Internet users, however some gaming customers may have
increased sensitivity to other applications running in the background.
To achieve the best online game playing experience, Telecom is working to
ensure that the connections are optimised and queuing is minimised. Users wanting
the best gaming experience should avoid running other applications or PCs on
the same connection or upgrade their connection to a higher speed to ensure
queues are minimised.
Frequently Asked Questions:
Q. Why can multiple users on one connection now not connect when playing
games?
A. Telecom is installing new equipment in the network, which handles
traffic congestion in a slightly different way than previously.
When a traffic burst exceeds the rated capacity of that connection,
any overflow data is now queued temporarily and sent as soon as the
congestion is cleared - normally within milliseconds.
Q. Why has Telecom made this change?
A. This change means that packets of data, which previously may have
been dropped, will now reach their destination. This change should enhance
the experience for most Internet users, however some gaming customers may
have increased sensitivity to other applications running in the background.
Q. This is obviously having a negative effect on my games experience - why
don't you change it back?
A. For the majority of customers, the new queue shaping provides
them with a better Internet experience. Telecom is working to ensure that
the connections are optimised and queuing is minimised. Users wanting the
best gaming experience should avoid running other applications or PCs on the
same connection or upgrade their existing connection to a higher speed to
ensure queues are minimised.
Q. Why didn't you notify customers of this change?
A. Telecom regularly makes changes to its Network and indeed,
announced earlier this year that it was overhauling its JetStream portfolio.
With so many changes being made in various parts of the Network, it is
impractical to notify all customers whenever a change is made.
Q. Isn't this just a ploy to get us on to your 256k plans where we have to
pay for all traffic?
A. Customers are free to choose the most appropriate plan for their
needs. The Xtra JetStream 256k and Full speed plans obviously offer
customers a bigger pipe, so the chances of packets getting dropped or queued
are less.
~ John Doe
_____________________________________________________________
Free, simple, fast, memorable email
Become you(a)EmailAccount.com at http://www.emailaccount.com/
[View Less]
Hi,
Could any operators of 2.4GHz outdoor networks in the Lincoln/Henderson area
please contact me offlist for mutual co-operation in channel usage.
Michael Hallager
Managing Director
Networkstuff Limited
URL: http://www.networkstuff.co.nz
Networkstuff, NZ's leading supplier of high quality used networking equipment.
E-Mail: michael @ networkstuff.co.nz
Member of the NZ Open Source Society.
Member of the Auckland VHF Group.
Amateur radio callsign: ZL1VMH.
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.
Programme
Tony Holmes of BT is attending as guest speaker. He intends to discuss
the following topics:
1. Introduction to ENUM.
2. ENUM …
[View More]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
Email: jennifer.neeley(a)m-co.co.nz
--
Peter Macaulay
Executive Director
InternetNZ
Direct +64 4 495 2113
[View Less]
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.nethttp://www.iconz.co.nz/prefix/
Regards
ICONZ NOC
Email: noc(a)iconz.net
Phone: 09 977 3500
Hi all,
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 210.55.169.1
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.
Server: 210.55.108.130
Address: 210.55.108.130#53
Non-authoritative answer:
1.169.55.210.in-…
[View More]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.
bash-2.05b#
Reminds me of the "old days" when Xtra started up....
Michael Hallager
Systems Administrator
Vivid Computers Ltd
Managing Director
Networkstuff Ltd
[View Less]
Hi All
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 …
[View More]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!
Tony
[View Less]
Hi, team.
[ 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, …
[View More]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
you.
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
here:
http://www.cymru.com/Bogons/index.html
A quick summary of the documents and projects that have been updated
include the following:
HTTP
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)
BGP
Bogon route-server *
RADb
fltr-unallocated
fltr-martian
fltr-bogons
DNS
Bogon (bogons.cymru.com) zone
Monitoring
Bogon prefix monitoring
* All of the bogon peers have received the appropriate BGP prefix
updates.
Please feel free to contact Team Cymru with any comments, questions, or
concerns.
Thanks!
Rob, for Team Cymru.
--
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);
[View Less]
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 …
[View More]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:
99.27.67.200 IANA Reserved
202.163.151.24 Assigned but not announced
89.87.209.213 IANA Reserved
112.188.234.68 IANA Reserved
45.38.78.200 Interop Show Network
244.128.164.67 Unroutable
168.80.80.67 UUNET Internet Africa
64.215.105.194 64.215.105.194
| 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
--
Richard Cox
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Contribute to the SpamCon Legal Fund!! http://www.spamcon.org/legalfund/
[View Less]
Hey guys,
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 202.37.246.18 (Global-gateway)
eg.
…
[View More]traceroute 89.87.209.213
traceroute to 89.87.209.213 (89.87.209.213), 64 hops max, 44 byte packets
1 gateway (219.88.241.241) 1.679 ms 2.403 ms 1.358 ms
2 fe0-0.cr1.idc.orcon.net.nz (219.88.242.250) 0.863 ms 0.872 ms 0.852 ms
3 fe-1.qos2.idc.orcon.net.nz (219.88.242.226) 1.134 ms 1.004 ms 1.128 ms
4 219.88.242.233 (219.88.242.233) 1.774 ms 1.906 ms 1.567 ms
5 202.50.245.33 (202.50.245.33) 39.962 ms 93.651 ms 6.643 ms
6 ge-0-3-0-6.akbr3.global-gateway.net.nz (202.37.246.18) 6.165 ms !N^C
Ip addresses they were sent from:
99.27.67.200
202.163.151.24
89.87.209.213
112.188.234.68
45.38.78.200
244.128.164.67
168.80.80.67
64.215.105.194
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 45.38.78.200.dnsbl.njabl.org.,]
[type: 127.0.0.9]
RCVD_IN_UNCONFIRMED_DSBL (0.5 points) RBL: Received via a relay in unconfirmed.dsbl.org
[RBL check: found 45.38.78.200.unconfirmed.dsbl.org.]
RCVD_IN_BL_SPAMCOP_NET (3.0 points) RBL: Received via a relay in bl.spamcop.net
[RBL check: found 45.38.78.200.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.
Barry Murphy
[View Less]
