davideous

GreenArrow | Chicago, IL | REMOTE | Full-time

GreenArrow makes enterprise email server software used by companies such as Fry's Electronics, Merriam-Webster, and Six Flags and email service providers. We are a close-knit 12 person company, bootstrapped, and profitable.

What will you be working on? Our flagship products, GreenArrow Engine & GreenArrow Studio which provide flexible and secure SMTP and API email delivery along with subscription management and content creation. We have a strong emphasis on shipping quality product.

We are looking for:

* Senior level developers who love Ruby on Rails

* Great taste in code (http://www.youtube.com/watch?v=YJDOz1GGZnk&t=14m20s) and the desire to ship a high-quality product

* Experience with React, Postgres, and Go is a plus

* US and Canada candidates only

Hiring process: Resume review, initial coding challenge (estimated 2-3 hours), cultural interview, several in-depth technical interviews (which include you writing code on your computer with a screen-share).

What to learn more?

* https://www.drh.net/careers

* https://www.drh.net/careers/experienced-ruby-on-rails-develo...

Obligatory XKCD: https://xkcd.com/538/

Yes, it would technically meet the Open Source Initiative's definition (https://opensource.org/osd), but if there was no way to re-flash the device, no way to verify the binary on the device, or possibly even no way build a binary (which may require proprietary tools under NDA from the chip manufacturer) -- I think a lot of critics would still be critics, but I could be wrong.

If Yubico did this it would be very interesting to see the reaction.

> They could prevent bad firmware updates by wiping keys on upgrade

This does not close the attack vector of someone intercepting the device before you get it and surreptitiously installing firmware with a backdoor.

Yes, pritambaral described what I'm trying to point-out.

In think the "vs" in the title is saying this: they had to choose between open source (that is functional meaning you can really use the code and re-flash the device) and the secure hardware. It was a trade off of one "vs" the other, and this is their reasoning behind that trade-off.

I think if they released the source, but you weren't able to reflash the device (which is a design trade-off they chose to close some attack vendors), people would be up-in-arms and saying "it's not true open source because I can't re-flash or verify the device."

In discussions like this the phrase "security by obscurity" gets used as an accusation. We all agree "security by obscurity" does not work. But that's not what is happening here.

Wikipedia's definition: "the reliance on the secrecy of the design or implementation as the main method of providing security for a system or component of a system."

Youbico isn't saying that the security of the device is increased by keeping the source code secret.

They say they are increasing the security by things like this: disabling user-loading of new firmware (which could be a bad actor loading bad firmware), using hardware with built-in side-channel countermeasures, and disabling JTAG ports (which could be used for key extraction).

This isn't obscurity. These are some good engineering arguments. Engineering is always full of trade-offs.

We should pump the waste heat into greenhouses and grow tulips.

(https://en.wikipedia.org/wiki/Tulip_mania)

This reminds me of the elevation of Mt Everest as determined in 1856:

> Peak XV (measured in feet) was calculated to be exactly 29,000 ft (8,839.2 m) high, but was publicly declared to be 29,002 ft (8,839.8 m) in order to avoid the impression that an exact height of 29,000 feet (8,839.2 m) was nothing more than a rounded estimate

Source: https://en.wikipedia.org/wiki/Mount_Everest

We have an reverse osmosis unit that has a "remineralizer," which adds back in minerals. It's basically a filter canister with minerals in it, which mineral-free RO water dissolves.

There are bombs where a fission stage ignites a fusion stage which sends neutrons to start another fission reaction.

From: https://en.wikipedia.org/wiki/Thermonuclear_weapon#Summary

"(3) The fusion fuel of the secondary stage may be surrounded by depleted uranium or natural uranium, whose U-238 is not fissile and cannot sustain a chain reaction, but which is fissionable when bombarded by the high-energy neutrons released by fusion in the secondary stage. This process provides considerable energy yield (as much as half of the total yield in large devices), but is not considered a tertiary "stage". Tertiary stages are further fusion stages (see below), which have been only rarely used, and then only in the most powerful bombs ever made."

This appears to be working so far.

One sample doesn't really establish a "market rate" yet, so I don't worry about the seller not being motivated by financial profit motive. Sometimes the value provided to the seller goes beyond the financial payment. 18F gets a good deal here because of the intangibles they have to offer.

If they put out more projects than the amount of work people are willing to do at the "$1 volunteer" or "$1 build my portfolio" rate, then the price should go up. How deep is this pool? I guess they will find out.

The big challenge, I think, will be if bad actors start coming in and making crazy bids and then doing sloppy work. Time will tell.

I'm excited to see how this develops.

The big difference is that Apple has a monopoly on distributing iOS apps. In music, Apple has to complete with other music streaming services and other channels, so they have to be competitive to get artists to sign up for Apple Music.

Not true. We have plenty of clients using their own decentralized email servers and getting great inbox delivery of legitimate bulk email.

To get good results on your own server, you need:

(a) To be sending email that people want to receive.

(b) To have the technology setup correctly. It's not hard; we do it all the time for our clients.

(c) It's greatly beneficial to above ~20k messages/day on your own server. Not required, but being above that point lets the ISPs gather statistical data on your complaint and open rates, which allows reputation filters to click in.

My company, www.drh.net, provides an SAAS or on-premises Mail Transfer Agent, GreenArrow Engine.

You can run it in your network and tightly lock down the system. We can take care of all of the email deliverability setup and operations tasks, if you want.

One advantage of running licensed software on your network is that you don't pay per-message fees, so for higher volume it's really economical compared to a service like SendGrid.

We sell enterprise email server software. It's high-touch and sometimes a long sales cycle. Lots of demos of the software via screen-share.

Right now we have two people in sales. They are collaborating multiple times a day on Skype and help each other out on basically every sale.

Much of your concern seems to be about the ability to hire the best people, given the preference for commissions. I've been fortunate here: I've been able to hire my sales reps through personal connections, based off of reliably knowing their prior performance -- and I know I have really good people.

Perhaps it would have been harder to start the sales organization without commissions without these connections. But it's working for us right now.

Here's a good article on why Fog Creek does not pay sales commissions:

http://blog.fogcreek.com/why-do-we-pay-sales-commissions/

We don't pay sales commissions at my company, and it works well for us. It does help the sales department to work more as a team.

> As an e-mail services provider, I cannot or should inspect what my customers are sending. I can suspend them due to complaints of abuse but the damage is already done.

As an ESP, since you are letting customers send through your IP space, then a bad-apple can hurt the delivery of your other clients.

This is one of the big jobs that an ESP has. MailChimp, for example, has invested a ton of effort into detecting bad-apples as early as possible. (There are some really neat big-data techniques.) This is also why SES requires that you start with a smaller quota and build-up.

Some techniques:

* manually reviewing new clients before they send

* giving a new client a limited sending quota, so they build reputation with you over some time

* detect clients/campaigns with high complaints, high bounces, or low opens and take compliance action

* detect a partially-sent campaign with a high bounce rate and suspend it

* don't give any client an unlimited sending quota, so they can't hurt you too badly

> I still say, block domain names, not IPs..

There's a minimum amount of mail volume required to build a reputation. Many of your clients might not have this so they benefit from being lumped-in on an IP reputation.

I don't think IP blocking will ever go away, as it's an effective technique. The threat of an IP block also places some reasonable pressure on ESPs to police their client base.

Yes, good senders will still get messages flagged as spam. But the ISPs know this and they look at the complaint ratio. A complaint ratio of 0.5% or 1.0% is considered good. A complaint ratio of 3.0% is a problem.

We have one customer that's cleanest-of-the-clean (confirmed opt-in, valuable content, solid brand) sending 600k emails/day, and we see hundreds of spam reports. But their email gets delivered to the Inbox.

If you're a good actor with a solid technical setup you're still going to have an occasional delivery problem. This is why monitoring is so crucial. But you're not going to be putting out fires left-and-right, which is what it sounded like what _asciiker_ was saying he is doing.

The freedom of choice is actually in the hands of the end-users.

The end-users choose which email providers (Yahoo, Gmail, Hotmail) they want to use. The email providers are motivated to provide a good user experience, which includes blocking unwanted email because they make their money through user engagement.

The key to delivering into the inbox is sending mail that your recipients both want and expect. Provide a good user experience, and you'll build a good reputation. Push the limits (for example, use a "pre checked" checkbox on an order confirmation page to put people on your sales mailing list) and you'll be putting out email delivery fires all of the time.

Most of the things that you describe (SPF, SenderID, DKIM, PTR, MX) are all technical requirements, which are just the baseline for delivery. These are required, but any sender of unsolicited email can configure them. They don't earn you access to the inbox. Just like properly formatted HTML does not earn you great SEO results.

I like to break email delivery down into four areas:

* who -- send to people who requested your email and are expecting it

* what -- send something of value to these people

* technical foundation -- (SPF, SenderID, DKIM, Feedback Loops, etc.) required, but having it does not give you any points

* monitoring -- (open ratio, complaint ratio, ISP response codes) you need to know when something goes wrong

(My company, www.drh.net, has been providing email server software, services, and deliverability consulting for over 10 years.)

---

[edit; added the below]

Another way the freedom-of-choice is in the hands of the end users is this: the big ISPs (yahoo, gmail, hotmail) make most of their filtering decisions based off of end-user behavioral data.

For example:

* what percentage of your email is opened

* what percentage of your email is complained about (the "this is spam" button)

* what percentage of your email is deleted without reading

* how long is your email read

* how much is forwarded

* how much is replied to

* what percentage of your email that was placed in the Spam folder when seen by the user received a click on the "this is not Spam" button.

This is the end-users voting on if they want your email or not. This isn't the entire email deliverability equation, but it's a huge part of it.

The ISPs treat this data so importantly because: (a) it's hard to game unlike content filtering, and (b) it directly correlates to good user experience which they want to provide.

[edit to make bulleted list look right]

This is illegal in the United States under the CAN-SPAM law

From: http://www.business.ftc.gov/documents/bus61-can-spam-act-com...

"You can’t charge a fee, require the recipient to give you any personally identifying information beyond an email address, or make the recipient take any step other than sending a reply email or visiting a single page on an Internet website as a condition for honoring an opt-out request"

(My company provides email delivery software and consulting.)

[edit for typo]

This reminds me of something my Latin teacher used to say: We don't know how Latin was actually pronounced because all of the audio tapes were destroyed when Rome burned down. :-)

Summary:

The author of this article came out of partial retirement to construct a novel bankruptcy plan for GM, which is what GM used.

The normal route would be for GM to file bankruptcy and have the court approve a restructuring. This restructuring plan would be fought over by creditors, and GM would be "dead in the water" while this was happening and loose market share. The author asserts this would have been a death blow to the reorganized GM.

The novel plan was to split GM into two companies, "OldCo" and "NewCo," either before or after filing for bankruptcy (the article was not very clear). NewCo would emerge from the bankruptcy as the new GM, and OldCo would be liquidated. The bankruptcy process would complete faster as the restructuring plan was already "set" by splitting into two companies.

There was internal debate in GM about this plan. A more standard bankruptcy was also being prepared. The Obama administration, in providing funding to GM, decided for the NewCo/OldCo plan and also ousted the CEO of GM.

This article is written by the author of the NewCo/OldCo plan, so it may be self-serving.

The article spends more time describing the process of and drama around creating the plan than the details of the actual plan.

[edit for clarity and typos]

We're not a contracting agency, but we pay in that range for 40 hours/week, are a 100% remote company, allow flex time, and with good benefits. Email me at dharris@drh.net if you're interested.