Slashdot Mirror

I especially liked the link to "empathy is a core engineering value" though: http://www.listbox.com/member/...

Linked from: https://www.joyent.com/blog/th...

And if so, should not empathy extend throughout all levels of a learning organization, including between managers and subordinates? Everyone is learning stuff all the time, including about cultural changes. Firing someone rather than trying to understand the situation and the individual's motives more first and whether change is needed or possible does not seem "empathic". Perhaps that is the kind of thing you tend to learn after many years of experience being a parent or other long-term caregiver (including a long-term manager or mentor) when you see someone learn and grow and change over a long time?

Plus, as other comments suggest here, there is an assumption in this blog post that may ignore the possibility the issue was about consolidating minor changes rather than having them as individual commits. If this issue was deemed by enough of the community to be important, maybe a more systematic patch would indeed be in order? One tiny change is not much work, but it may set a bad precedent?

Also, it is not empathic to coworkers and the rest of a company and community depending on someone to fire that person without notice without reasonable review or attempts at remediation for a less than egregious offense (contrast with, say, someone accused of physically assaulting a coworker). The issue there is proportion and risk/harm assessment.

So, the response of "we would have fired him" seems too extreme in multiple ways.

I am all for meaningful diversity in workgroups, like discussed in this book:
"The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies"
http://www.amazon.com/The-Diff...

However, the problem with some of these "politically correct" initiatives or statements which seem on the surface to be helpful to promote "diversity" is that they can actually make workspaces more stressful for *everyone*. Someone can bully with the rules (or their interpretation) just as much, or more, than with a fist... Here is a website by psychologist Izzy Kalman that explores some issues related to bullying and truly creating happy productive workplaces by *really* emphasizing empathy and forgiveness and growth and free speech:
http://bullies2buddies.com/

Just think about it -- does everyone at Joyent now need to be afraid of getting fired if they check the word "he" into the codebase, even by accident? Or maybe by saying "he" accidentally as a meeting? There are potential unintended consequences of creating a different sort of hostile workplace climate, like many US schools are finding out these days as a result of "zero tolerance" policies (like biting a cracker at lunch to make it shaped like a gun can get you in deep deep trouble).

For reference, here is what makes for happy productive creative workplaces in general (Autonomy, Mastery, Purpose):
"RSA Animate - Drive: The surprising truth about what motivates people"
https://www.youtube.com/watch?...

Anyway, these are all complex issues about language, sex, management, control, gender roles, cultural change, recruitment, productivity, norms, and more. They are tricky to talk about or write about without seeming uncaring or inept because of various assumptions people make about the context or the people involved -- and the fact that none of us are "perfect" (and that perfection can be in the eye of the beholder based on priorities). It is sad to see such great software get mired in them. But I guess they are p

I don't think you can dismiss out of hand the possibility that this was a planned outcome.

That sounds very weaselly, in the sense that if one person anywhere had such a thought but never spoke it, your statement would be true. And it sounds like the kind of baseless nutball regurgitation we have come to expect from internet conspiracy crazies.

You should meet AC, he's informative but shy. This is probably why it was marked troll initially, since it has been going around for a while, and calling out the NSA is standard fare for a frosty piss.

Skype was moved to centralized servers so they could survive the new era of communications: mobile devices. It was impossible to do Skype on mobile devices without centralized servers because the P2P communications would eat your battery AND your data bill. I'm sure this helps with interception as well, but it wasn't he main intention. This is discussed in detail by a former Skype engineer here:

http://www.listbox.com/member/archive/247/2013/06/sort/time_rev/page/1/entry/6:271/20130623090855:0B714E0A-DC06-11E2-9F35-8CD4CCA160A2/

Your post should have consisted solely of This link followed by this link which it took me all of 3 minutes to find, so I would know whether to make fun of you or support you.

How Brazil-ian that the line between "chicken little" ignorant asshattery and fact has completely disappeared.

"Microsoft's ethical vacuity in this area is no surprise. A year and a half ago, in "Microsoft's Ballmer to China: Forget Google -- If You Want Censorship, Come to Bing!" link

"The U.S. is the most extreme when it comes to free speech .. If the Chinese government gives us proper legal notice, we’ll take that piece of information out of the Bing search engine" link

Funny enough, looking at the link you provided and following one of the embedded links for context got me this nugget:

By way of example, federal courts in Washington state and California
have ruled that the class action bans in AT&T's cell phone contracts
couldn't be enforced, because they violated Washington and California
state law. In contrast, Federal courts in Louisiana have enforced
such class action bans in a T-Mobile cell phone contract, finding that
Louisiana state law at the time allowed the ban.

