Sorry about that - we use Tumblr to host the blog and have had some issues before. I just converted to a pastebin for you, unfortunately didn't think to include any of the comments but here you go: http://pastebin.com/yHw7L0Fy
Yeah, I decided not to get into all of the options of each header. Partially because I was writing from a plane without wifi and partially because the response I was hoping for was "these things exist - I'll go read the docs on them".
That said, your points about X-Frame-Options and CSP are definitely important for usability. Maybe I'll update the post w/ some of those details.
Ha fair enough, and thanks! One problem with the CA system is that (as far as I understand) it really doesn't matter whether you choose a particularly secure CA or not - you're as vulnerable as the most vulnerable CA. That's why something like public-key pinning is important.
Good to know - thanks. More support is better, but the thing I really like about CSP is how it is still useful as a canary even with only partial browser support.
We'll try to keep adding whatever information we can about our deployment. If you have specific questions just shoot us an email - they'll probably be good inspiration for future posts.
That's a great question, and to be honest it's a bit of a pain point so I probably should've talked about it in the post.
When developing a new M/R job from scratch I start by mirroring (at least part of) the data to a local database. Then I can iterate locally on the M/R using print() and printjson() to debug the map() and reduce() functions - those will print directly to the database log.
I tend to just embed the map() & reduce() functions as Python strings like you see in the post. I'm confident that there are better ways to handle this, though. One approach that can be interesting is to do development from the shell, that way you can write and debug the map() & reduce() in an actual JS environment. Once you're happy with them you can just drop them in as strings with the rest of your application code. Would love to hear how other people are approaching this stuff, too.
All of that said, I expect that the tooling here will improve over time.
Hi, fiesta.cc is me - working on the white-labeling stuff as we speak. Shoot me an email if you think you might want to try it. mike [at] corp.fiesta.cc
the defining feature of fiesta.cc (as opposed to posterous, etc) is that list names don't have to be unique - so anybody can make a new list called "[email protected]" without worrying about registering the name or running into collisions.
Right now messages aren't saved at all (for privacy reasons). In the future there will be optional (opt-in) archiving like yahoo/google groups has.
oops, thought that was handled properly. fixing now (if you don't want to wait you can change your name from the "Dashboard" page). Thanks for the heads up!
Thanks for the feedback! I was thinking of .cc as a feature, designed to evoke the act of CC'ing an address to create a list. Wasn't a decision made due to lack of seriousness or to cut costs, but maybe still needs rethinking if the CC connection isn't obvious...
Yeah, the other nice thing about this compared to librelist is that you can use any list name you want without worrying about conflicts (since lists are tied to the sender's address).
Yup, using MongoDB to store everything. I will definitely be doing a post discussing the architecture, etc. Follow @mdirolf or @fiesta and you'll see it when it pops up.
The short answer, though, is that I'm running a 3 node replica set. Each mailserver (right now there are 2) is running on one of those nodes.