we all knew that profitable large network owners would change the
landscape
compared to merely ebitda-positive large network owners, and here's an
example of how big company cost management practices can go up against
reasonable and customary internet behaviour and pretty much ignore it.
Having
I used RT a looong time ago around 1998 1999 and liked it, but OTRS,
compared to THEN features is superior. I haven't tried RT yet, although I
did start installing it and I know I gave up on RT once when trying to
install it but got OTRS up and running rather easily, so I can't say about
their
Speaking on Deep Background, the Press Secretary whispered:
Having an abuse@ email address may be customary Internet behavior but it
is no longer reasonable. The fact is that SMTP email has outlived its
usefulness and needs to be replaced with something that provides a chain
of
On Mon, 4 Aug 2003, William Devine, II wrote:
I used RT a looong time ago around 1998 1999 and liked it, but OTRS,
compared to THEN features is superior. I haven't tried RT yet, although I
did start installing it and I know I gave up on RT once when trying to
install it but got OTRS up and
On Mon, 04 Aug 2003 13:38:37 BST, [EMAIL PROTECTED] said:
The web of trusted email servers would use a new and improved mail
transfer protocol (NIMTP) that would only be used to exchange email
between trusted servers. Users could continue to use authenticated SMTP to
initiate the sending
Also the fact that the transition time would require many companies to
run 2 or more protocols. And simply put the majority of SMTP isn't
bad, if fully implemented as a single standard and implemented by
vendors and developers.
But the idea isn't bad, but may have massive cost additions, if
Hi, sorry for this low-level question, but at least I'm not posting in html.
:)
My company owns a class C, and we're switching ISPs. The new provider is
telling us that they can start announcing, without us having to tell the old
provider to stop announcing. I.e., a 2-3 day period where both
If the old provider is advertising the prefix based on your
advertisement to them (you're running BGP), then their advertisement
should cease shortly after your link to them goes down. Likewise, the
new provider would only propagate the advertisement after you advertise
it to them.
Michael
H.
On Mon, 4 Aug 2003, Mike Donahue wrote:
My company owns a class C, and we're switching ISPs. The new provider is
telling us that they can start announcing, without us having to tell the old
provider to stop announcing. I.e., a 2-3 day period where both are
announcing our class C.
This
Hi, sorry for this low-level question, but at least I'm not posting in html.
:)
My company owns a class C, and we're switching ISPs. The new provider is
telling us that they can start announcing, without us having to tell the old
provider to stop announcing. I.e., a 2-3 day period where
On Fri, Aug 01, 2003 at 07:52:09PM -0400, [EMAIL PROTECTED] said:
Is there a way to block html mail at the edge using a proxy ro something?
anything's possible given sufficient resources, but this is not a workable
solution - this needs to be addressed at the client level. Anything else will
Hi, NANOGers.
] See show ip bgp inconsistant-as on cisco. YMMV.
On that theme, please also see:
http://www.cymru.com/BGP/incon01.html
http://www.cymru.com/BGP/incon01-list.html
Thanks,
Rob.
--
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);
Valdis Kletnieks [EMAIL PROTECTED] wrote:
1) What *immediate* benefits do you get if you are among the first to
deploy? (For instance, note that you can't stop accepting plain old
SMTP till everybody else deploys).
The immediate benefit (as sender) is that you reduce the (now
On Thu, Jul 31, 2003 at 09:09:34PM +0300, [EMAIL PROTECTED] said:
[snip]
What we need is a new programming paradigm, capable of actually producing
secure (and, yes, reliable) software. C and its progeny (and program
now, test never lifestyle) must go. I'm afraid it'll take laws which
Is it a class C, or a /24?
Regardless, longest match wins. If old provider is announcing your space as part of a
larger announcement, you'll be a bad netizen for a few days because you're violating
the RFCs concerning inconsistent AS, but your traffic will swing almost entirely over
to new
I would have though people would have learned by now that
there is no technical solution to spam. You can go ahead
with all these wonderfully expensive
authentication/filtration/insertantispambuzzword systems until
the cows come home and you will +_still_+ recieve spam.
Regards,
Neil.
On Mon, Aug 04, 2003 at 08:35:14PM +0200, Mikael Abrahamsson wrote:
On Mon, 4 Aug 2003, Mike Donahue wrote:
My company owns a class C, and we're switching ISPs. The new
provider is telling us that they can start announcing, without us
having to tell the old provider to stop announcing.
We have sensors in our datacenters that report, among other things,
humidity.
One data center is exceeding the predefined humidity alerts of the
devices, but given that cisco says the operating humidty of routers is
10% to 85%, I dont know if humidity of, say, 65% is anything to worry
about.
| and when I should
| complain to the datacenter operators? (References I can point to would
| be nice.)
When your equipment starts to rust ;)
I don't have any technical references, but I think that anything over
65% is probably too much. Most facilities I have equipment in do not
exceed that
On Mon, 04 Aug 2003 19:41:35 BST, Richard D G Cox [EMAIL PROTECTED] said:
The immediate benefit (as sender) is that you reduce the (now ever-increasing)
risk of your mail being rejected by filtration processes and will be trusted
on arrival; the benefit for the recipient is of course less
IIRC, too low a humidity level makes static electricity a problem. Too high makes
the cold air condense on your equipment. 60-65% sounds about right.
Todd Mitchell - lists wrote:
| and when I should
| complain to the datacenter operators? (References I can point to would
| be nice.)
On Mon, Aug 04, 2003 at 01:02:46PM -0700, Steve Francis wrote:
And reasonable thresholds that I can tolerate, and when I should
complain to the datacenter operators? (References I can point to would
be nice.)
depends what's in your SLA. If it states 40-65%, and you notice it's
over 68% or
For a datacenter with a single controlled area the ideal range for relative
humidity (RH) is in the neighborhood of 35% to 50%.
Here are some data points:
1) Static electricity is minimized when RH is at or above 35%.
2) RH below 25% can cause embrittlement of hygroscopic materials
I'm all for raising the bar on attackers and having end networks implement
proper source filtering, but even with that 1000 nt machines pinging 2
packet per second is still enough to destroy a T1 customer, and likely
with 1500 byte packets a T3 customer as well. You can't stop this without
Filtering the bogons does help, and everyone should perform anti-spoofing
in the appropriate places. It isn't, however, a silver bullet.
it's necessary but not sufficient.
anti-spoofing is useful, but vastly insufficient, and hence not necessary
randy
anti-spoofing eliminates
Filtering the bogons does help, and everyone should perform anti-spoofing
in the appropriate places. It isn't, however, a silver bullet.
it's necessary but not sufficient.
anti-spoofing is useful, but vastly insufficient, and hence not necessary
anti-spoofing eliminates certain avenues of
On Mon, Aug 04, 2003 at 05:28:07PM -0400, [EMAIL PROTECTED] wrote:
I'm all for raising the bar on attackers and having end networks implement
proper source filtering, but even with that 1000 nt machines pinging 2
packet per second is still enough to destroy a T1 customer, and likely
On Mon, Aug 04, 2003 at 12:16:12PM -0400, [EMAIL PROTECTED] wrote:
On Mon, 04 Aug 2003 13:38:37 BST, [EMAIL PROTECTED] said:
The web of trusted email servers would use a new and improved mail
transfer protocol (NIMTP) that would only be used to exchange email
between trusted servers.
Randy Bush wrote:
anti-spoofing eliminates certain avenues of attack allowing one to focus
on remaining avenues, and hence (as Vix stated) is necessary but not
sufficient.
it turns 1% of the technical problem into a massive social business
problem which, even if it was solvable (which it
Filtering the bogons does help, and everyone should perform anti-spoofing
in the appropriate places. It isn't, however, a silver bullet.
it's necessary but not sufficient.
anti-spoofing is useful, but vastly insufficient, and hence not necessary
anti-spoofing eliminates certain avenues
On Mon, Aug 04, 2003 at 05:28:07PM -0400, [EMAIL PROTECTED] wrote:
I'm all for raising the bar on attackers and having end networks implement
proper source filtering, but even with that 1000 nt machines pinging 2
packet per second is still enough to destroy a T1 customer, and likely
On Mon, Aug 04, 2003 at 04:59:53PM -0500, Jack Bates wrote:
on has to contact each IP owner and find out if spoof protection is
enabled.
it's worse than that. If they have it enabled (eg: 10.0.0.0/24 has
it enabled), but nobody else does, it allows everyone else to spoof
from the
it all comes down to filtering, filtering, filtering.
announcement filtering, anti-spoof filtering, peer filtering.
If you're not doing this, you *SHOULD* be. I know it's hard
to do these things in the current business environment. Those of
you that can, please take
Hi, NANOGers.
] Also, if you can't do it everywhere, doing it where you _can_ is preferable to
] not doing anything at all.
Indeed, every little bit helps. We will win these battles by
degrees, folks, not through a single panacea. So, with that
said, I have to make a shameless plug for the
Hi, NANOGers.
] For those of you that are doing IPv6 deployments, might I suggest
] you also take the time to do the same? I know that Cisco has v6 u-rpf
] support already.
It's shameless plug and solicitation of feedback day here at Team
Cymru. :) We have put together a very rough
Date: Mon, 4 Aug 2003 18:50:36 -0400 (EDT)
From: [EMAIL PROTECTED]
And so we should do nothing?
If a _few_ networks null-route abusers, said networks isolate
themselves. If _all_ networks cut off abusers, who becomes the
island?
Fixing the Internet is difficult. What can't be tackled
[EMAIL PROTECTED] writes:
And so we should do nothing?
of course not. but the first thing to do is ignore naysayers. anybody
who tells you something can't be done should be suspected of extreme and
pervasive laziness until either they or you prove otherwise.
--
Paul Vixie
After several run-ins with Edge 1 Networks [69.44.28.0/22] having their
machines hijack victim machines on our networks infected with Jeem,
and then making their spam runs, I've had it. I have reported both to
Edge 1 and their parent Williams Communications Group [AS7911] with no
result
On Mon, 04 Aug 2003 23:35:24 -0400
Jeff Kell [EMAIL PROTECTED] wrote:
Todd Mitchell - lists wrote:
| and when I should
| complain to the datacenter operators? (References I can point to would
| be nice.)
When your equipment starts to rust ;)
I don't have any technical
On Mon, 4 Aug 2003, Jack Bates wrote:
Randy Bush wrote:
anti-spoofing eliminates certain avenues of attack allowing one to focus
on remaining avenues, and hence (as Vix stated) is necessary but not
sufficient.
it turns 1% of the technical problem into a massive social business
Here is a company who thinks they have a solution for spam
http://www.nwtechusa.com/ironmail-zd-srit-enterprise-security.html
-Henry[EMAIL PROTECTED] wrote:
I would have though people would have learned by now that there is no technical solution to spam. You can go ahead with all these
41 matches
Mail list logo