here ya go

Here's an email from one of Comcast's engineers recently sent to Dave Farber's Interesting People mailing list. It clarifies the policy quite well:

From: "Livingood, Jason"
Subject: Clarifying Misconceptions of the New Comcast Congestion Mgmt Syste

Hi Dave

I wanted to try to clear up a misconception about how the new Comcast congestion management system works. I believe we have both heard people complain that they fear that they will be unable to use their provisioned speeds during off-peak hours, for example, or at all times of the day, or that users are somehow throttled to a set speed. Neither of these two things are correct. Part of the problem appears to be confusion over how a user's traffic enters a lower priority QoS state, so I hope to clarify that here

In order for any traffic to be placed in a lower priority state, there must first be relatively high utilization on a given CMTS port. A CMTS port is an upstream or downstream link, or interface, on the CMTS in our network. The CMTS is basically an access network router, with HFC interfaces on the subscriber side, and GigE interfaces on the WAN/Internet side. Today, on average, about 275 cable modems share the same downstream port, and about 100 cable modems share the same upstream port (see page 5 of Attachment B of our Future Practices filing with the FCC, available at http://downloads.comcast.net/docs/Attachment_B_Future_Practices.pdf). We define a utilization threshold for downstream and upstream separately. For downstream traffic, a port must average over 80% utilization for 15 minutes or more. For upstream traffic, a port must average over 70% utilization for 15 minutes or more

When one of these threshold conditions has been met, we consider that individual port (not all ports on the CMTS) to be in a so-called Near Congestion State. This simply means that the pattern of usage is predictive of that network port approaching a point of high utilization, where congestion could soon occur. Then, and only then, do we search the most recent 15 minutes of user traffic on that specific port, in order to determine if a user has consumed more that 70% of their provisioned speed for greater than 15 minutes. By provisioned speed, we mean the "up to" or "burst to" speed of their service tier. This is typically something like (1) 8Mbps downstream / 2Mbps upstream or (2) 6Mbps downstream / 1Mbps upstream

So how does this work in action? Let's say that a downstream port has been at 85% utilization for more than 15 minutes. That specific downstream port is identified as being in a Near Congestion State since it exceeded an average of 80% over that time. We then look at the downstream usage of the ~275 cable modems using that downstream port. That port has a mix of users that have been provisioned either 8Mbps or 6Mbps, so 70% of their provisioned speed would be either 5.6Mbps or 4.2Mbps, respectively. So let's use the example of a user with 8Mbps/2Mbps service on this port. In order for their traffic to be marked with a lower priority on this downstream port, they must be consuming 5.6Mbps in the downstream direction for 15 minutes or more, while said port is highly utilized

Once that condition has been met, that user's downstream traffic is now tagged with the lower priority QoS level. This will have *no* effect whatsoever on the traffic of that user, until such time as an actual congestion moment subsequently occurs (IF it even occurs). Should congestion subsequently occur, traffic with a higher priority is handled first, followed by lower priority (and this is not a throttle to X speed)

I hope this helps. You can others can feel free to contact me directly if you have any questions
Regards
Jason Livingood
  - Engineering & Technical Operation

For verification, you can find the original in the IP Archives. Date of the email is 2008-09-24 12:37:35

Some of what you write is debatable, but some isn't.

The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade.

Saying that is ignoring the facts. Both the ASF and the Debian project classified the Microsoft's license for their patent as inherently incompatible with free software. And patents on e-mail standards, unlike patents on many other IT technologies, are a very particular problem because a very large (if not the larger) part of the e-mail server world runs on free software. Go read the ASF's and Debian's explanations, they certainly did do their homework.

Sender-ID is not incompatible with SPF as alleged. The only difference is at the recipient side and the recipient cannot be forced to interpret SPF or Sender-ID in any particular way.

(To be explicit about my motives: I am the one who appealed to the IESG/IAB on behalf of the SPF project about the reuse of "v=spf1" records for the PRA algorithm in the Sender ID specification.)

You correctly point out that a communication standard is little more than a silent agreement between senders and receivers that only works if the receiving party tries their best not to misinterpret what the sending party meant. But then you simply quit the subject, assuming that communication standards will work even with everyone interpreting stuff their way, because, after all, there is no protocol police, thank you. Sorry, but "compatible" means something else to me.

We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.

Again you are missing the facts. Quoting from my appeal to the IESG:

It is also worth noting that at the time the MARID WG was closed [in September 2004], the then-current Sender ID specification draft-ietf-marid-protocol-03 did not include the re-use of "v=spf1" records for PRA checking. This was only introduced in [Microsoft's] individual submission draft-lyon-senderid-core-00 in October 2004. Also did Microsoft's record generation wizards generate only "v=spf2.0/pra" records until the end of October, when they began generating only "v=spf1" records.

Read the appeal. It connects a lot of dots that many do not like to remember.

Some of what you write is debatable, but some isn't.

The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade.

Saying that is ignoring the facts. Both the ASF and the Debian project classified the Microsoft's license for their patent as inherently incompatible with free software. And patents on e-mail standards, unlike patents on many other IT technologies, are a very particular problem because a very large (if not the larger) part of the e-mail server world runs on free software. Go read the ASF's and Debian's explanations, they certainly did do their homework.

Sender-ID is not incompatible with SPF as alleged. The only difference is at the recipient side and the recipient cannot be forced to interpret SPF or Sender-ID in any particular way.

(To be explicit about my motives: I am the one who appealed to the IESG/IAB on behalf of the SPF project about the reuse of "v=spf1" records for the PRA algorithm in the Sender ID specification.)

You correctly point out that a communication standard is little more than a silent agreement between senders and receivers that only works if the receiving party tries their best not to misinterpret what the sending party meant. But then you simply quit the subject, assuming that communication standards will work even with everyone interpreting stuff their way, because, after all, there is no protocol police, thank you. Sorry, but "compatible" means something else to me.

We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.

Again you are missing the facts. Quoting from my appeal to the IESG:

It is also worth noting that at the time the MARID WG was closed [in September 2004], the then-current Sender ID specification draft-ietf-marid-protocol-03 did not include the re-use of "v=spf1" records for PRA checking. This was only introduced in [Microsoft's] individual submission draft-lyon-senderid-core-00 in October 2004. Also did Microsoft's record generation wizards generate only "v=spf2.0/pra" records until the end of October, when they began generating only "v=spf1" records.

Read the appeal. It connects a lot of dots that many do not like to remember.

Stuart Gathman's opinion is recorded at http://archives.listbox.com/spf-discuss@v2.listbox .com/200410/0488.html.

Yes, it does. You'll have to switch from forwarding, where the envelope sender is preserved, to remailing, where the envelope sender is changed. But don't worry, we're working on providing SRS patches for the four major opensource MTAs, so that when you upgrade to an SPF-aware version, this problem will be solved also.

If your forwarding runs through a commercial service like pobox.com, you shouldn't have to do anything. They have to change with the times, and perform the above rewriting automatically for you. SRS is a structured standard that helps them adapt.

Until the SRS patches are ready, the following workarounds will preserve the important functionality.

Re: [spf-discuss] Article on Microsoft patents and Caller ID

Well, if Google, Yahoo (who created the spec, and indicated that they would be using it shortly), and AOL (who says they will begin testing in Q1) all use DomainKeys, we probably have a de facto email authentication standard.

Unfortunately for all the DJB-acolytes, this means that djbdns, as well as being proprietary and insecure, will not have a place on the internet from Jan 1st 2005, the day SPF+ will be activated globally.

Unfortunately for all the DJB-acolytes, this means that djbdns, as well as being proprietary and insecure, will not have a place on the internet from Jan 1st 2005, the day SPF+ will be activated globally.

Other plans include replacing BIND with djbdns, and integrating SPF+ with sendmail.

Interestingly, it looks like SPF+ may be forked, as an attempt to escape the ludicrous shoehorning of XML into SPF2 by Microsoft.

Interestingly, it looks like SPF+ may be forked, as an attempt to escape the ludicrous shoehorning of XML into SPF2 by Microsoft.

Interestingly, it looks like SPF+ may be forked, as an attempt to escape the ludicrous shoehorning of XML into SPF2 by Microsoft.

Interestingly, it looks like SPF+ may be forked, as an attempt to escape the ludicrous shoehorning of XML into SPF2 by Microsoft.

The open source community's response so far has been SPF+, which is essentially a technique of encoding the rules in TCL, which is served over DNS and executed on the mailserver. For obvious reasons, SPF+ will probably define the future of spam control on the internet.

Before the flag day, SPF will work the way it is now. After the flag day, which will probably occur later rather than sooner, SPF will have all the functionality of Caller ID. Here's a line to the post with the real info. Feel free to re-read it. Here's the sections about the "flag day". It's easy to see the "flag day" is about requiring forwarding MTAs to implement an extension to ESMTP, not the dual syntax of accepting either v=spf1 or xml (which will presumably occur very soon, since it doesn't impact anybody negatively, except people with a religious believe that one syntax ought to be universal.)

THE BIG NEW IDEA: let's define a new ESMTP field, "RFROM".

[snip]

If a MAIL RFROM is not present, checks run against the PRD from the headers ...

... Until the Flag Day, when you can go back to checking MAIL FROM if the RFROM is not present.

[snip]

THE NEED FOR A FLAG DAY

* The promise made to the SPF camp was: you will one day be able to reject forged MAIL FROM based on SPF lookups. I intend to keep that promise.

* Under the Old SPF, until the forwarders were all SRS compliant, we used a hacky workaround with trusted-forwarder.org.

* Under the New SPF, until the forwarders all use RFROM, we are in the same boat.

* Either way we need the industry to announce a flag day: we need to strike a balance between giving forwarders lots of notice, and being able to block stuff before DATA.

* Changing the burden to RFROM instead of SRS makes things a lot easier for forwarders. That reduces their adoption threshhold. Everybody wins.

* We can't decide today when the flag day will be, but one day soon we
probably will be able to.

* Before the Flag Day:

- Campaign for MTAs to start supporting RFROM.

- In the absence of RFROM, receivers SHOULD NOT reject spoofs until after seeing data, and SHOULD use responsible addr from 2822 header.

- (Receivers who know exactly who's forwarding to them may choose to reject anyway. Local policy, etc.)

- Fight Joe Jobs with SES.

* After the Flag Day:

- MAIL FROM RFROM now expected from forwarders.

- MAIL FROM spoofs without RFROM MAY be rejected.

- Flag day requires industry coordination to ensure MAIL FROM / RFROM support is out there.

- RFROM harder to spoof because only a PASS result is acceptable.

Microsoft would be from a technical standoint far ahead of the SPF crowd (who are pushing an ugly, nasty-side-effect hack if I've ever seen one). Microsoft may actually produce something that benefits the community as a whole. Seems incredible, but...wow, if we owe having a *good* email infrastructure to Microsoft, the world will be standing on its head. Anyone have a link to a good technical description of Microsoft's proposed system?

When I see things like this. It really doesn't give me a good feeling as to ESR's technical understandings of SPF.

I'm sure Wietse and Claus have a pretty good grip on SPF as well. You may want to have a look at the postfix-users archives to confirm that for yourselves.

Before looking at SPF you may want to read what Claus Assmann [theaimsgroup.com], and Wietse Venema [theaimsgroup.com] have to say on the subject.

You might also want to read what Steve Bellovin (one of the guys who invented USENET among other things) and Eric Raymond have to say about it. They spend a little more time understanding SPF...

Wired story with Raymond's comments.

Bellovin's comments in an email to the SPF mailing list.

I have a site hosted on Hostway, and I don't see any way to put up an SPF record. I just emailed them about it.

Also, what about GoDaddy? I don't see any way to publish a SPF record, and by the results of a quick Google search, it looks like GoDaddy doesn't offer it. Before SPF gets off the ground, all these providers will need to support it.

Patch snipped because Slashdot complains about too many junk characters.

Admittedly, this is still not an ideal solution, as it takes an intervention by the sysadmin whenever a user decides to sign up with a "new" forwarding service.

However, on the SPF mailing list, they are mentioning a trusted-forwarder.org domain, which, when finished, will act as a DNSwl (DNS white list) to inventory all known forwarders (such as pobox, netcourrier, ...)

Agreed on most points.

I'm not sure PKI needs to be part of the SPAM solution. Three reasons:
1) The same clueless ficktwizzles that set up their mail servers as open relays (224K of them? according to ORDB.org) will also be setting up their mail server certificates. No, this isn't fraught with peril.

2) There isn't a black market (that I'm aware of, doh) of private keys. Client certificates are useless, server certificates are useless unless you also own the domain name, code signing certificates, well, um, yeah I guess those are dangerous. But we've seen the lengths spammers will go, and I can easily foresee a huge market for stolen certificates, if now every domain has one to send mail.

3) The _last_ thing we need to do is get Verisign slobbering over using certificates for email. Over in the SPF discussion mailing list there are Verisign people who want certificates in the DNS records published by SPF.

Say for example Listbox or there's always Egroups. My own company's mailing list services aren't really ready for prime-time yet, but I do operate the announcements-only mail list for the Philadelphia Eagles, and that is about 11000 subscribers although it is one-way only.
--