cmorrisrsg

Lead engineer at MailChimp here. Funny you should mention it, but tomorrow we're going to be launching Google Authenticator and YubiKey integrations with AlterEgo so you can use those as you like. We're also working on a Duo integration, but no ETA there.

We saw it pop up on Centos6 as well. JRE 1.6 and 1.7.

We saw this on every Ubuntu Lucid machine we run. Restarting the JVM was insufficient - we ended up fully rebooting the machines.

Yes - the pricing is flat rate. Right now charging for inbound emails is turned off since the feature is so new and basic, but inbound emails will be indexed and tracked the same as outbound emails, so they'll be charged the same.

Well, supporting unsubscribes in transactional emails can sometimes make sense, like with notification or confirmation emails where the user might want the option to not receive them. With others, like receipts or signup confirmations it makes less sense. For now, we presume that you're going to do the right thing and implement unsubscribes if it makes sense for the emails you're sending. We've got a feature coming to make that process easier, but it's still going to be a decision that the sender is going to need to make.

It's really simple right now. We add a List-Unsubscribe header to each email which in supporting email clients (like gmail) adds an unsubscribe button to the report spam button that's always there. If the recipient unsubscribes in that way, we treat it as an unsubscribe. The more traditional subscription model isn't supported by Mandrill at this time. You'd need to build your own or use MailChimp for that. I recommend MailChimp, it's pretty good at handling subscription-based email like that ;)

We've considered it, but we're still working on our reseller/integrator story.

You can customize DKIM without a dedicated IP. You do need to have a paid plan to get the dedicated IP, but that's really because you need at least a few hundred thousand emails per month of volume before getting a dedicated IP. With lower volumes (like anything that can fit in the free plan), the sending reputation of one of our shared IP addresses is certainly better than a dedicated IP with no reputation.

Yes - you can use Mandrill for newsletters if you want to code your own subscription logic and store your own list of emails. MailChimp is quite a bit more expensive than Mandrill, but it does a lot more too. MailChimp stores more analytics than Mandrill does and stores it longer. It handles scheduling, batch testing, social integrations and content management in ways that Mandrill really doesn't. MailChimp also has analytics and profiles for list subscribers that Mandrill doesn't have.

If Mandrill does everything you need it to do and you can do the rest on your own, you should use Mandrill. It is, as you note, much cheaper.

Not yet. The inbound system right now is really basic - we'll parse out the messages and deliver them to a webhook, but we won't munge it much beyond breaking apart attachments and things.

There are a few things that we think set Mandrill apart from the pack. Our application is designed with responsiveness in mind, and we have mobile application on both of the major platforms so you can get access to your email stats and reputation wherever you are. We have search and analytics deeply ingrained in the application in a way that is fairly unique - letting you see your emails in context and trying to derive the context for you when we can. We also integrate deeply with the main MailChimp product. They use the same underlying delivery engine, the same templating and content personalization systems, and we have a heavy discount for users of both products.

Mandrill's still a rapidly iterating product for us, but we think we can take the same sense of usability and power that we have in MailChimp and extend it to email more broadly.

We're trying to make Mandrill a stable email platform for all uses, so in that way we're similar to SendGrid. Where we're really trying to focus isn't so much in just the delivery of the email, though we do have a ton of experience doing that well.

Mandrill is a product that is trying to make your application-driven emails as easily tracked, tested, and understood as the bulk email you'd send using MailChimp. It's still early days for the product and we're still iterating rapidly, but that's where we're trying to get.

We're also integrated with MailChimp itself. We've got a big discount for paid MailChimp users that want to use Mandrill, and you can share templates between Mandrill and MailChimp easily. We'll be integrating more deeply in the future - really trying to make a one-stop shop for email-related needs for businesses.

That's one of the reasons we chose that name for the brand. Since Mandrill is an infrastructure service, we wanted it to feel more serious and aggressive than MailChimp.

We built on top of our own internal job scheduling systems that we use for email to handle retries, batching, and concurrency handling so we don't overwhelm your servers. It's all custom stuff, though.

You do get all the information we have on the message and the bounce. Recipient, sender, subject line, bounce info, tags, etc.

Hey - I'm Chad, the project lead for Mandrill. I'd be happy to answer any questions you guys might have.

A viable solution going forward is to have browsers implement both the vendor-prefixed and non-vendor-prefixed versions of a property, but use the vendor-prefixed one preferentially. That would allow developers to use one non-prefixed rule in the common case where all supporting browsers implement the rule in the same way, but developers can target particular browsers if they deviate. Or if you're worried about the standard deviating, support vendor-rule and x-rule at the same time.

