I received an off-list request: "Could you clarify what precisely you
are trying to secure?" I fear that perhaps I am still too vague.
When one accepts an email[*], one wishes for some sort of _a priori_
information regarding message trustworthiness. DKIM can vouch for
message authenticity, but
Stardate Mon, 14 Apr 2008, Suresh Ramasubramanian's log:
SR> From: Suresh Ramasubramanian
SR> Looks like what various people in the industry call a "reputation
SR> system"
I started responding; Suresh's reply came as I was doing so, and put it
very succinctly. Reputation system, but inter-"netw
SL> Date: Mon, 14 Apr 2008 14:47:12 +1200 (NZST)
SL> From: Simon Lyall
SL> The question is what tool are people going to use to talk to people,
SL> government bodies and companies that they are not "friends" with?
SL> Even if the person you want to contact is on IM it is likely they
SL> will bloc
AC> Date: Mon, 14 Apr 2008 10:18:40 +0800
AC> From: Adrian Chadd
AC> There already has been a paradigm shift. University students
AC> ("college" for you 'merkins) use facebook, myspace (less now,
AC> thankfully!) and IMs as their primary online communication method.
IOW: "Must establish trust O
Bottom line first:
We need OOB metadata ("trust/distrust") information exchange that scales
better than the current O(N^2) nonsense, yet is not PKI.
And now, the details... which ended up longer reading than I intended.
My apologies. As Mark Twain said, "I didn't have time to write a short
lett
FBi> Date: Sat, 12 Apr 2008 15:42:29 -0500
FBi> From: Frank Bulk - iNAME
FBi> Sounds like the obvious thing to tell customers complaining about
FBi> their e-mail not getting to Yahoo! is to tell them that Yahoo!
FBi> doesn't want it.
Obviously. That's when the client asked if their servers (per
JA> Date: Fri, 11 Apr 2008 10:22:11 -0400
JA> From: Joe Abley
JA> To return to the topic at hand, you may already have outsourced the
JA> coordination of your boycott to Yahoo!, too! They're already not
JA> accepting your mail. There's no need to stop sending it! :-)
Except for queue management.
HY> Date: Thu, 10 Apr 2008 16:17:08 -0400
HY> From: Henry Yen
HY> Naaah. I hear that Microsoft is going to buy Yahoo!, so this
HY> problem will go away once Yahoo! mail gets folded into Microsoft
HY> hotmail, whereupon things will get soo much better!
Maybe all the 42x responses are an atte
FWIW:
I've been tempted to implement sort of a "reverse blacklisting". If an
(MX|provider) trips a 4xx threshold, have the local MTA s/4/5/ on emails
to the problem (MX|domain). If it trips a 5xx threshold, including
"upgraded" 4xx responses, simply refuse delivery altogether at the local
end.
BS> Date: Thu, 10 Apr 2008 13:30:06 -0400 (EDT)
BS> From: Barry Shein
BS> Is it just us or are there general problems with sending email to
BS> yahoo in the past few weeks? Our queues to them are backed up though
BS> they drain slowly.
[ snip details ]
BS> Just wondering if this was a widesprea
DI> Date: Mon, 04 Jun 2007 15:22:11 -0400
DI> From: Dave Israel
DI> So you make end devices unaddressable by normal means, and while it
DI> shouldn't give them more security, it turns out it does. No matter
DI> how much it shouldn't, and how much we wish it didn't, it does.
"Hey, this so-called
JS> Date: Mon, 04 Jun 2007 12:20:38 -0700
JS> From: Jim Shankland
JS> If what you meant to say is that NAT provides no security benefits
JS> that can't also be provided by other means, then I completely
What Owen said is that "[t]here's no security gain from not having real
IPs on machines". Th
GE> Date: Thu, 15 Mar 2007 16:49:20 -0500 (CDT)
GE> From: Gadi Evron
[ tongue perhaps only slightly in cheek ]
GE> Some things the NOC used to help us with quite lot, that were not
GE> directly related to their obvious job description:
GE>
GE> 1. Reboots (as specified earlier).
GE> 2. Getting
la> Date: Tue, 13 Mar 2007 13:03:17 -0400
la> From: list account
la> In my limited experience ARIN seems to not want to work with the
la> small operator.
Half a dozen years back, I'd have agreed and then some. For the past
few years, I'd beg to differ.
Judging by the rest of your message, I w
SW> Date: Fri, 17 Nov 2006 15:56:53 +
SW> From: Stephen Wilcox
SW> you can override it (on cisco) with allow-own-as
s/allow-own-as/allowas-in/
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-c
SS> Date: Fri, 14 Jul 2006 13:38:31 -0500
SS> From: Stephen Sprunk
SS> Ever used Word or Outlook? They annoyingly "fix" words as you type without
SS> offering multiple choices or even alerting the user that they're doing it.
Yes. One of the first "features" that I shut off.
SS> OpenDNS's typ
(Note that I've not examined OpenDNS's offering, so I'm _not_ pretending
to comment on what they do.)
Let's quit looking at overly-simplistic correction mechanisms. Do spell
checkers force autocorrection with only a single choice per misspelled
word?
Return an A RR that points -controlled syste
BS> Date: Thu, 13 Jul 2006 14:35:10 -0400
BS> From: Barry Shein
BS> Sarcasm aside isn't the right answer, for starters, software
BS> interfaces for kids?
Are you proposing Bob.NET?
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsma
SMB> Date: Mon, 10 Jul 2006 23:40:02 -0400
SMB> From: Steven M. Bellovin
[ snipping points to which I'm not responding ]
SMB> The third is that not all the world is a web site.
Indeed, different apps have different requirements. SRV-ish granularity
would be useful.
Eddy
--
Everquick Interne
RB> Date: Fri, 23 Jun 2006 11:33:43 -0400
RB> From: Robert Boyle
RB> Now THAT is impressive compression! I don't know what your former company
RB> did, but they should focus on selling that compression technology. ;)
Irrational numbers can be described in finite space, yet extend
indefinitely wi
IvB> Date: Mon, 19 Jun 2006 15:40:50 +0200
IvB> From: Iljitsch van Beijnum
IvB> And is NANOG now officially an IETF working group...?
More interaction between IETF and NANOG is good. Kudos to SMB for
trying to inspire more of it.
Eddy
--
Everquick Internet - http://www.everquick.net/
A divisi
CLM> Date: Wed, 14 Jun 2006 04:46:31 + (GMT)
CLM> From: Christopher L. Morrow
CLM> is it really that hard to make your foudry/extreme/cisco l3 switch vlan
CLM> and subnet???
Of course not.
CLM> Is this a education thing or a laziness thing?
Both.
Eddy
--
Everquick Internet - http://www.
JvO> Date: Tue, 13 Jun 2006 21:35:14 -0700
JvO> From: John van Oppen
JvO> It sure seems like this is a good demo of the best practice of
JvO> having customers on their own VLANs with their own subnets. We
JvO> have been doing this since we started offering colo services, is
We actually go so f
AW> Date: Sun, 11 Jun 2006 20:55:42 -0700
AW> From: Andrew Warfield
AW> I'd love a multi-ISP solution. I just assumed that anything involving
AW> more than a single upstream AS across the two links would leave me
AW> having to consider BGP convergence instead of just IGP reconfig. I
AW> didn't
Date: Sun, 11 Jun 2006 19:34:12 -0700 (PDT)
From: [EMAIL PROTECTED]
[A] somewhat cleaner way to do this would be to advertize a less
specific route from the DR location covering the more specific route
of the primary location. If the primary route is withdrawn, voila ..
traffic starts moving
RB> Date: Sun, 11 Jun 2006 17:02:14 -1000
RB> From: Randy Bush
RB> persistent tcp connections from clients would not fare well unless
RB> you actually did the hacks to migrate the sessions, i.e. tcp serial
RB> numbers and all the rest of the tcp state. hard to do.
Actually, the TCP goo isn't to
Date: Wed, 24 May 2006 15:26:15 -0400
From: Valdis.Kletnieks
d: A fish (not a fish anything, just a random posting not related to
anything on topic)
And this one will invariably start a "trout"/"salmon"/"swordfish"/"octopus"
debate.
...at which point someone interjects that an octopus
RAS> Date: Tue, 23 May 2006 03:33:34 -0400
RAS> From: Richard A Steenbergen
RAS> If you're receiving RFC1918 sourced packets
#include "flamewars/urpf.h"
#include "flamewars/pmtud.h"
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsm
DH> Date: Tue, 16 May 2006 18:05:10 -0400
DH> From: David Hubbard
DH> So I'm looking at a company who offers anycasted DNS;
DH> how do I tell if it's really anycasted? Just hop on
DH> different route servers to see if I can find different
DH> AS paths and then do traceroutes to see if they sugge
PC> Date: Tue, 16 May 2006 11:17:10 + (UTC)
PC> From: Peter Corlett
PC> Beyond that, you're paying lots of money for information that has a
PC> finer granularity but is arguably no more accurate.
It's precision versus accuracy -- one of the most basic concepts in the
sciences and engineering
AH> Date: Mon, 15 May 2006 23:24:13 +0100
AH> From: Alexander Harrowell
AH> [W]hen the path is [...] it won't be quite that clear.
Exactly. It's a bit different than triangulating cell towers based on
signal strength.
Since when does the NSA patent things, anyhow? I'd think they would
keep se
Date: Mon, 15 May 2006 17:24:48 -0400
From: [EMAIL PROTECTED]
The NSA was granted a patent for an IP geo-location technology based
on triangulation using latency measures.
It could probably be foiled by this patented technology:
http://www.tinyurl.com/ebu6t
which is equally reliab
RP> Date: Mon, 15 May 2006 21:05:35 +0100
RP> From: Roland Perry
RP> I just tried that, says I'm 100 miles south of where I really am. That's
RP> quite a long way out in a small country like England.
Home cable returned "haven't got a clue".
I tried a couple other netblocks that returned diffe
AC> Date: Mon, 15 May 2006 09:35:47 -0700
AC> From: Ashe Canvar
AC> Can any of you please recommend some IP-to-geo mapping database / web
AC> service ?
AC>
AC> I would like to get resolution down to city if possible.
Many people would.
Don't hope for much better than country granularity -- and
JS> Date: Mon, 8 May 2006 12:07:13 +0800 (CST)
JS> From: Joe Shen
JS> Could it be possible to implement IPv4 Anycast architecture for
JS> radius server farm?
Yes.
JS> Could it be any problem with AAA procedure?
UDP is anycast-friendly. Your biggest problems are likely to be
authentication da
LD> Date: Tue, 25 Apr 2006 09:43:51 +1000
LD> From: Lincoln Dale
LD> I suggest you talk to some of the folks you work with that have to
LD> deal with synchronous replication.
LD>
LD> In the world of storage networking & synchronous I/O, typically
LD> anything higher than 1 msec round-trip latenc
Date: Tue, 25 Apr 2006 10:17:51 +0100
From: [EMAIL PROTECTED]
You have to take a balanced approach to continuity planning.
Otherwise, you risk going bankrupt long before there is
any big catastrophe.
"risk analysis"
Also, I would say that expecting a terror act to knock
out a 65 square m
SS> Date: Thu, 13 Apr 2006 22:22:11 -0700
SS> From: Steve Sobol
Apologies in advance for the OT post...
SS> > Well I just saw your .sig... Can't give any credit to your statement.
SS>
SS> Your choice. I don't see any sense in arguing the point further, as you
SS> probably won't change your mi
ST> Date: Wed, 12 Apr 2006 18:56:44 -0700 (PDT)
ST> From: Steve Thomas
ST> If you accept the message, you can presumably deliver it. In this
Possibly. However, insufficient storage is not the only cause of 4xx
status.
ST> day and age, anyone accepting mail for a domain without first
ST> check
ST> Date: Wed, 12 Apr 2006 10:16:53 -0700 (PDT)
ST> From: Steve Thomas
ST> RFC 2821?
ST>
ST> ...the protocol requires that a server accept responsibility
ST> for either delivering a message or properly reporting the
ST> failure to do so.
How does one properly report delivery failure to a
BD> Date: Tue, 11 Apr 2006 23:47:11 -0400
BD> From: Brian Dickson
BD> As to the liability issue, it is easy enough to envision that
BD> someone, somewhere, is relying on time results from NTP for a
BD> life-or-death application, like a medical device, and is innocently
BD> an impacted third party
LL> Date: Wed, 12 Apr 2006 01:10:09 +0200
LL> From: Lars-Johan Liman
LL> [I just happened to see this, browsing at high speed, so please
LL> forgive me, if I'm out of context.]
I was primarily referring to taking the load away from DIX. :-)
However, as long as you raise a few points...
LL> If
Date: Tue, 11 Apr 2006 16:30:11 -0400
From: Valdis.Kletnieks
I suppose pointing out that the Internet works because providers
*cooperate* and *agree on protocols* would be pointless
To a certain [limited] extent, anyway, as countless NANOG-L threads
prove time and again. Of course, it
TV> Date: Mon, 3 Apr 2006 09:25:40 -0400 (Eastern Daylight Time)
TV> From: Todd Vierling
TV> Note that Xen in particular has major advantages over some similar products
TV> because it eliminates CPU-consuming system trap hackery needed to emulate
TV> hardware devices and page-table mappings. Xen
FB> Date: Sat, 1 Apr 2006 13:26:51 -0600
FB> From: Frank Bulk
FB> The majority of U.S.-based IP TV deployments are not using MPEG-4, in fact,
FB> you would be hard-pressed to find an MPEG-4 capable STB working with
FB> middleware.
*nod*
Again, I don't see how AT&T can claim "DSL is fast enough"
JL> Date: Sat, 1 Apr 2006 14:02:13 -0500 (EST)
JL> From: Jon Lewis
JL> Maybe they meant that the typical end-user windows IP stack has small enough
JL> TCP windows that when you take into account typical latency across the
JL> internet, those users just can't utilize their high bandwidth links du
Google for: telecommunications bill 2006
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794
MA> Date: Sat, 1 Apr 2006 08:34:36 +0200 (CEST)
MA> From: Mikael Abrahamsson
MA> http://arstechnica.com/news.ars/post/20060331-6498.html
MA>
MA> "In the foreseeable future, having a 15 Mbps Internet capability is
[ snip ]
MA> Is this something held generally true in the US, or is it just point
JC> Date: Tue, 7 Mar 2006 13:38:50 -0500
JC> From: John Curran
JC> Does anyone have statistics for the present prefix mobility experiment
JC> in the US with phone number portability? It would be interesting to
JC> know what percent of personal and business numbers are now routed
JC> permanently
Greetings all,
The fuss over shim6, routing table size, and long-prefix PI space has
intrigued me. I've started analyzing some [simulated] FIBs and believe
I may have found something interesting. In the name of statistical
sampling, I'd like to analyze some other [simulated] FIBs from diffe
ME> Date: Sat, 4 Mar 2006 19:01:14 -0500
ME> From: Marshall Eubanks
ME> So, if we gave every active ASN a contiguous IPv6 block, and moved
ME> everyone over to IPv6, we would REDUCE the size of the routing table
ME> by a factor of 8.28. That would gain several years of growth before
ME> the routi
SS> Date: Fri, 3 Mar 2006 20:05:36 -0600
SS> From: Stephen Sprunk
SS> > Unfortunately, that involves change from the status quo, and thus
SS> > altruistic action.
SS>
SS> Only when self-interest and altruism are coincident is the latter
SS> consistently achieved.
Witness BCP38, spam/worm cleanu
JA> Date: Fri, 3 Mar 2006 15:42:25 -0500
JA> From: Joe Abley
JA> If there's such a compelling need for native multicast, why has it
JA> seen such limited deployment, and why is it available to such a tiny
JA> proportion of the Internet?
One could ask the same of long-prefix PI availability and a
AO> Date: Thu, 02 Mar 2006 21:42:49 +0100
AO> From: Andre Oppermann
AO> Doing longest-prefix match for high pps rates and high prefix counts
AO> in hardware is complex and expensive.
True, but...
AO> Way more so than doing perfect match on 32 bits (giving 4bn
AO> routeable slots).
...how many
Date: Thu, 2 Mar 2006 10:07:33 +
From: [EMAIL PROTECTED]
[ snip ]
Is there something inherently wrong with independent
organizations deciding where to send their packets?
1. Many a transit seems to think so.
2. Is there an inherent need?
3. Is this DPA+sourceroute cocktail the best met
Sorry to respond to my own post. I omitted a key point:
Note that a calling card doesn't even really approximate source routing.
It's more of an anycasted proxy.
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth,
I hesitate to make an analogy, lest the analogy wars begin...
Sometimes I am forced to use a telephone. I periodically get dead air
or a fast busy. Sadly, my phone skills are rusted. Can someone please
tell me how I select the switches and trunks through which my call is
routed? Thanks.
Date: Wed, 1 Mar 2006 23:46:22 +
From: [EMAIL PROTECTED]
when/if a shim6 proof of concept is built,
Let's look at IPv4 options:
0x83 0x04 0x04 0x?? 0x?? 0x?? 0x??
usually doesn't make it very far. Try
% traceroute -n -g ip.of.some.router and.of.the.destination
from
JAK> Date: Thu, 16 Feb 2006 13:02:14 -0800 (PST)
JAK> From: John A. Kilpatrick
JAK> As long as you can find a customer who wants to be dual-homed and doesn't
JAK> care about PI then great. But most folks who bother to be dual-homed
My primary focus has been on the SOHO users who rarely have mor
Let's look at this a little more carefully.
Pretend for a moment that you operate a network "U". Pretend that
someone else operates a network "E". Pretend that you share a
downstream customer "C". So far, so good.
"C" has several different locations, none of which are directly
interconne
JA> Date: Thu, 16 Feb 2006 12:44:27 -0500
JA> From: Joe Abley
JA> Personally, if I was going to multi-home, I would far prefer that my various
JA> transit providers don't cooperate at all, and have sets of peers and/or
JA> upstream transit providers that are as different as possible from each
JA>
JP> Date: Thu, 16 Feb 2006 12:05:35 -0500
JP> From: John Payne
JP> Are most of the multihomers REALLY a one router shop (implied by your
JP> renumbering is easy comment) - although shim6 could help there I guess.
Dual-homed leaves, particularly those who [would] use DSL and cable?
Yes. And it
SM> Date: Wed, 15 Feb 2006 23:05:20 -0500
SM> From: Scott Morris
SM> I guess my question is, what's the point of asking this question now?
IPv6 is still fairly green-field. Future IPv4 allocations will be made,
too.
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsma
Hopefully this thread will be quick and less convoluted. Rather than
simply alluding to "one prefix per ASN", I'd like to detail an
allocation scheme that works toward that.
Find the largest contiguous block. Split in half. Round to appropriate
boundary. Assign. Space at the end of the
JAK> Date: Wed, 15 Feb 2006 18:51:16 -0800 (PST)
JAK> From: John A. Kilpatrick
JAK> Maybe I missed it, but is there something in your solution that keeps
JAK> dual-homed leaves from having to renumber when changing ISPs? In your
Note: I'm approaching this from a "something to do today" IPv4
st
PJ> Date: Wed, 15 Feb 2006 23:41:15 + (GMT)
PJ> From: Paul Jakma
PJ> reason you decided to strip my address from your reply.>
That portion did, but the rest of my message did not. VZW's 1xRTT
service was getting ugly, so I didn't re-paste your headers from the
original message.
PJ> > B
MK> Date: Wed, 15 Feb 2006 15:35:27 -0800
MK> From: Matthew Kaufman
MK> So this is a good proposal if I*(I-1)/2 < C where
MK> C = number of ASNs issued to dual-homed customers
MK> I = number of ASNs issued to "Transit Providers" said customers might select
MK> from
MK>
MK> (Note that it is bigge
CA> Date: Wed, 15 Feb 2006 14:04:24 -0600
CA> From: Chris Adams
CA> Only one of our multihoming customers has a connection to someone we
CA> already have a connection with, so there's no path between our network
CA> and the rest.
I overlooked something:
You lack connections at the IP layer. Do
AO> Date: Wed, 15 Feb 2006 22:20:21 +0100
AO> From: Andre Oppermann
AO> $realworld always wins.
Translation: "Shift as much cost as you can to as many other entities
as you can."
$realworld says that is short-sighted. If selfishly saving $x increases
the overall economy's cost by $10x, it d
AO> Date: Wed, 15 Feb 2006 22:18:04 +0100
AO> From: Andre Oppermann
AO> So what? The newer 7200s have got NPE-G1's or soon NPE-G2's in them.
AO> Comes with 1G RAM default. It's not that your 7 year old NPE-150 can
AO> still participate in todays DFZ, is it? We're not going to explode
It'll be
PJ> Date: Wed, 15 Feb 2006 20:46:33 + (GMT)
PJ> From: Paul Jakma
PJ> Well you don't need to assign an ASN for Cox and SBC to announce a shared
PJ> prefix for a start off.
Technically true, but administratively not feasible. Coordinating
private ASNs would be similar to coordining RFC1918 s
AO> Date: Wed, 15 Feb 2006 21:41:53 +0100
AO> From: Andre Oppermann
AO> Err, the problem is not the number of AS numbers (other than having to
AO> move to 32bit ones). The 'problem' is the number of prefixes in the
It's both.
AO> routing system. The control plane scales rather well and direc
PH> Date: Wed, 15 Feb 2006 21:14:03 +0100
PH> From: Per Heldal
PH> ...quite the opposite of what I ment to say. Most nanog'ers work in
PH> engineering. The problem is a lack of ops-people turning these
PH> xOG-groups ito xEG-groups instead.
Ah. That makes much more sense. :-)
PH> PS! I prefer
CA> Date: Wed, 15 Feb 2006 14:04:24 -0600
CA> From: Chris Adams
CA> There's a difference: computers (routers) handle the O(N^2) routing
CA> problem, while people would have to handle the O(N^2) cooperative AS
CA> problem.
0.1 ^ 2 < 5000
One must also consider the scalar coefficient.
CA> We ar
CM> Date: Wed, 15 Feb 2006 14:37:44 -0500
CM> From: Chip Mefford
CM> ED> Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_
CM> ED> address space. Each provider announces the aggregate co-op space
CM> ED> via the joint ASN as a downstream.
CM>
CM> This makes a lot of sense.
BTW,
PJ> Date: Wed, 15 Feb 2006 19:02:11 + (GMT)
PJ> From: Paul Jakma
PJ> > Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_ address
PJ> > space. Each provider announces the aggregate co-op space via the joint
PJ> > ASN as a downstream.
PJ>
PJ> This is unworkable obviously: Think
Consider:
RIRs refuse to grant ASNs to dual-homed leaves. Transit providers
_must_ cooperate with each other. Hopefully they coalesce joint ASNs
and space responsibly before sending such merrily along to the global
table.
Voici, non-portable ASNs and "minimum height to ride" requirements
RB> Date: Wed, 15 Feb 2006 11:26:47 -0600
RB> From: Randy Bush
RB> and what was the effect in the ietf? zippo.
Exactly. I'm claiming that the meeting was a more effective vehicle
than a mailing list for the group of people involved -- NANOGers. I'm
also suggesting that, by extension, cross-
MA> Date: Wed, 15 Feb 2006 16:31:56 +0100 (CET)
MA> From: Mikael Abrahamsson
MA> The current routing model doesn't scale. I don't want to sit 5 years from
MA> now needing a router that'll handle 8 million routes to get me through the
MA> next 5 years of route growth.
MA>
MA> PI space for multiho
Funny that shim6 is being mentioned. The corresponding open mic session
at 35 showed how gathering people for 20 minutes of complaining can
effectively replace long, protracted email threads.
There was even unicast chatter about trying to coordinate NOGs with
engineering.
Per, I'd like to ta
AH> Date: Thu, 02 Feb 2006 13:01:27 -0500
AH> From: Alain Hebert
AH> I'm I alone to find this a bit spammy?
Quite possibly. I for one may well be able to cross off some things
from my "need to finish writing" list.
Less work? Open-source tools? (LGPL, but _c'est la vie_, I suppose.)
Far m
DG> Date: Fri, 20 Jan 2006 00:49:12 -0500
DG> From: Daniel Golding
DG> The RBOCs need to get over this - they are floundering around to try and
DG> find a way to recoup network costs. This is one front. IMS is another. I
It's not just RBOCs. Approximately five years back I approached a
cableco
JM> Date: Wed, 14 Dec 2005 20:45:09 -0500
JM> From: Jeff McAdams
JM> And, at that, only after extracting regulatory concessions at both the
JM> state and federal levels basically giving them their monopoly back to
JM> give them "incentive" to half-*ssed roll out that DSL that is, itself, a
JM> me
DO> Date: Fri, 9 Dec 2005 15:08:49 -0800
DO> From: Douglas Otis
DO> This is a third-party acting in good faith, albeit performing a check better
DO> done within the session. In your view, there is less concern about delivery
DO> integrity, and so related DSNs should be tossed. Being done within
MS> Date: Sat, 10 Dec 2005 22:54:24 +1100
MS> From: Matthew Sullivan
MS> RFC 2821 states explicitly that once the receiving server has issued a 250
MS> Ok to the end-of-data command, the receiving server has accepted
MS> responsibility for either delivering the message or notifying the sender
MS
DO> Date: Wed, 7 Dec 2005 17:02:51 -0800
DO> From: Douglas Otis
DO> > H. BATV-triggered bounces. Virus triggers forged bounce which in
DO> > turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth
DO> > growth of the '90s will continue. ;-)
DO>
DO> BATV should not trigger any
DO> Date: Wed, 7 Dec 2005 14:15:00 -0800
DO> From: Douglas Otis
DO> > Perhaps DSNs should be sent to the original recipient, not the purported
DO> > sender. RFC-compliant? No. Ridiculous? Less so than pestering a
DO> > random third party. Let the intended recipient communicate OOB or
DO> > m
DO> Date: Tue, 6 Dec 2005 16:26:16 -0800
DO> From: Douglas Otis
DO> I know of no cases where a malware related DSN would be generated by our
Good.
DO> products, nevertheless, DSNs are not Unsolicited Bulk Email.
Huh? I get NDRs for mail that "I" sent. I do not want those NDRs. I
did not r
SMB> Date: Sun, 04 Dec 2005 23:04:52 -0500
SMB> From: Steven M. Bellovin
SMB> A-V companies are in the business of analyzing viruses. They should
SMB> *know* how a particular virus behaves.
The cynical would say they _do_ know, and "accidental" backscatter is a
way to advertise their products
CO> Date: Mon, 28 Nov 2005 14:57:58 -0600 (CST)
CO> From: Chris Owen
CO> However, I do think Akamai would be better off getting their issues with
CO> their replacement boxes straightened out. I agree that we get value for
CO> having the boxes on our network (and so do they lets not forget).
*sh
RB> Date: Fri, 11 Nov 2005 11:03:44 -0600 (CST)
RB> From: Robert Bonomi
RB> "Upgrades" or 'fixes' that cause a machine to run noticably _slower_ than
RB> the 'down-rev' machine are a really good way to alienate customers.
Especially
RB> thosw whose machines are running at nearly 100% capacity b
RB> Date: Mon, 7 Nov 2005 14:43:54 -0600 (CST)
RB> From: Robert Bonomi
RB> Re-coding to eliminate all 'possible' buffer overflow situations is a *big*
RB> job. The required field-length checking for every multi-byte copy/move
RB> operation does have a significant negative impact on performance,
TV> Date: Wed, 19 Oct 2005 12:20:25 -0400 (EDT)
TV> From: Todd Vierling
TV> That's why SLAs exist.
I thought SLAs existed to comfort nontechnical people into signing
contracts, then denying credits via careful weasel words when the time
comes for the customer to collect. Or maybe I'm just cyn
LD> Date: Sat, 17 Sep 2005 16:18:28 +1000
LD> From: Lincoln Dale
LD> [without having looked at Imagestream in any way, shape or form..]
LD>
LD> it would be _unlikely_ that any router vendor that wants to support >OC3
LD> could do so with the 'standard' (non-modified) linux IP stack. if they ar
Date: Sat, 17 Sep 2005 19:11:14 +0200 (CEST)
From: [EMAIL PROTECTED]
A collegue smartbits tested a 1GHz pc, with a full feed and 250k
simoultaneons flows it managed around 250kpps. This also with freebsd
and device polling. It sounds to me like a software based machine can
be plenty fast with
RB> Date: Tue, 21 Jun 2005 14:40:47 +0100
RB> From: Randy Bush
[ trimming CC list ]
RB> considering that we have fellow isps dumping horrifying garbage in
RB> the rib, it's amusing how we attack a seemingly well-run very small
RB> experiment.
Bears would rather attack fish than wolverines.
Co
w> Date: Mon, 13 Jun 2005 10:39:54 -0700 (PDT)
w> From: "william(at)elan.net"
w> http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/
See also:
.zz.countries.nerd.dk
IN A lookups return 127.0.x.x, where x.x is a two-octet representation
of the ISO 3166 numeric country
TF> Date: Wed, 4 May 2005 10:48:56 +0100
TF> From: Tony Finch
TF> Why would anyone use an anycast address as a client? Wouldn't it be
TF> simpler to make all client connections from the machine's unicast address?
Maybe, maybe not.
Take an anycast DNS provider that AXFR/IXFRs zones from its cust
PWG> Date: Tue, 3 May 2005 23:56:48 -0400
PWG> From: Patrick W. Gilmore
PWG> I was just talking about people setting up anycast name servers, each
PWG> of which pointed at a different HTTP server (or other service), to
PWG> spread load. In many cases, the two servers are the same.
Ah, okay... w
TV> Date: Tue, 3 May 2005 22:21:45 -0400 (Eastern Daylight Time)
TV> From: Todd Vierling
[ trimming CC list before it grows too long ]
TV> And last time I checked -- on this list, mind you -- it certainly
TV> was not. Cf. people trying to run and hide, or lash out at me for
TV> complaining, wh
1 - 100 of 206 matches
Mail list logo
