Re: A Zero Spam Mail System [Feedback Request]
On 2/20/2019 12:22 PM, Matthew Black wrote: SIGH. I am far more inclined to listen to John Levine or Suresh Ramasubramanian, both who have been around for decades and have earned their chops with DMARC and Sendmail. Both with a proven track record, rather than someone lacking credentials. Since spam is a subjective term, I’d personally like to know how someone can design a solution that works for billions of people. Listen to them, by all means, but I'll suggest something simpler: This is already a long thread and has been both unproductive and unpleasant. Most folk who experience such a pattern in a mailing list do not ever see it change until the actors or the topic changes, and usually it takes both... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
RDAP adoption?
Not sure whether this is a permitted query for the list... I'm trying to discover the field maturity of RDAP. How much deployment of servers supporting it is there, but also how much querying from clients is happening? Any sense of the adoption/use trends? Thanks (and maybe apologies.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Residential VSAT experiences?
On 6/22/2015 6:01 PM, Lyndon Nerenberg wrote: SSH client/server authors would do well to learn the lessons of telnet line mode. Too bad the RCTE Telnet option never got popular... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Searching for a quote
On 3/12/2015 5:24 PM, Tom Paseka wrote: Be conservative in what you send, be liberal in what you accept ^http://en.wikipedia.org/wiki/Robustness_principle As with all terse summaries, the meaning of this is easy to distort. In the unfortunately not-so-uncommon extreme, it is used to argue for demanding acceptance of all manner of random cruft, essentially translating into the protocol requires you to support anything I send you. This, of course, is not what Jon meant. Rather, he noted the fact that protocol specifications invariably contain some ambiguities which, equally invariably, get interpreted differently by different, reasonable implementers. Hence the stricture to meant to guide the sending of what an implementer should consider to be the most conservative interpretations, and accept the most liberal (different) interpretations. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Multi-homing with multiple ASNs
On 11/23/2014 11:20 AM, joel jaeggli wrote: Their grasp of load-balancing seems a bit shallow also. Are there discussion/guidance papers that one can point to, to improve the depth of understanding, or at least get better configuration choices? (Those are independent points of improvement...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: .sj/.bv == privacy?
for the purpose of a specialty domain registry where registrants (such as hosting companies) would be contractually required to guarantee privacy to their end customers. Hmmm... Until privacy is a feature across many/most hosting services, anyone specializing it is, in effect, identifying traffic that is likely to be /more/ interesting for those wishing to inspect the data. In other words, anything that explicitly identifies traffic as attempting greater privacy is likely to be a greater target for attack. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Verizon Public Policy on Netflix
On 7/12/2014 3:19 PM, Barry Shein wrote: On July 12, 2014 at 12:08 ra...@psg.com (Randy Bush) wrote: or are you equating shell access with isp? that would be novel. unix shell != internet. You mean when you sat at a unix shell using a dumb terminal on a machine attached to the internet in, say, 1986 you didn't think you were on the internet? An question with more nuance than most folk tend to realize: To Be On the Internet March, 1995 http://tools.ietf.org/html/rfc1775 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Verizon Public Policy on Netflix
On 7/14/2014 9:09 AM, David Farber wrote: Three years On Jul 12, 2014, at 9:28 PM, Dave Crocker d...@dcrocker.net wrote: ... Also, although CSNet started with NSF money, it was required to become self-funded within 5 years. Hmmm... I believe the point of confusion is the difference between the initial contract, versus the strategic requirement to become self-funded: http://en.wikipedia.org/wiki/CSNET CSNET was funded by the National Science Foundation for an initial three-year period from 1981 to 1984. and A stipulation for the award of the contract was that the network needed to become self-sufficient by 1986. The wikipedia article confirms this distinction by citing the NSF itself: http://www.nsf.gov/about/history/nsf0050/internet/modest.htm By 1986, the network was to be self-supporting. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Verizon Public Policy on Netflix
On 7/14/2014 8:31 AM, Jay Ashworth wrote: Oh, *sure* Dave; write your own RFC just so you can refer to it in an argument, 19 years later... Well, after all, one does need to /earn/ the title of visionary... However, you've provided nice closure to some childhood trauma: I've no math skills, while my brother who is 5 years my senior has an excess of them. When I was quite young -- maybe 4? -- he taught me to participate in a parlor trick where I would demonstrate astonishing arithmetic skills. He would feed me a series of numbers and operations (4 + 3 * 2 - 2 +...) and I'd say the final answer and it was always correct. The gimmick was that by pre-arrangement he said he would say the final answer early on, in a particular place in the sequence, and then he'd make the computation wander around until it came back to that number. Friends and family were amazed. Except our mother, who knew I wasn't that bright. I guess now you've discerned that she was wrong. On 7/14/2014 9:52 AM, Barry Shein wrote: How about Vicarious Access: No physical connection but people keep coming into your office to tell about some dopey thing they just read or saw on the internet. Might be time to revise the RFC... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Verizon Public Policy on Netflix
On 7/12/2014 3:43 PM, Barry Shein wrote: I don't recall whether CSnet had any commercial members. Apple was a CSNET 56k customer. As I recall, Schlumberger (http://www.slb.com/, a research site of theirs on the west coast) was one of the earliest CSNet member. So was HP. I put Schlumberger online circa 1981 or 1982. I believe they were among the first 5-10 sites I brought up. At that stage, it was only email relaying, of course. Packet services were later. Also, although CSNet started with NSF money, it was required to become self-funded within 5 years. Albeit on a non-profit financial model, I'd claim that that made it, essentially, a commercial access service. If one allows 'commercial' ISP to cover independent operations that happened not to have a profit-oriented motive, I suspect the first service to quality would be The Little Garden, operated as a direct consortium, rather than having third-party operations, as CSNet did. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Anternet
On 4/4/2014 11:32 PM, Andrew D Kirch wrote: So, if there's more than 4 billion ants... what are they going to do? get larger ants. (and the responses have now covered both pro forma responses.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Yahoo DMARC breakage
On 4/9/2014 8:00 PM, Andrew Sullivan wrote: On Wed, Apr 09, 2014 at 12:27:55PM -0500, Dave Crocker wrote: But it's the result of an informed corporate choice rather than software or operations error. Why do you think (it seems to me you've said it more than once) that this was informed choice? Sorry for not responding when you posted this; I missed it. The answer is that Yahoo was an active participant in the creation of DMARC and the applicability and limitations of the design were well and fully discussed. Many times. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: responding to DMARC breakage
On 4/12/2014 2:38 PM, Jim Popovitch wrote: On Sat, Apr 12, 2014 at 1:12 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: someone needs to get a legal opinion wrt the DMARC group's effort to have all mailinglists change their From: address. The DMARC group (presumably referring to the dmarc.org informal consortium that created DMARC) is conducting no such effort. The action taken this past week was an independent effort by Yahoo. dmarc.org had nothing to do with it. The DMARC specification is quite clear about the limitations of its use. Nothing is aided by the confusing the very basic different between a specification and the choices actors make in applying it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Yahoo DMARC breakage
On 4/9/2014 11:54 PM, Jimmy Hess wrote: Basic functionality is seriously and utterly broken --- that DMARC doesn't have a good answer for such situations, is a major indicator of its immaturity, in the sense that it is Too specific a solution and cannot apply to e-mail in general. If it were mature: a mechanism would be provided that would allow mailing lists to function without breaking changes such as substituting From:. On 4/9/2014 11:54 PM, Jimmy Hess wrote: Basic functionality is seriously and utterly broken --- that DMARC doesn't have a good answer for such situations, is a major indicator of its immaturity, in the sense that it is Too specific a solution and cannot apply to e-mail in general. If it were mature: a mechanism would be provided that would allow mailing lists to function without breaking changes such as substituting From:. Every tool has limitations. An 18-wheeler truck is not broken or immature because it fails to corner like a Maserati. A Maserati is not broken or immature because it does not have the carrying capacity of an 18-wheeler. DMARC was designed to handle a particular usage scenario and its limitations have been carefully documented. Or perhaps we need to declare email broken and immature because it does not (yet) satisfy a long list of entirely reasonable functional requirements, such as, ummm, author authentication? Long deployment and use and deep knowledge don't matter; only satisfying someone's list of requirements does? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Yahoo DMARC breakage
On 4/10/2014 5:05 AM, Tei wrote: Your post advocates a (*) technical ( ) legislative ( ) market-based ( ) vigilante Since the nanog list isn't devoted to anti-spam work, folk might not know that you were calling upon the stellar web page developed by Cory Doctorow: http://craphound.com/spamsolutions.txt As far as I know, he meant it strictly for humor. However he did such a good job, it is common to point folk to it (or, as we've seen here, even fill it out) when the they declare that they have the FUSSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Yahoo DMARC breakage
On 4/10/2014 5:13 AM, Miles Fidelman wrote: If I point a gun at you, and pull the trigger, but maybe shouldn't have done that, the gun is not broken. It occurs to me that, if you point a gun at me, aim at me, pull the trigger, and hit someone standing 10 feet to my left - the gun IS broken (or at least very poorly designed). Unfortunately, that has no relationship to do with the current situation. Again: Yahoo was fully aware of the implications of its choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Yahoo DMARC breakage
On 4/9/2014 10:13 AM, Royce Williams wrote: Am I interpreting this correctly -- that Yahoo's implementation of DMARC is broken, such that anyone using a Yahoo address to participate in a mailing list is dead in the water? Their implementation is not 'broken'. Rather, Yahoo has made a very conscious policy decision. So the such that clause of your sentence is correct. That is, the effect really is what you describe. But it's the result of an informed corporate choice rather than software or operations error. From background exchanges and Yahoo participation in the development of DMARC, I believe they fully understood the technical and operations effects of the decision. Whether it is the 'right' choice is primarily a political debate, and I'm not commenting on that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Yahoo DMARC breakage
On 4/9/2014 3:05 PM, John Levine wrote: In article 5345831b.4030...@dcrocker.net you write: Their implementation is not 'broken'. I'd say it's pretty badly broken if Yahoo intends for their web mail to continue to be a general purpose mail system for consumers. If they want to make it something else, that's certainly their right, but it would have been nice if they'd given us some advance warning so we could take the yahoo.com addresses off our lists. If I point a gun at you, and pull the trigger, but maybe shouldn't have done that, the gun is not broken. Management decisions that are subject to criticism does not represent erroneous performance by the folks tasked with doing the task mandated. Everything they are doing is legal. Your (possibly entirely valid) assessment that their action is ill-advised or unpleasant does not equal broken. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: autoresponding to Yahoo DMARC breakage
On 4/9/2014 5:45 PM, George Michaelson wrote: procmail is a rewrite of MMDF mailfilter. badly. Thanks, but I believe it slightly preceded MMDF's equivalent facility. On the average, Allman put comparable features into sendmail sooner than I did. Of course, my design's were sooo much better than his, but that seems to have hurt it's adoption... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Yahoo DMARC breakage
On 4/9/2014 7:25 PM, Miles Fidelman wrote: Dave Crocker wrote: Everything they are doing is legal. Your (possibly entirely valid) assessment that their action is ill-advised or unpleasant does not equal broken. Well, sort of - given that DMARC is still an Internet draft, not even an experimental standard. Maybe it's doing what the draft says it is - but it's an alpha-level protocol, that breaks a lot of things it touches. If not broken it's certainly not ready for prime time - and large scale deployment is akin to a DDoS attack - i.e., not ill-advised but verging on criminal. While IETF full standards status does indicate real deployment and serious technical maturity, IETF Proposed Standard does not mean mature or immature, given the varied history of work leading to Proposed. SSL was quite mature, before the IETF did enhancements to produce TLS. The IETF's version of DKIM was essentially v4 for the technology. DMARC is estimated to currently cover roughly 60% of the world's email traffic. As not ready for prime time goes, that's quite a lot of prime time. Yahoo! is choosing to apply the technology for usage scenarios that have long been known to be problematic. Again, they've made an informed choice. Whether it's justified and whether it was the right choice is more of a political or management discussion than a technical one. In technical terms, DMARC is reasonably simple and reasonably well understood and extensively deployed. For most discussions, that qualifies as 'mature'... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IPv6 isn't SMTP
On 3/27/2014 6:51 AM, Blake Hudson wrote: The primary issues I see with SMTP as a protocol related to the lack of authentication and authorization. Take, for instance, the fact that the SMTP protocol requires a mail from: and rcpt to: address (more or less for authentication and authorization purposes), Actually, for neither. Mail from was mislabeled; it merely provides an address to send return notices to, which is why it makes sense to permit it to be different from the rfc5322.From value. And, of course, rcpt to specifies a recipient address. auth/auth functions were tacked on much, much later, which is why their utility is so constrained. (20 years?) but then in the message allows the sender to specify a completely different set of sender and recipient information that gets displayed in the mail client. Yeah. Almost like it is approximating the difference between what is on the outside of a postal envelope versus what is on the letterhead and opening of a piece of paper mail, which also permit such independence... The essential problem with seeing these as 'problems' is confusing 'common' with 'required'. Common scenarios are fine, but so are the variants. The variants often blow apart the simplifying assumption that one can incorrectly believe from the common scenarios. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IPv6 isn't SMTP
On 3/25/2014 10:41 PM, Jimmy Hess wrote: (1) Architectural layers are a protocol design construction, only, which assist with standardization. They are not a separation of responsibilities. Actually, they are specifically a separation of responsibilities. That the separation doesn't work adequately and all the time means that pragmatics requires wandering across layer boundaries. But pragmatics also dictate being extremely careful when choosing to do that. A SMTP server has to take care to have an implementation of all layers. There are two possible meanings to that sentence. The first prompts a 'duh' reaction, since SMTP (usually) runs over TCP/IP. So the server won't be very useful unless it 'has' an implementation of all layers. The other interpretation is that an SMTP package needs to have its own version of TCP and IP. This, of course, is silliness. SMTP packages do not typically implement TCP or IP. They might pay quite a lot of attention to those lower layers, but they don't implement them. (2) The IP protocol layer is not actually independent. Moving to IPv6 does in fact have effective new requirements for SMTP servers. Mostly, no. Not completely no, of course, but mostly. Language like #2 is leading quite a few folk to try to treat email over IPv6 as if it will be a separate service from the one currently running over v4. It won't be a separate service. Or, at least, it has better not be. The success of email has been through seamless, end-to-end integration, not through disparate silos with different service models. By way of example, please highlight which email packages require or even allow an author to dictate which version of IP to send over. For anything that someone thinks should be done for v6, pursue it instead as a change for the entire global service. It's fine for v6-related issues to /motivate/ global changes, but don't isolate the work to v6 platforms. (4) When a major change will [by necessity] be made to any layer underlying the MTA application on the protocol stack, now is also a good time to look at the overall service as a whole. Sure, but not 'also'. Rather 'only', except for relatively trivial layer convergence gluing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IPv6 isn't SMTP
On 3/26/2014 11:22 AM, Barry Shein wrote: What makes IP address mobility possible is mass, unauthorized if not simply illegal use of others' resources, such as with botnets or massive exploiting of holes in web hosting sites' software. Except that compromised personal computers are 'valid' by all normal metrics. An army of such machines provides a kind of address mobility that is not detected by any normal means. Fundamentally spam is a security isse. In the same way as burglary is a security issue, yeah. Which is to say that fundamentally, spam is a social issue, like any other crime. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/8/2013 9:48 PM, Jay Ashworth wrote: Very specifically: A 3270 that took 5 seconds of delay and then *snapped* the entire screen up at once was perceived as faster than a 9600 tty that painted the same entire screen in about a second and a half or so. Don't remember who it was either, but likely Bell Labs. Interesting, but it doesn't feel like the one I'm vaguely remembering. (How's that for waffling?) But then, when interactive computing started getting real, by the late 60s and early 70s, a number of places started studying human-computer interaction issues. IBM and Bell Labs were the two places best positioned with researchers for this. Anyhow, my main point was that economic charging models that are entirely rational, with respect to consumption and cost, don't always work for user preference. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/8/2013 7:55 PM, Phil Karn wrote: It costs you nothing to let people use capacity that would otherwise go to waste, and it increases the perceived value of your service. Sometimes, yes. Othertimes, perhaps not. I seem to recall an early bit of research on interactive computing (maybe by Sackman) that showed user preference for a /worse/ average response time that was more predictable (narrower range of variance) than a better average time that was more erratic. So, stability over throughput, sort of. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Email Server and DNS
On 11/3/2013 8:11 PM, John Levine wrote: I would recommend you go a step further and use DKIM, ADSP, and DMARC. Using DKIM is a good idea. Do *not* use ADSP. It is a failed experiment which will provide no benefit and considerable pain. +1 If you believe that your domain is heavily forged (which if you are not Paypal, Facebook, or a large bank or ISP, it almost certainly is not), you can set up a DMARC record to collect some statistics about what mail other people are getting that appears to be from you. Do not try to use DMARC to tell people to quarantine or reject your mail until you are really sure you understand the statistics you're getting. +1 The 'reporting' function in DMARC appears to have wide applicability and substantial benefit. The handling (rejection, etc.) function has very narrow benefit. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Reverse DNS RFCs and Recommendations
On 10/30/2013 9:55 AM, Andrew Sullivan wrote: As I think I've said before on this list, when we tried to get consensus on that claim in the DNSOP WG at the IETF, we couldn't. Indeed, we couldn't even get consensus on the much more bland statement, Some people rely on the reverse, and you might want to take that into consideration when running your services. Now, IETF non-consensus on the way the Internet works is hardly a surprise, but I thought I'd point this out just in case people want to be prepared for flames from people who feel strongly about the matter. I'm beginning to think that documenting failures to get consensus could be almost as important as documenting successes, in order to provide a basis for countering folks who claim something is required, when there's explicit public experience that it isn't. Looks to me that Andrew's note is an example of that potential benefit. Rather than having to have someone remember this stuff, anyone could point to the 'failure' document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty
On 9/7/2013 5:33 PM, Harald Koch wrote: On 7 September 2013 17:08, Paul Ferguson fergdawgs...@mykolab.com wrote: Preliminary analysis of more than 25,000 traceroutes reveals a phenomenon we call ‘boomerang routing’ whereby Canadian-to-Canadian internet transmissions are routinely routed through the United States. I sincerely hope that nobody in Canada is surprised by this, since it was already an issue in 1994 (when I was at CA*net). Much farther back than that. In 1985 I was working in Toronto and did a proposal for a national X.25 network. The pragmatics for reliability were simple at a national scale: Essentially all Canadian telecom links went through a few common sites across the country; if you wanted redundancy you had to have a second, independent path through the US. Given that most Canadian population occupies a relatively thin band (close to the US border), this topological fragility was/is largely inherent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: What do people use public suffix for?
On 4/19/2013 12:57 PM, Tony Finch wrote: To reinforce Joe's point, there doesn't even need to be a zone cut for there to be an administrative cut. There are various ISPs and dynamic DNS providers that put all their users in the same zone, and the common suffix of a zone like this should be treated as public suffix even though there is no zone cut. Zones are nice constructs for partitioning operational management of DNS data, but I believe they were not intended to impart semantics about organizational boundaries. The fact that they often correlate moderately well makes it easy to miss the facts that a) that's not their job, and b) the correlation isn't perfect. And the imperfections matter. That is why there is the current interest in developing a cheap, accurate method that /is/ intended to define organizational boundaries. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: What do people use public suffix for?
On 4/19/2013 4:33 PM, Jimmy Hess wrote: It seems this is more about providing a security function to DNS, to inform the public, about where the responsible parties change. Absent a view that somehow says all metadata is a security function, I don't see how the marking of administrative boundaries qualifies as a security function. It's easy to imagine security functions that are 'in support of' the enforcement of the boundaries, but that's quite different from having an annotation mechanism to assert the boundaries. Let's be careful not to overload functions here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: What do people use public suffix for?
1. Explicitly marking an administrative boundary is not inherently a 'security' function, although properly authorizing and protecting the marking no doubt would be. 2. Defining a marking mechanism that is built into a security mechanism that is designed for other purposes is overloading functionality, as well as setting up a problematic critical dependency. That's not just asking for trouble, it's guaranteeing it. 3. Since you made reference to assumptions a couple of times: the goal here is an explicit marking mechanisms. No assumptions involved. d/ On 4/19/2013 7:58 PM, Jimmy Hess wrote: On 4/19/13, Dave Crocker d...@dcrocker.net wrote: On 4/19/2013 4:33 PM, Jimmy Hess wrote: [snip] Absent a view that somehow says all metadata is a security function, I don't see how the marking of administrative boundaries qualifies as a security function. The security function comes in immediately, when you consider any actual uses for said kind of metadata. The issues are alleviated only by assuming that an administrative division always exists, unless you can show otherwise, and showing that the records are in the same zone is one way of showing otherwise. When you come to rely on it, there are new security issues. It becomes such that; It is perfectly safe to assume that there is an administrative division when there is not -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Muni network ownership and the Fourth
On 1/29/2013 7:59 AM, Jay Ashworth wrote: - Original Message - From: Rob McEwen r...@invaluement.com (C) The fact that the Internet is a series of PRIVATE networks... NOT owned/operated by the Feds... is a large reason why the 4th amendment provides such protections... it becomes somewhat of a firewall of protection against Federal gov't trampling of civil liberties... but if they own the network, then that opens up many doors for them. Regular readers know that I'm really big on municipally owned fiber networks (at layer 1 or 2)... but I'm also a big constitutionalist (on the first, second, fourth, and fifth, particularly), and this is the first really good counter-argument I've seen, and it honestly hadn't occurred to me. Rob, anyone, does anyone know if any 4th amendment case law exists on muni- owned networks? The challenge, here, is a classic 'natural monopoly' concern/argument. I don't know the right answer, here, but I think the frame for discussing it has a long history. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: De-funding the ITU
On 1/12/2013 11:07 PM, Bill Woodcock wrote: On Jan 12, 2013, at 8:17 PM, John Levine jo...@iecc.com wrote: The political fallout from the US being seen as a big rich bully taking its wallet and going home is likely not worth the trivial amount of money involved. Relative to the $2M/year IETF budget? Purely for accuracy: Current IETF expenditures are around US$ 5M - 5.5M. The ISOC Direct Contribution Excluding Development is just over US$ 2M: http://iaoc.ietf.org/documents/YEF-2012-2015.pdf d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: De-funding the ITU
On 1/12/2013 9:04 PM, Fred Baker (fred) wrote: ITU-D and ITU-R do a lot of good work. -R is excluded from the petition. (From a number of postings, it appears that many folk haven't noticed that.) I don't know anything about -D. In the interest of adding some core information to the thread, could you provide a brief summary of its job and benefits (with any concerns that are broadly held)? I'm not asking you to defend your views but to provide a most basic tutorial on -D. The more objective the better. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Legal Crap [was: William was raided for running a Tor exit node. Please help if you can.]
On 12/1/2012 11:01 AM, Jimmy Hess wrote: Anyone, including people off the street, can have opinions about the Law, and opinions about networks. Would you be willing to rely some stranger off the street, with no qualifications, or positive background whatsoever, to start recommending a new network design, quite possibly. strangers off the street sometimes demonstrate superior insight than credentialed 'experts'. not typically, of course, but sometimes. an essential point is how much work i want to do to assess the credibility of the comments from either source. folks who rely on their credentials for credibility tend to lose it with me. anyone who makes a point by clearly providing a solid basis for it tends to gain it. but i agree that clarity about the purpose of this thread would be helpful... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IPv4 address length technical design
Is anyone aware of any historical documentation relating to the choice of 32 bits for an IPv4 address? ... Actually that was preceded by RFC 760, which in turn was a derivative of IEN 123. I believe the answer to the original question is ... My theory is that there is a meta-rule to make new address spaces have 4 times as many bits as the previous generation. We have three data points to establish this for the Internet, and that's the minimum needed to run a correlation: Arpanet, IPv4, IPv6... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Anonymous planning a root-servers party
On 2/15/2012 2:40 PM, Grant Ridder wrote: I really don't think Anonymous is dumb enough to forget about anycast. Given their track record, it does seem advisable to take the threat seriously, whatever taking it seriously might mean... If i remember right, another group tried to take down the root servers within the past 5 or 6 years and only took out around 20 or 25. Some discussions about that I recall guessed that it was an experimental probe, for learning how to do a better attack. (Remember that 9/11 was a revision of a prior attack on the towers.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Whacky Weekend: Is Internet Access a Human Right?
On 1/5/2012 7:36 AM, Marshall Eubanks wrote: On Thu, Jan 5, 2012 at 10:22 AM, Jay Ashworthj...@baylink.com wrote: Vint Cerf says no: http://j.mp/wwL9Ip With all due respect to Vint, I think that it isn't now, but it will be. With all due respect for the view that it will be, I'll suggest that this entirely misses the point of his op-ed. His point is to distinguish means versus ends and that something as basic as a human right needs to be about ends, not means. Means often change -- sometimes quickly -- but ends are typically quite stable. Discussion about means needs to be in terms of the ends they serve. From the US perspective, speech and assembly are examples of rights. The 'right' to telephone service is not a direct right; it's a derivative of the speech right, I believe. Onerous assembly laws are examples of unacceptable means. The Internet is a set of means. (Zaid's concrete example about blog blocking is also on point.) Broadly, we need to be careful to distinguish between core issues (rights, causes, and the like) from derivative and surface issues (means, symptoms, and the like. It's extremely easy to get caught up with the details of means and symptoms and entirely miss the underlying, strategic issues. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Outgoing SMTP Servers
Bill, Your misunderstanding of physical pollution pollutes your understanding of spam. But it turns out that you seem to misunderstand spam quite a bit, independently. On 10/27/2011 9:26 PM, William Herrin wrote: If you throw pollution into the air, it may eventually impact me or it may blow somewhere else. Mostly it'll blow somewhere else. But as lots of people throw pollution into the air, some non-trivial portion of that pollution will drift over me. This is the so-called tragedy. They used to be able to tell how recently someone moved to in Los Angeles by how corrupted their lungs were, from the /local/ pollution. Maybe it's still possible. Pollution tends to increase the occurrence of some diseases, thereby significantly increasing societal health costs. So the casual view of pollution going somewhere else is simply wrong. Still you do seem to understand that it affects some mass of folk. By contrast, if you send me spam email, you are directly abusing my computer. The linkage is not at all amorphous. You send to me. I receive from you. There is no all world or local area destination. If you send without some specific pointer in my direction, I won't receive it. Ever. Imagining spam as a tragedy of the commons disguises its true nature as a massive quantity of one-on-one abuses of individual owners' computers. Worse, it forgives the owners of the intermediate networks for shrugging their shoulders and turning a blind eye to the abusers. Email travels over shared resources. Spam consumes roughly %95 percent of that shared path (comm lines and servers). Receiving operators must devote masses of resources to filter that firehose of mostly junk, in order to get everyone's mailboxes to remain at least somewhat useful. Since the spammers are well-organized and aggressive and often quite bright, they adapt their attacks to get round these filters, thereby creating an extremely unstable arms race. This means the entire situation is extremely unstable. When -- not if -- it breaks, mail becomes unusable. That will be a common suffering. The one-to-one cost or damage is probably also a reasonable perspective, but it's /incremental/ to the shared cost. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Outgoing SMTP Servers
On 10/30/2011 8:36 PM, Brian Johnson wrote: So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct? If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection? As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Outgoing SMTP Servers
On 10/28/2011 5:44 AM, William Herrin wrote: A commons is jointly owned, either by a non-trivial number of private owners or by all citizens of a government. The practical use of the term is a bit broader: http://en.wikipedia.org/wiki/Commons As rule, the term gets applied to situations of fate-sharing when actions by some affect utility for many. You cited air pollution. The Internet can suffer comparable effects. Spam can reasonably be called pollution and it has a systemic effect on all users. For such an issue, it's reasonable and even helpful to view it as a commons. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Outgoing SMTP Servers
On 10/25/2011 8:13 AM, William Herrin wrote: Blocking outbound TCP SYN packets on port 25 from non-servers is considered a BEST PRACTICE ... The SMTP submission port (TCP 587) is authenticated and should generally not be blocked. Email Submission Operations: Access and Accountability Requirements http://www.ietf.org/rfc/rfc5068.txt IETF BCP It does not explicitly support blocking outbound port 25, since that's controversial, but it /does/ require permitting outbound port 587. d/ Regards, Bill Herrin -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: How long is your rack?
On 8/15/2011 8:37 AM, Randy Bush wrote: i have no assurance that a shortened url does not lead to a malicious site. From a practical standpoint, a long URL provides no greater assurance. you really have no idea what you're going to receive when you click on any link. life is nasty. but one still avoids bad neighborhoods. Which incorrectly presumes that the average user can distinguish among Internet neighborhoods. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Yup; the Internet is screwed up.
On 6/10/2011 7:04 AM, Scott Brim wrote: The Internet is now more important than electricity or water -- This being a silly Sunday, I'm rolling that around on my tongue and savoring it a bit. While the image of a desiccated user, still typing away, is appealing -- but possibly not all that remarkable, given recent reports of Internet addiction -- what's especially tasty is the idea of having an Internet connection that works without electricity... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: gmail dropping mesages
On 4/22/2011 4:24 PM, Lynda wrote: Nearly all of the spam I see is DKIM signed. It just makes messages bigger. I'd just as soon our volunteers spend their times on other things, myself. In the off-chance you are assuming that the presence of a DKIM signature is supposed to mean something about the quality of a message, please note that it isn't. It is only meant to supply a reliable, valid identifier, with which assessments can then be made. That assessment step is where the fun happens. See: http://dkim.org/specs/draft-ietf-dkim-deployment-11.html For reference, spammers are typically early adopters of newly security standardized mechanisms, in the (demonstrably valid) belief that some folk confuse identification with quality assurance. In particular, the DKIM d= identifier is primarily helpful for avoiding false positives. That is, it is for an assessment process targeting signers you trust, rather more than for targeting those you don't. If you don't care about the trust side of the filtering equation, I suspect DKIM will not be all that helpful for you. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: 365x24x7
On 4/17/2011 8:19 AM, Jay Ashworth wrote: - Original Message - From: Dave CROCKERd...@dcrocker.net There were 3-5 of us covering things for that added time. But, then, the major operations were purely daytime, during the week. Graveyard shift was quiet enough that we surreptitiously bought a cot... You didn't work for the FAA, Dave, did you? No, or we would have gotten more sleep. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: 365x24x7
On 4/15/2011 6:14 AM, harbor235 wrote: If I were going to provide a 365x24x7 NOC, how many teams of personnel do I need to fully cover operations? I assume minimally you need 3 teams to cover the required 24 hr coverage, but there is off time and schedule rotation? What is the work distribution? Do you have stable patterns of more-vs-less activity? If things are busy daytime and quiet nighttime, obviously you need different-sized teams. Variable scheduling of staff is often deemed more fair, but I think it makes things less stable. People are constantly having to change their life. A simple model has 3 teams over weekdays/nights, leaving you with weekends, holidays and vacations. I was a part-time operator during college. Full-timer shifts were 3 people; maybe 2 for graveyard. There were 3-5 of us covering things for that added time. But, then, the major operations were purely daytime, during the week. Graveyard shift was quiet enough that we surreptitiously bought a cot... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Paul Baran, RIP.
On 3/28/2011 5:44 AM, Dobbins, Roland wrote: http://www.networkworld.com/news/2011/032811-paul-baran-packet-switching-obit.html Katie Hafner's (Where Wizards Stay Up Late) obit on Paul is also quite good: http://www.nytimes.com/2011/03/28/technology/28baran.html?_r=1src=busln -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: quietly....
On 2/19/2011 10:11 AM, kmedc...@dessus.com wrote: And that has nothing to do with whether a protocol is a peer protocol or not. IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a peer-to-peer protocol. At each layer of an architecture, the question of whether a mechanism is peer to peer can be newly defined. Even within a layer it can be, depending upon configuration choices. IP is typically /not/ peer to peer, since getting from the originating host to the target host is typically mediated by many routers. That is the essence of /not/ being peer to peer. One layer up, we find that TCP typically /is/ peer-to-peer. SMTP as a one-hop email transmission protocol is peer-to-peer from the SMTP client to the corresponding SMTP server. However email exchange from an author's MUA to a recipient's MUA is, again, the essence of /not/ being peer to peer. It is typically massively mediated by lots of different email servers. One could configure two MUAs to talk with each other 'directly' using SMTP, but that's never done. Instant message services similarly are not peer-to-peer technical terms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: quietly....
On 2/19/2011 10:11 AM, kmedc...@dessus.com wrote: And that has nothing to do with whether a protocol is a peer protocol or not. IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a peer-to-peer protocol. At each layer of an architecture, the question of whether a mechanism is peer to peer can be newly defined. Even within a layer it can be, depending upon configuration choices. IP is typically /not/ peer to peer, since getting from the originating host to the target host is typically mediated by many routers. That is the essence of /not/ being peer to peer. One layer up, we find that TCP typically /is/ peer-to-peer. SMTP as a one-hop email transmission protocol is peer-to-peer from the SMTP client to the corresponding SMTP server. However email exchange from an author's MUA to a recipient's MUA is, again, the essence of /not/ being peer to peer. It is typically massively mediated by lots of different email servers. One could configure two MUAs to talk with each other 'directly' using SMTP, but that's never done. Instant message services similarly are not peer-to-peer technical terms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Weekend Gedankenexperiment - The Kill Switch
On 2/6/2011 10:47 AM, Barry Shein wrote: If you focus it down very sharply like this: DARPA specified (or, perhaps, the project was sold to DARPA with a promise...) that the network being designed in the late 1960s should be resistant to a nuclear attack. That's probably an urban legend, who knows, it's probably not all that interesting. But was it observed over and over from the early on that a packet network, versus the then predominant technology of virtual (or even real) circuit networks, would be resistant to damage of all sorts? Yes. Sorry, but I think the technical implications of a goal to survive 'hostile battlefield conditions' versus 'nuclear attack' are (small pun) massively different. Hence I think the actual language used matters. And the fact that the common language around the net during the '70s was the former and not the latter matters. Which is why it would be helpful to get some credible documentation about use of the latter. I'd expect the major difference in the two terms is the scale of the outage. A few square miles, versus possibly thousands. To that end, I remember an anecdote about van Jacobson from the 1989 quake in California that might provide some insight about a large-scale outage:[1] He was living in Berkeley but was visiting Stanford when the quake hit and he wanted to check that his girlfriend was safe. Of course, the phone didn't work.[2] Out of sheer frustration and the need to do /something/ he sent her an email. He got a response within a few minutes. Surprised that the net was still working (and working quite well), he did a traceroute from the Stanford system to the one his girlfriend was using.[3] Not surprisingly, the path did not cross the San Francisco Bay, as it normally would have. Instead it went down to Los Angeles, across the southern US, up the East Coast and back across the Northern U.S. Although the outage was fairly small-scale, the scale of the re-routing suggests that a larger, 'regional' outage from something like a nuclear event would adapt readily. (We can ignore the additional question of EMP effects, since that only affects the scale of the outage.) And, of course, there have been other test cases since then... d/ [1] This is anecdotal; I've never confirmed the story with him. [2] That does not automatically indicate a system failure, given the switch to an emergency mode for the phone system that restricts access during major events like these. [3] Van created traceroute. http://en.wikipedia.org/wiki/Traceroute -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Weekend Gedankenexperiment - The Kill Switch
On 2/5/2011 6:43 AM, Fred Baker wrote: On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: Not sure if it has been said already but wasn't one of the key point for the creation of the internet to create and infrastructure that would survive in the case of all out war and massive destruction. (strategic nuclear strikes) Urban legend, although widely believed. Someone probably made the observation. Maybe not quite an UL... http://www.rand.org/about/history/baran.html On the average, The Rand Corp is extremely careful about what it publishes, yet here it is, repeating the claim. Back in the '70s, I always heard survive hostile battlefield conditions and never heard anyone talk about comms survival of a nuclear event, but I wasn't in any interesting conversations, such as in front of funding agencies... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: UN mulls internet regulation options
On 12/18/2010 9:52 PM, Joseph Prasad wrote: http://www.itnews.com.au/News/242051,un-mulls-internet-regulation-options.aspx Given the season, their efforts appear to be a form of mulled whine. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Level 3 Communications Issues Statement Concerning Comcast's Actions
On 11/29/2010 2:40 PM, Rettke, Brian wrote: Essentially, the question is who has to pay for the infrastructure to support the bandwidth requirements of all of these new and booming streaming ventures. I can understand both the side taken by Comcast, and the side of the content provider, but I don't think it's as simple as the slogans spewed out regarding Net Neutrality, which has become so misused and abused as a term that I don't think it has any credulous value remaining. I find it helpful to distinguish participant neutrality from service neutrality. The first says that you and I pay the same rate. The second says the my email costs the same as my voip. As described, it appears that Level3 is being singled out, which makes for participant non-neutrality. On the other hand, if Comcast were charging itself for xfinity traffic, this might qualify as service non-neutrality (assuming there is a plausible meaning to charging itself... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IPv4 sunset date set for 2019-12-31
On 10/21/2010 1:56 PM, Barry Shein wrote: Well, if the DNS root servers ceased IPv4 service it'd be pretty much a fait accompli as far as the public internet is concerned. Given the reality of fragmenting the DNS -- including its root -- that's an action that well might backfire. Current fragmentation is constrained; this could plausibly motivate more people to pursue other paths and thereby blow things up. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: 12 years ago today...
On 10/15/2010 10:51 PM, Rodney Joffe wrote: On October 16th, we lost a real friend and hero. Sigh http://www.apps.ietf.org/rfc/rfc2468.html Quite a few of us felt compelled to remark on his life and effect on us. They've been nicely collected at postel.org: http://postel.org/remembrances/ Speak softly and carry a big registry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Real ops talking to future ops
On 8/23/2010 6:39 PM, John Kristoff wrote: A few classes ago I had a student tell me they had an instructor spend two full classes (out of 10) on Token Ring. There's a serious need to cover such a construct, but also to introduce it in the context of modern systems: Probably none of what is sold today as ethernet is actually the original ethernet protocol or even close to it. What is sold today is a the ethernet *interface* and some other protocol under it. This difference between the interface and the infrastructure under it that provides service to it is a fundamental construct that is often missed. Standardized interfaces let technology adapt underneath it. So, for example, IBM published the API for netbios, without publishing the protocol. That let some of us build alternative protocols that satisfied the API but ran over TCP. (See RFC 1001, 1002 for the standardized version.) Much of what is sold today as ethernet has a protocol under it that is contention-free. The different Token Ring schemes provide that in a distributed manner.[1] d/ [1] Though my own focus was on email, my CS prof was Dave Farber, so I had to absorb more about TR than I would have wanted. One of the interesting metricts for TR is delay-time per node. The Irvine Ring introduced one bit-time delay. Scaled great. The IBM TR introduced one full packet-time. Didn't scale well. -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Real ops talking to future ops
On 8/23/2010 3:38 PM, John Kristoff wrote: many of the other instructors they come into contact with are focusing only on class A, B, C addressing wow. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: On the control of the Internet.
On 6/13/2010 3:47 PM, valdis.kletni...@vt.edu wrote: It's always been a BCP good idea to have your DNS have secondaries in another non-fate-sharing AS, even though everybody from Microsoft on down seems to feel the need to rediscover this. Postel used to advise having them on different tectonics plates (and sources of power, of course.) Conflating the liberal in what you accept advise, it might be wise to accept tectonic as covering tectonic shifts in politics, as well as land masses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Mail Submission Protocol
On 4/21/2010 8:16 PM, Suresh Ramasubramanian wrote: The MAAWG BCPs have far more available than one of the worst maintained blacklists that has ever been in existence. For example: http://www.maawg.org/sites/maawg/files/news/MAAWG_Port25rec0511.pdf d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Mail Submission Protocol
On 4/21/2010 6:49 AM, Claudio Lapidus wrote: So we are considering ways to further filter this traffic. We are evaluating implementation of MSA through port 587. RFC 5068, Email Submission Operations: Access and Accountability Requirements, is a BCP. It specifies authenticated port 587 for email submission across the net. As others have noted, it works well through a wide variety of access environments. I don't remember the last time I found it blocked. I use it over TLS, of course. Blocking of outbound port 25 for all hosts not explicitly authorized has become common. The fact that 587 default to authenticated is the win. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Fiber Outage in Sunnyvale, CA.
Near Lawrence, between El Camino and Central, seems to be working fine to the home. d/ On 4/15/2010 2:29 PM, Shon Elliott wrote: I heard there is a fiber outage in Sunnyvale that has taken out most of the city. Can someone from ATT Provide any kind of clue on what's going on? I'm being told by one of our partners that their entire building is without service in Sunnyvale and apparently they've talked to other businesses in the area that have fiber-based services who are also down. Regards, Shon Elliott Senior Network Engineer unWired Broadband, Inc. Office: (559) 261- x 511 Cell: (559) 917-6480 -- Dave Crocker Brandenburg InternetWorking bbiw.net
getting the hint (was: Re: Please do not respond to Dean and CC the NANOG list)
On 4/15/2010 1:32 PM, Ronald Cotoni wrote: Do what I do, auto respond to his messages telling him to not email you then forward to ab...@. He will get the hint. This is a common misunderstanding of the personality type. Your recommendation is based on the assumption that you are dealing with a predominantly rational person, according to a normal sense of rational. In reality, these situations occur with someone who thrives on getting any sort of reaction at all. Much like the claim that there is no such thing as bad publicity, this sort of person enjoys any and all interaction, no matter how distasteful and dissuading a 'normal' person might find it. The only response that works -- and even this is not guaranteed -- is shunning. Drop the message. Do not respond. Ever. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Tidbits the NANOG Community
On 4/4/2010 6:46 AM, Stefan Fouant wrote: Sounds like this guy could benefit from some carpeting and a few Roombas in his Data Center ;) trolls rarely benefit from anything but being ignored. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: What is The Internet TCP/IP or UNIX-to-UNIX ?
On 4/3/2010 6:38 PM, IPv3.com wrote: What is The Internet TCP/IP or UNIX-to-UNIX ? As of 2010, many people would likely answer that question based on the Services they use as opposed to a religious adoration for TCP/IP. See: http://www.ietf.org/rfc/rfc1775.txt ...anti-v6 religious diatribe elided... mis-directed attack, in spite of having such an easy target. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Email Portability Approved by Knesset Committee
On 2/23/2010 8:44 AM, Scott Brim wrote: Simple: you separate 'mail' addresses from 'fire' addresses. Mail addresses are identifiers. Fire addresses are locators. wrong approach. simply get fire engines to have heat sensors and set their gps accordingly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Email Portability Approved by Knesset Committee
On 2/22/2010 9:29 AM, Suresh Ramasubramanian wrote: Am I missing something? All the ISP has to do is to provision a pop3 / imap / webmail mailbox for that user and keep it around. As a permanent requirement for all accounts, including changes as the user moves around -- long-term churn is 100% within relatively few years-- and to expect all domain owners who originally host a mailbox to then do this forwarding admin and ops competently, this is going to be a serious problem. The scheme is certain to be quite unreliable along multiple axes. Worse, I had not thought of Sheldon's excellent point about negative reputation blowback on the domain owner. Per the followup comments on this, the domain owner might be able to do some things in domain name usage and IP Address assignment to mitigate this, the initial and on-going costs of getting this right and the likelihood of eliminating all blowback are problematic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
artifacts (was Re: Email Portability Approved by Knesset Committee_
On 2/22/2010 9:35 AM, Larry Sheldon wrote: I have been wondering about that too--the Internet may be the only artifact of human existence that is generally border insensitive (with exceptions we don't need to enumerate). Pollution. Global warming. Nuclear fallout. ... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: artifacts (was Re: Email Portability Approved by Knesset Committee_
Hmmm. While it's easy and reasonable to call these externalities, I suspect a good case could be made that they are not, since they affect the principals, as well as everyone else... I'm confused by the reference to archaic, structured balloons... d/ ps. Creative misunderstanding is also a convenient refuge. -- dcrocker On 2/22/2010 12:24 PM, R.A. Hettinga wrote: On Feb 22, 2010, at 2:53 PM, Dave CROCKER wrote: On 2/22/2010 9:35 AM, Larry Sheldon wrote: I have been wondering about that too--the Internet may be the only artifact of human existence that is generally border insensitive (with exceptions we don't need to enumerate). Pollution. Global warming. Nuclear fallout. Externalities are the last refuge of the dirigistes. -- Friedrich Hayek -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Email Portability Approved by Knesset Committee
On 2/22/2010 8:42 PM, Larry Sheldon wrote: When Somebody calls one of my portable telephone numbers, they don't get a message telling them they have to call some other number. The get call progress tones. You are confusing what is presented to the end-user with what might be going on within the infrastructure service. Call progress tones are the former and their primary goal is to keep the user happy, providing very constrained information. Especially for mobile phones, there is often all sorts of forwarding signallying going on while you hear to tones. In general, a core problem with the Knesset law is that it presumes something that is viable for the phone infrastructure is equally - or at least tolerably - viable in the email infrastructure. Unfortunately, the details of the two are massively different in terms of architecture, service model, cost structures and operational skills. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Mitigating human error in the SP
On 2/1/2010 6:21 PM, Chadwick Sorrell wrote: Any other comments on the subject would be appreciated, we would like to come to our next meeting armed and dangerous. If upper management believes humans can be required to make no errors, ask whether they have achieved that ideal for themselves. If they say yes, start a recorder and ask them how. When they get done, ask them why they think the solution that worked for them will scale to a broader population. (Don't worry, you won't get to the point of needing the recorder.) Otherwise, as Suresh notes, the only way to eliminate human error completely is to eliminate the presence of humans in the activity. For those processes retaining human involvement, procedures and interfaces can be designed to minimize human error. Well-established design specialty. Human factors. Usability. Etc. Typically can be quite effective. Worthy using. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Arrogant RBL list maintainers
On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote: As previously noted in this thread, msulli...@sorbs did a fairly good job of documenting this in an RFC draft. I'd say its still the primary goto to point people at for how to do things the right way. http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 The time to pursue something like this in the IETF is when there is a substantial industry consensus that it is the right approach and that the folks supporting it will actually use it. Are those of you who have participated in this thread willing to conform to the model specified in this draft? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: SPF Configurations
Jeffrey Negro wrote: SPF seems to be the way we could possibly avoid more spam filters, and delivery rate is very important to our company. You've seen the anti-SPF rants. At the least, they should make clear to you that you should use SPF only and exactly for specific destinations that you already know require it. If you have any doubts about the requirement, you'll try to verify it; otherwise assume SPF won't solve your problems. The other obvious mechanisms for validated identification to receiving operators is, of course, with DKIM. DKIM is entirely comfortable having a validated identifier (the d= parameter in the signature header field) be different than whatever is in the author header field (From:) But either way, that's just identification. As already noted on the thread, what matters most is the set of content and operations practices, to establish a rock solid reputation both of you and of your clients. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: So why don't US citizens get this?
Fred Baker wrote: The key thing in that definition is the lack of government intervention in its various forms. That's D'Arcy's point. Where there is government subsidy, regulation, or other intervention, it cannot be described as a free market. I have always understood the issue to be the presence or absence of unfettered competition. Competition is good. It's lack is bad. Government can be one source of fettering. So can monopolization. So can post-purchase lock-in. Anything that restricts the ability of the consumer to make on-going choices for alternate sources of products and services. Which is to say, anything that alters the incentives of companies to provide better products at better prices. We ought to stop saying 'free' and instead say 'competitive'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
