Why is it that open relays are so common in European/Asian networks?
Granted, we still have a long way to go in the US, but at the current
rate, I'll likely be blocking all of RIPE and especially APNIC by
September. How long does it take to absorb a clue?
Just curious.
Cheers,
Brian
A long time. We're blocking huge parts of the Asian and European networks
right now in the Spamblock system, and in fact, I'd estimate that 80% of all
entries made are non-US these days.
Hi,
One reason might be that clueless folk in the US that complain to APNIC or
RIPE (or NANOG) directly instead of looking stuff up in the appropriate
whois database ("ARIN has all the IP information, right?") and complaining
to the people who can actually do something about the problem.
Another reason might be that until very recently, sendmail shipped with
relay enabled by default and very little in the way of easily understood
(particularly by non-native English speakers) documentation on how to
disable relaying in the shipped tarball.
Not that either matters, of course. Everyone has the same access to
knowledge and skills as ISPs in the US, right? Besides, it is so much more
productive (or at least cathartic) to whine to a US based mailing list that
targets ISPs in North America.
If you think blocking all of Europe/Northern Africa/Former Soviet Union and
Asia/Pacific helps you out (after all, the US is the only part of the
Internet that matters, right?), knock yourself out. To give you a hand:
APNIC allocates out of 202/7, 210/7, and 61/8 (althought we haven't
allocated anything out of 211/8 to date) -- should make filters easy.
Regards,
-drc
(not speaking in any way for APNIC, after all, I've resigned)
David R. Conrad wrote:
Hi,
One reason might be that clueless folk in the US that complain to APNIC or
RIPE (or NANOG) directly instead of looking stuff up in the appropriate
whois database ("ARIN has all the IP information, right?") and complaining
to the people who can actually do something about the problem.
Keep in mind that some of these "clueless folk" may expect individually
assigned CIDRs to be registered accurately, and are complaing to the
registered contact for the block. If these blocks aren't
registered/SWIPed appropriately, your argument is weak.
As to the "people who can actually do something about the problem",
generally they are the problem. Polite requests for resolution
regularly fall on unhearing ears. The problem is escalating to the
point where it's much more convenient to simply block an entire /16 or
larger, than to attempt to contact the appropriate person, which is
quite unfortunate.
Another reason might be that until very recently, sendmail shipped with
relay enabled by default and very little in the way of easily understood
(particularly by non-native English speakers) documentation on how to
disable relaying in the shipped tarball.
Not that either matters, of course. Everyone has the same access to
knowledge and skills as ISPs in the US, right? Besides, it is so much more
productive (or at least cathartic) to whine to a US based mailing list that
targets ISPs in North America.
If you know of a more appropriate forum for such a question, I'm
listening. This was indeed more a legit question (with a possibly
poorly-chosen subject line) than a whining waste of space.
Out of curiosity, are you advocating a certain measure of irresponsible
network management based on sendmail's somewhat cryptic nature? God
forbid a net manager should open a book.
If you think blocking all of Europe/Northern Africa/Former Soviet Union and
Asia/Pacific helps you out (after all, the US is the only part of the
Internet that matters, right?), knock yourself out. To give you a hand:
APNIC allocates out of 202/7, 210/7, and 61/8 (althought we haven't
allocated anything out of 211/8 to date) -- should make filters easy.
You've entirely misinterpreted my post. If it appeared as nothing more
than an unsubstantiated rant, please accept my apology.
Brian
Wrong. Most people (clueless or not) only know of Internic and therefore
do not look at Ripe or Apnic. Even when it says in the Internic (now
Arin) entry to look at whois.ripe.net for proper delegation, they ignore
it since it is one line and not prominent. ARIN refuses to add comments
last time I requested. The end result is I get about a dozen spam
complaints a week from users who are simply complaining to the wrong
person.
Hank Nussbacher
Brian,
Keep in mind that some of these "clueless folk" may expect individually
assigned CIDRs to be registered accurately, and are complaing to the
registered contact for the block.
APNIC has a policy that _all_ "permanent" reassignments made by ISPs must
be recorded in the APNIC database before address space is considered used.
This policy is recursive; it includes address space assigned to customers
of ISP customers of ISPs (etc), even to the point of individual /32s
assigned in the case of static dialups or virtual hosting.
I believe RIPE-NCC has a similar policy (although their hierarchy is much
shallower that the AP region's for reasons I've never been to clear on).
Of course, the fact that an entry is in a database (any database) doesn't
mean it is valid, either when it was inserted or anytime thereafter, but
that is a generic problem with the registry database "system" (to use the
word loosely), rather than a complaint that can be directed at non-US
registries alone.
If you know of a more appropriate forum for such a question, I'm
listening.
More appropriate than NANOG might be "Internet Engineering Planning Group"
<iepg@iepg.org> and "Asia Pacific Operators Forum" <apops@apnic.net>. I
think RIPE-NCC has something similar (eof@ripe.net?). You are missing the
point, however. In any of these forums you are preaching to the converted
-- I'd be surprised (but sadly, not very) if many of the folks that get
mail through iepg, nanog, apops, or the RIPE-NCC counterpart have open
relays. The people you should be complaining to are the perps themselves
or their upstreams -- they are the only ones who can have an impact (but
you know this).
Out of curiosity, are you advocating a certain measure of irresponsible
network management based on sendmail's somewhat cryptic nature?
I'm advocating nothing. I provided two possible reasons why it may appear
to you that AP or EU regional networks have more open relays than their NA
counterparts and provided you with the prefixes APNIC allocates to
facilitate your filters. One could argue that blocking entire continents
is "a certain measure of irresponsible network management", at least from
the perspective of the customer, but I won't argue the point as I assure
you, I am more tired of spam than most.
God forbid a net manager should open a book.
Ah, sorry. I must have missed the announcement of Allman's book translated
into Thai, Mongolian, Bangala, (etc.). Hmm. Must not have been translated
into English, given the amount of open relays in the US...
Actually, I feel this typifies one of the Internet's Achilles heels --
critical portions of the Internet infrastructure have truly broken defaults
and/or missing/broken documentation. Information on how to fix those
portions are generally available only through lore or cryptic crib notes
almost always written only in English. Vendors are typically uninterested
in changing the defaults. Yet the problems generated by those defaults
have global impact. Wonder how long it will be before relay is off by
default in Unix distributions (does Sun still have a default broadcast of
all 0s?)...
Regards
-drc
[I should just keep my mouth shut, and pray the thread dies.]
"David R. Conrad" writes:
APNIC has a policy that _all_ "permanent" reassignments made by ISPs must
be recorded in the APNIC database before address space is considered used.I believe RIPE-NCC has a similar policy
Sometimes it doesn't happen.
I can't count the number of times we've queried APNIC, RIPE, etc.,
only to receive the catch-all record. (That's not to complain,
directly, about the state of the databases, merely a statement of
fact.) So that's where we send the complaint. I can count the number
of times such messages have generated a response: five from APNIC,
twice from NORGESNETT, and twice from RIPE.
Its possible that many of them were forwarded, but most of the
sources/relays we've complained to have been "sorry about that", so I
expected to have received some responses -- count: zero.
Note: Don't fear, APNIC isn't out-of-norm, most NSP's are doing the
same.
Of course, the fact that an entry is in a database (any database) doesn't
mean it is valid, either when it was inserted or anytime thereafter,
Aye. This has been hashed over before, but it would be quite helpful
if the registries were to audit their databases periodically.
God forbid a net manager should open a book.
Ah, sorry. I must have missed the announcement of Allman's book translated
into Thai, Mongolian, Bangala, (etc.).
I can't buy this complaint.
Just because someone wrote a program does not mean that that person
should have to publish instructions in every language possible just
because its possible that people everywhere might use it. Whoever
made the choice to use Sendmail should translate the documentation
(man pages, op manual, _and_ web pages) for the target audience.
FYI: The responses received from regional or national registries
were...
APNIC (all): "please send to the registered entity", none was
listed.
NORGESNETT (both): They didn't grasp our request that we be
told who was the next most responsible party (IBM as
it turned out) or that the complaint be forwarded to
that party. Since we have no Norweigean skills on
staff the complaint fell through the cracks. (The
space has since been registered more sanely.)
RIPE #1: "please send to the registered entity", none was
listed.
RIPE #2: "please send to the registered entity", no e-mail
contact information was present in the updated after
our complaint entry.
"David R. Conrad" <davidc@apnic.net> writes:
> APNIC has a policy that _all_ "permanent" reassignments made by ISPs must
> be recorded in the APNIC database before address space is considered used.
> This policy is recursive; it includes address space assigned to customers
> of ISP customers of ISPs (etc), even to the point of individual /32s
> assigned in the case of static dialups or virtual hosting.
>
> I believe RIPE-NCC has a similar policy (although their hierarchy is much
> shallower that the AP region's for reasons I've never been to clear on).
For the record: The RIPE NCC does have the same policy. Looking at the
relative depths of the registration hierarchy and possible explanations
is an interesting idea.
I also fully agree that a single whois interface to all address space
registrations is very desirable. The RIPE NCC and ARIN provide that
using the -a flag on their servers. This is easy for us because we
happen to use almost identical database schemata. The InterNIC and now
ARIN face the problem of a different schema. Exchange between the
databases has been on the agenda for at least 5 years. If it was easy
it would have been done now. If you want the priority raised, talk to
*your* regional registry.
Daniel
Mark,
[I should just keep my mouth shut, and pray the thread dies.]
Bet you forgot your wooden stakes, no?
I can't count the number of times we've queried APNIC, RIPE, etc.,
only to receive the catch-all record.
If you queried an IP address (not a domain name), this means:
a) someone has stolen a prefix (rare)
b) someone has dummied up a prefix in a mail header or something (typical)
c) there is a bug in the database software (happens)
If the prefix has been allocated, it will show up in the APNIC database
(part of the procedure for allocation is updating the APNIC database).
Might show up as the service provider instead of the end user though...
Note: Don't fear, APNIC isn't out-of-norm, most NSP's are doing the
same.
APNIC isn't an NSP.
Aye. This has been hashed over before, but it would be quite helpful
if the registries were to audit their databases periodically.
No argument and it is something APNIC plans on doing (or planned -- can't
speak for APNIC anymore as I no longer run it).
Whoever
made the choice to use Sendmail should translate the documentation
(man pages, op manual, _and_ web pages) for the target audience.
And the chances standard Unix vendors who supply sendmail (etc.) with their
distributions will even include up to date distributions, much less up to
date documentation or even documentation more than a man page are? And you
expect these folks to also translate the documentation?
APNIC (all): "please send to the registered entity", none was listed.
We also tell you how to determine how to find the registered entities in
the canned response.
For reference, I've personally received about 100 complaints about spam
over the past 12 hours, about 85% demanding that APNIC disconnect "our
dialup customer" which has resulted in the spam, and about 50% you have
included the response from InterNIC that states "please check the APNIC
database prior to contacting APNIC". I don't even bother to respond any more.
Regards,
-drc
[The original point was that the proper registry can be difficult to
find so that meaningful results can be obtained. One poster lamented
that the whois "system" should do the right thing. ARIN may be doing
so these days.]
"David R. Conrad" writes:
b) someone has dummied up a prefix in a mail header or something (typical)
c) there is a bug in the database software (happens)
I doubt B since the IP address queried was that of the TCP peer.
Granted it could have been a spoofed session, but that would have
required a level of expertise that I've never seen used merely to
attempt delivery of a few thousand pieces of e-mail.
I suspect either C, flaky data, or C due to flaky data.
If the prefix has been allocated, it will show up in the APNIC database
(part of the procedure for allocation is updating the APNIC database).
Which is what seemed to have been assumed by the people that sent the
responses we received. However they did not include the "correct"
information.
When we query the registries (which we try to avoid since its such a
slow, and imprecise mechanism) we first try the exact address, then we
back-off (class-wise) until either a non-catch-all response is
received, or an /8 is achieved.
Might show up as the service provider instead of the end user though...
That is what we usually locate, as is who we prefer to contact.
I should clarify that we have made many queries to the various
registries, and in most cases we have received sufficiently precise
information so as to avoid a "please advise or forward" situation.
The problem usually lays in the remaining, imprecise, cases.
Note: Don't fear, APNIC isn't out-of-norm, most NSP's are doing the
same.APNIC isn't an NSP.
I wasn't clear enough, sorry. What I meant to say was that, amongst
all cases where it was apparent that the database yielded contacts
that almost certainly were not the operators of the source networks
APNIC was not unique in their responses. Specifically, we've also
sent plenty of "please advise or forward" messages to MCI, PSI,
SPRINT, and UUNET (just to name a few) that have yielded the same, or
similar, results as those sent to the registries.
And the chances standard Unix vendors who supply sendmail (etc.) with their
distributions will even include up to date distributions, much less up to
date documentation or even documentation more than a man page are? And you
expect these folks to also translate the documentation?
I certainly do expect it of the vendors. That they don't should not
reflect poorly on Eric.
No "service provider" specific distributions of any MTA exist of which
I am aware. Anyone using a general distribution, or even a service
provider specific one, that did not take the time to examine the
settings for appropriateness are themselves delinquent, rather than
the package's author. Having chosen to provide e-mail services they
should have examined the package in-hand (probably part of a general,
rather than service provider specific, OS distribution) as well as the
alternatives. This should have resulted in them scuttling off to,
e.g., www.exim.org, www.qmail.org, www.sendmail.org, and
www.zmailer.org (to name a few). Information is present at the
Sendmail site describing the pros and cons of the relay settings
extant, and how to change them within several service provisionings.
APNIC (all): "please send to the registered entity", none was listed.
We also tell you how to determine how to find the registered entities in
the canned response.
We used that method to arrive at the address we used. The mail we
sent indicated that you were receiving it due to a lack of additional
information. Since the registries receive so many pieces of mail I
understand the need for a canned response, but one to/in which the
correct data had been appended/inserted would have been much more
helpful.
For reference, I've personally received about 100 complaints about spam
over the past 12 hours, about 85% demanding that APNIC disconnect "our
dialup customer" which has resulted in the spam, and about 50% you have
included the response from InterNIC that states "please check the APNIC
database prior to contacting APNIC". I don't even bother to respond any more.
I can understand, and I do sympathize -- you will never have received
such mail from us. What are those of us that do query the registry
properly, yet still land on the registry's entry supposed to do? It
may be that ARIN recognizes this catch-22, and has begun to act in a
fashion that helps.
What we have received from the (previously named) registries, and from
several (just named) NSP's ...
APNIC: Usually no response, nor evidence of forwarding. Five "please
send to the registered entity" but no information as to who
that would be.
MCI: No response, nor evidence of forwarding. In one case a voice
call to their security department caused a message to be
passed to the source network, which responded within an hour.
(By then the relay had been totally absorbed by us, so the
useful net effect was nil.)
NORGESNETT: Good intentioned responses to the first two messages.
The next three garnered no response, nor evidence of
forwarding. We've since had no reason to send to them as: a)
analysis showed that the addresses were IBM dial-up ports, and
b) the registry database now clearly shows this anyway.
PSI: Usually no response, nor evidence of forwarding. Twice "please
send to the registered entity" but no information as to who
that would be.
RIPE: Usually no response, nor evidence of forwarding. Twice "please
send to the registered entity" but no information as to who
that would be. In one of the later cases the registry had
been updated after our message was transmitted, but the new
information did not contain an e-mail entry.
SPRINT: No response, nor evidence of forwarding.
UUNET: No response, nor evidence of forwarding.
An example:
Note: ARIN is the correct NIC to query these days, at the time it was InterNIC.
$ whois 203.30.7.44@whois.internic.net
[originally this yielded a "not found" response]
$ whois 203.30.7.0@whois.internic.net
[originally this yielded a "not found" response]
$ whois 203.30.0.0@whois.internic.net
[originally this yielded a "not found" response]
$ whois 203.0.0.0@whois.internic.net
[originally this yielded the following response]
[rs.internic.net]
Asia Pacific Network Information Center (APNIC2)
[...]
Netname: APNIC-CIDR-BLK
Netblock: 202.0.0.0 - 203.255.255.0
Maintainer: AP
Coordinator:
Gampe, Paul A. (PAG4-ARIN) hostmaster@APNIC.NET
+81-3-5500-0480 (FAX) +81-3-3353-6096
[...]
*** please refer to whois.apnic.net for more information ***
*** before contacting APNIC ***
*** use whois -h whois.apnic.net <object> ***
[...]
Okay, we know we have to parse responses for the "please refer to"
redirection -- we know what to do ...
$ whois 203.30.7.44@whois.apnic.net
[teckla.apnic.net]
inetnum: 203.0.0.0 - 203.63.255.255
netname: AUNIC-AU
[...]
person: Geoff Huston
[...]
e-mail: gih@aarnet.edu.au
[...]
The response has no indication that AUNIC should be polled for more
information -- Geoff probably has the same problem you do as a result
of this. Fortunately we know about the AUNIC whois server, yet ...
$ whois 203.30.7.44@whois.aarnet.edu.au
[nico.telstra.net]
inetnum: 203.30.0.0 - 203.30.15.255
netname: AUSSIENET-AU
[...]
admin-c: AK600
tech-c: AK600
[...]
$ whois AK600@whois.aarnet.edu.au
[nico.telstra.net]
No entries found for the selected source(s).
So Geoff still would have gotten the mail.
These days we also tend to try rwhois using root.rwhois.net ...
$ rwhois whois 203.30.7.44
Referral Whois (RWhois) spec version 1.0 (InterNIC V-1.0B9.2)
network:Class-Name:network
network:Auth-Area:0.0.0.0/0
network:ID:NETBLK-AUSSIENET-AU.0.0.0.0/0
[...]
network:Tech-Contact;I:AK600.NET
[...]
Which still isn't quite enough, so an extra pass is needed.
$ rwhois ak600.net
Referral Whois (RWhois) spec version 1.0 (InterNIC V-1.0B9.2)
[...]
contact:Email:andrew@AUSSIE.NET
[...]
Finally a contact that should be near enough to be useful. This is a
sufficiently large block that its unlikely that aussie.net is the
actual source network, but they should be close enough to be a useful
first step. I always say that to myself, yet often nothing comes of
these messages.
And the point to it all? I suppose I am just restating the original
poster's complaint that it is damned hard to know where to go to get
the ultimate information, as well as a responding poster's desire that
the system do the right thing so that everyone doesn't have to know
the proper incantation to avoid sending mail to people far removed
from the actual source.
It may be that ARIN recognizes this -- a run of this query today
yielded ...
[rs.arin.net]
Asia Pacific Network Information Center (APNIC2) APNIC-CIDR-BLK
202.0.0.0 - 203.255.255.0
The Australian Internet Registry Pty Ltd (NETBLK-AUSTRALIA) AUSTRALIA-CIDR-BLK
203.0.0.0 - 203.63.255.0
aussie.net Pty Limited (NETBLK-AUSSIENET-AU) AUSSIENET-AU
203.30.0.0 - 203.30.15.255
[...]
Our scripts would have selected NETBLK-AUSSIENET-AU for expansion ...
[rs.arin.net]
aussie.net Pty Limited (NETBLK-AUSSIENET-AU)
[...]
Coordinator:
Khoo, Andrew (AK600-ARIN) andrew@AUSSIE.NET
61-2-318-2341 (FAX) 61-2-310-3362
[...]
Bingo, there in two steps. (An rwhois-based query also requires two
steps.) The original whois trail required seven, but only yielded a
national registry address.
Mark Milhollan writes:
$ whois 203.0.0.0@whois.internic.net
[originally this yielded the following response]
[rs.internic.net]
Asia Pacific Network Information Center (APNIC2)
[...]
Netname: APNIC-CIDR-BLK
Netblock: 202.0.0.0 - 203.255.255.0
Maintainer: APCoordinator:
Gampe, Paul A. (PAG4-ARIN) hostmaster@APNIC.NET
+81-3-5500-0480 (FAX) +81-3-3353-6096
[...]
Actually it yielded a different coordinator as I remember, I failed to
clip this from the current (ARIN) response.
Hmm, "as I remember" ... that's not the right way. I see I need to
record more of the audit trail.
What about d). Perhaps someone temporarily announced routes for
unallocated space, setup a mail/spam server in that IP space, sent out
their mail, and stopped exporting the route.
Is there a place one can search to see a history of BGP announcements for
a given route?
Jon Lewis writes:
What about d). Perhaps someone temporarily announced routes for
unallocated space, setup a mail/spam server in that IP space, sent out
their mail, and stopped exporting the route.
Absolutely possible, and an enumeration I missed, thanks Jon.
Is there a place one can search to see a history of BGP announcements for
a given route?
I don't know of any.
I'm trying to collect "you have an open relay, here're some
URL's you can go to for info on fixing it"-type messages in
as many languages as possible...I've got Japanese now, does
anybody have any other languages to share/trade?
Contact me privately, I'll happily coordinate this effort.
Once there's a handful avaliable I'll put 'em on the web.
Hi,
"David R. Conrad" writes:
>b) someone has dummied up a prefix in a mail header or something (typical)
>c) there is a bug in the database software (happens)What about d). Perhaps someone temporarily announced routes for
unallocated space, setup a mail/spam server in that IP space, sent out
their mail, and stopped exporting the route.
Actually, that was "a", what I call prefix theft. I figure it is becoming
more and more common, and I know of at least one case where it was an
actual policy of a large network.
<CYNICAL>
However, this isn't a problem anymore given we have not one, but two
proposals on how to authenticate routing announcments. All the rest is
just a small matter of programming.
</CYNICAL>
As an aside, it always amazes me that the Internet even works (particularly
for an infrastructure that the unwashed masses seems to think will replace
the existing telephone network), but I guess the same could be said of any
chaotic (in the non-linear sense) system...
Regards,
-drc
"David R. Conrad" writes:
Actually, that was "a", what I call prefix theft.
Ahh. I see it now, and can't imagine what I thought when I first read
it.
I think I'll see if I can add a call to a looking glass, either during
connection setup or asynchronously during the connection.
I don't see how it can be on the rise. When FDT multihomed, we had to
arrange with both our providers to accept our route. Why aren't all the
big providers putting distribute lists on their customer BGP peers? The
access-lists should change infrequently enough that it wouldn't be a big
deal to maintain, and it would make the net a better place. If I totaly
hose our BGP setup and announce crap to either provider, nobody will be
affected. In fact, I think I did this the first night I setup BGP.
Nothing bad happened.
While they're at it, they could use the same data to setup/maintain
ingress filters. Last I heard, Cisco had finally made it so that
non-logged extended access-list filtered packets are still fast switched.
95% of the spam attacks we see come from the USA, advertising USA services, 99%
with forged headers (yahoo, hotmail, msn, prodigy and earthlink are tops, juno
and bigfoot much less now).
5% and growing are people in Europe who seem to think they can get payment for
spamming on behalf of USA web sites!
However, in late October, Europe will require its member states to enact
legislation to control unsolicited communication of any type. Hopefully the
respective gov'ts will do something effective rather than try and sidestep
the issue (just after pigs master basic aerobatics :-).
Agreed that a lot of open relays seem to exist in JP... and there
are significant numbers in Europe as suggested. The time zone and language
differences are going to be a big PITA in terms of getting the problems sorted
quickly. In Japan, they seem to think <postmaster> is optional!!!
The UK is getting its act together on spam... as spammers's targets for relays
are driven out of the USA they are hitting further down the chain (machines on
slower lines rather than close to the cores), targeting ISP's customers not the
ISPs. I suspect that Europe will be the next spammers's paradise regardless of
gov't support etc.
Perhaps we should all hope that the year2000 bug will break all broken systems
totally, leaving only the clueful to run the place properly.
Paul
[snip]
Oh, I hate stepping in on this sort of argument.
Agreed that a lot of open relays seem to exist in JP... and there
are significant numbers in Europe as suggested. The time zone and language
differences are going to be a big PITA in terms of getting the problems sorted
quickly. In Japan, they seem to think <postmaster> is optional!!!
If you have problems with a JP domain, send it to me and I will
see who I can push, shove or generally embarrass in a public forum
in the appropriate language.
The address to send such complaints to will be "abuse@gol.ad.jp", the
usual abuse rules apply, please don't expect personalised responses.
<postmaster> is clearly optional, because reading RFCs is too. ^_^;
More often than not, there is an auto responder there because there
is no postmaster. (I kid you not.)
Getting providers here to institute <abuse> and or even take any
sort of measures against spamming by their own users is an uphill
task.
Peter
----(
Postie, Abuse Dept and all-round dogsbody, @gol.com
Getting providers here to institute <abuse> and or even take any
sort of measures against spamming by their own users is an uphill
task.
I've been working with JD Falk and the CAUCE folks about getting some
resources in japanese together covering MTA configuration and usage of the
RBL among other things.
My personal goal is finding someone willing to actively maintain parts of
the sendmail FAQ and vix's tsi pages in japanese.
Peter
matt
postmaster@interq.or.JP
--matt@bikkle.interq.or.jp-------------------------------------------
Matt Ghali MG406/GM023JP - System Administrator, interQ, Inc AS7506
"Sub-optimal is a state of mind." -Dave Rand, <dlr@bungi.com>