For the current webkit- mess, it's probably best to just have the vendors implement each others prefixes on a case-by-case basis (when you know the semantics are the same). There are way fewer browser vendors than there are website developers, and it's much easier to get them all in a room to agree on something.

This is only hypocritical if when Stallman says "phone", he always means "cell phone". Just to be a devil's advocate, he could be talking about a landline which generally doesn't track movement, doesn't run software, and doesn't get turned into a listening device.

Any coding problem that could feasibly be completed in an acceptable amount of time would be too small to actually tell me what I want to know. I mostly don't want to know what algorithms you're aware of or how quickly you can type. I want to know how you structure and modularize code. I want to know how you debug things. I want to know if you can refactor well. In short, I want to know about how you handle building and maintaining real software. If I hired people to do coding problems all day, that would be another thing, but I don't.

I actually reject people without pet projects for an entirely different reason. I can find out much more about how you behave as a developer and whether or not you'd fit in with our company by reading your code than I can from any kind of interview or whiteboard challenge. Ideally you'd actually hire the prospective developer for a short contract project before hiring, but that has significant challenges and costs as well.

Think of a carpenter that claimed to be amazing at producing furniture, but had none to show you. Would you trust them on how well he could BS you in an interview? It's not about passion or dedication. If you, producer of code, can show me code you've produce, I'm taking a much lower risk on hiring you. And fortunately, there are enough people around with code to show that rejecting others is a pretty easy filtering decision to make.

It'll be interesting to see how much this gets adopted. Ad-hoc query languages like SQL are great for operations and reporting, but if your NoSQL store needs to conform to the limitations of the unQL language, aren't you losing that "polyglot persistence" quality of using NoSQL?

I like this, supposing that it lets extensions request permissions at the point when the user tries to do something requiring the permission, rather than at install time. At install time, the user has no idea why the extension needs a permission, and for the user's use-case it might not even need it. The extension has to ask for maximum permissions from the beginning.

This should make it easier for the user to gauge privacy lost vs. feature gained, rather than having to make essentially a brand trust decision from the start.

The Lua community has been historically more focused on embedded and scripting scenarios, and less on building a comprehensive platform for libraries and applications (compare the quality and availability of LuaRocks to PyPI, Ruby Gems, CPAN, etc.). That combined with the almost non-existent standard library means that not only does Lua not give you a solid base of code to build off of, it's hard to find a community-driven one as well. This leads to developers having to play mix-and-match to get a good base running. Also, the "table can be used to emulate any structure" piece means that every library and developer does OO and modules just a little bit differently, harming reuse across code bases.

There are a couple of syntax decisions (default globals, no ++ or --, indexes start at 1) that might cause negative reactions, but I'd put the lack of libraries and frameworks above that.

Lua is still awesome for simplicity, easy C binding, and performance, but deciding to build a new project in Lua requires a significant investment in just getting the base libraries put together.

It's probably not a slight against Chrome. These sorts of edge-case error pages are typically some of the least up-to-date for a website. You need to use a browser they don't test with to see it, so naturally they won't see the page during testing.

Alternately, Chrome might be legitimately untested but functionally equivalent enough to Safari that everything works. In that scenario leaving Chrome off the list of supported browsers is just a CYA in case something doesn't work.

No, bulk importing does not send a resubscribe message. MailChimp assumes that if you have access to the address list, then you have permission to send.

Copying this from my blog comment answering the same question...

Pseudo-transactional campaigns are very "pseudo". MailChimp campaigns require static predefined content. If you actually wanted to vary the content from recipient to recipient, you need to find a way to stuff the dynamic content into merge fields as you send which can cause latency and concurrency issues.

Also, since pseudo-transactional campaigns uses our sending infrastructure tuned for large bulk mailing, the delivery times are somewhat longer (on the order of minutes) for pseudo-transactional campaigns, vs seconds for STS.

No fine-print. Our high volume plans for large email lists are not unlimited, but smaller lists are completely free to send as much as they want. In practice, you'll hit our anti-spam limits long before you hurt our profitability if you try to send lots of email to a smaller list.

We had a fairly conservative cross-validation function that tested the results of the genetic optimization for a first pass. Following that, Omnivore was put into "observation" mode, so we could verify that the results it generated were predictive going forward, and not just biased towards the test set. Over the course of the past few months, the model has held up quite successfully.

Since accusing a customer of being a spammer without non-heuristic proof can be an emotion-ridden experience for everyone involved, we were conservative and optimized for accuracy over efficiency pretty much every step of the process.