Who/Where is nodejs.org email running?

[mikeal]

I don't actually know who is running this or what the setup is but we'll need to figure it out before we offer people email addresses as part of membership.

I know that the LF has some people who host email infra, is this being moved over? @mkdolan

[chrisdickinson]

It's on Google Apps, I do believe. Unsure who has access – maybe @misterdjules?

[TooTallNate]

Is indeed Google Apps:

❯ dig +short MX nodejs.org
20 ALT2.ASPMX.L.GOOGLE.COM.
30 ASPMX2.GOOGLEMAIL.COM.
20 ALT1.ASPMX.L.GOOGLE.COM.
30 ASPMX3.GOOGLEMAIL.COM.
10 ASPMX.L.GOOGLE.COM.

[misterdjules]

Yes, I have admin access to the email and groups services of this Google Apps account. I'm not a big fan of Google Apps though, so it might be a good time to think about a better solution.

[jasnell]

+1 on determining a better solution. Let's delimit some of the options here. What are our minimum requirements? Do we just need a straightforward mail server?

@mkdolan ... what are some of the other Linux Foundation groups using for mailserv?

[mkdolan]

All of our projects are using mailman.

On May 19, 2015, at 10:53 AM, James M Snell notifications@github.com wrote:

+1 on determining a better solution. Let's delimit some of the options here. What are our minimum requirements? Do we need a straightforward mail server?

@mkdolan https://github.com/mkdolan ... what are some of the other Linux Foundation groups using for mailserv?

—
Reply to this email directly or view it on GitHub #2 (comment).

[mikeal]

Yeah, the Google Apps cost structure is per account which is a non-starter if we want to give out an email address to each individual contributor.

How many current emails lists and accounts will we need to migrate?

Rather than maintain actual email accounts can we just give out email forwards for simplicity?

[mkdolan]

If you’re talking about giving out email accounts, that’s different than mailman and potentially much more costly to host. I’d have to check on that with our IT systems team.

On May 19, 2015, at 11:40 AM, Mikeal Rogers notifications@github.com wrote:

Yeah, the Google Apps cost structure is per account which is a non-starter if we want to give out an email address to each individual contributor.

How many current emails lists and accounts will we need to migrate?

Rather than maintain actual email accounts can we just give out email forwards for simplicity?

—
Reply to this email directly or view it on GitHub #2 (comment).

[mikeal]

I can look around for a good solution to doing simple email forwards.

[mikeal]

DNSimple has an API for email forwards that looks acceptable, and quite cheap. https://developer.dnsimple.com/domains/forwards/

[guyellis]

If Google provided the email accounts to the Foundation for free would it be an option?

[mikeal]

@guyellis possibly, but I don't know how realistic that is. People at Google have been trying to get our G+ account upgraded for months and haven't been successful yet :(

[rvagg]

the Google Apps cost structure is per account which is a non-starter if we want to give out an email address to each individual contributor.

Only for full user accounts, we don't need that, we just need redirects and those are essentially free, just one Google Apps user to administer and redirects for all, mailing lists for all. My varied experiences bending Google Apps to various use-cases is very positive, I'm not seeing the problem here.

[mikeal]

@rvagg I don't see how to do an alias outside of an account on that domain, am I missing something?

[rvagg]

it's all merged into the "groups" functionality now, make a group with a single user and make it public and it gets bounced on

[mikeal]

@rvagg in the past I've had some pretty bad issues with groups having too aggressive a spam filter (and no way whatsoever to see any of the stuff that gets filtered). What we did at my last company was setup a user account and forward the mail to a group instead of expose groups directly in order to get around this, but this was all like a year ago, I'm curious if you've seen any similar issues since.

[rvagg]

ditto, I've had problems like that in the past but more recently my email load has gotten so large that it wouldn't really bother me if the occasional email went missing! I'm more than happy to incentivise people to use more appropriate communications channels with me. I also haven't heard much complaining from others about this either lately. But .. ymmv.

[rvagg]

If it was important enough, we could task @nodejs/build with spinning up a custom solution for this but that does seem suboptimal, it's just email after all

[mikeal]

ya, i'm leaning towards the dnsimple thing if the API is easy enough because it would be really easy to automate. then we can use google groups for the actual email groups.

[bnb]

I see that you guys have pretty much decided on redirects, but I remembered @substack's eelmail from a while back. Could that be adapted easily?

[rvagg]

Hey ... how about we just run a server with postfix to do all of this, we don't need mailboxes, just an MX server that will handle incoming and forwarding. We could easily do this in @nodejs/build and do it via Ansible so it's easy to update and replace and ...

We could start off doing this for iojs.org since we have the DNS in Route53 already and there's no MX for it now.

[jbergstroem]

@rvagg you serious about maintaining mx infra? I don't think its the best solution – but if we need to be provider-neutral I can set it up/maintain it. I've hosted postfix/dovecot (mysql backed) for a long time if we need more than forwards.

[rvagg]

@jbergstroem since we have no need to maintain inboxes all we really need is a simple postfix or similar to handle simple forwarding rules for individuals and lists. It's a simple job and wouldn't need anything fancy. I used to do this too in a previous life, before Google Apps made it too easy to DIY.

[mikeal]

we need forwards and a group list for security issues.

what provider can we use? i know a lot of providers block email ports because of spam concerns.

[rvagg]

we only need to serve incoming mail, not outgoing - use your own provider for that, mostly it'll be GMail, so the spam blocking isn't an issue

[rvagg]

actually, no, you're right, the forwarding process is going to be susceptible to the same spam filtering rules, so we'd probably get into trouble hosting on one of the standard IaaS providers

[Danese]

I'm completely agnostic on how you do this, but the two things we need from my perspective are:

1. a persistent, indexable and searchable public (by default) archive of all conversations about and around Node.js (currently managed as I understand it by a combination of GitHub PRs & issue-tracking, plus Google Groups. Is there also Stack Overflow? Where do we maintain Backlog?). This is absolutely critical to allowing the Open Source Effect.

2. a way to bestow @nodejs.org vanity email aliases to those who deserve them (be that a perk of committership or of membership). At Apache this is handled by a simple redirect thru the pre-existing personal account of your choice (commonly but not exclusively gmail, ideally not a corp account because: Job Changes)...there is also an expectation that you'll maintain/update current employer affiliation info on a Committers/Members list because: Research.)

It may be that all of this is already implicitly understood by the folks already in this discussion, but I thought I should put it out there in case your choices don't allow for these two outcomes.

D

On May 31, 2015, at 12:48 PM, Rod Vagg notifications@github.com wrote:

we only need to serve incoming mail, not outgoing - use your own provider for that, mostly it'll be GMail, so the spam blocking isn't an issue

—
Reply to this email directly or view it on GitHub.

[mikeal]

@Danese We get all of 1 if we use GitHub repos for all the communication (except for security).

[Danese]

Yes, but what about Stack Overflow? Our Slack channel?

D

On May 31, 2015, at 1:12 PM, Mikeal Rogers notifications@github.com wrote:

@Danese We get all of 1 if we use GitHub repos for all the communication (except for security).

—
Reply to this email directly or view it on GitHub.

[mikeal]

Stack Overflow has its own community. Questions get asked and answered there but it's sort of a silo. That vast majority of communication in the node community is on GitHub in the various project repos. In fact, I've seen people ask questions on Stack Overflow and get pointed at repos on GitHub.

[mikeal]

BTW, the Slack Channel is an Advisory Board thing that @voodootikigod set up and I'm not sure if we should keep it. Slack for public rooms has a pretty poor user experience and I don't know of any other project that has one setup. A could working groups have gitter channels they use but I don't know of any that are using Slack.

[guyellis]

Stack Overflow is more about "how to use node.js et al" while GitHub Issues are "is this (here is) a bug/what about this new feature etc." I think that they both serve important and distinct roles. I don't think we need to worry about SO inasmuch as it pertains to this topic. There will always be overlap and when that happens people will be pointed in the better direction.

[bnb]

@mikeal: Just a small comment - Socket.io was one of the first to set up a public Slack. http://socket.io/slack/

Their joining mechanism is public either on GitHub or on the creator's blog.

[Morgul]

@mikeal To be honest, I've become a pretty big fan of slack; while I agree it's a big odd how it works (assuming everyone's a team member, as opposed to having public users join), from a normal user's perspective, I actually think the user experience is fine.

Like @bnb pointed out, socket.io has had great success with it.

[kenperkins]

+1 on not maintaining our own MX infra. It's not worth the headache.

Mailgun has a really awesome programmable mail system that can deliver based on deterministic rules.

[rvagg]

Mailgun looks awesome, I wasn't aware of this. My understanding of a brief read is that we can use it to do simple routing so we can set up email addresses like ken@nodejs.org and have it sent to ken@rackspace.com or whatever the mapping was. That's the most basic functionality we need, can you confirm that it does this @kenperkins? If so then I'm all in, can we use our existing Rackspace account to enable this or do we have to sign up new? I'd love to start playing with this for iojs.org at least.

[mikeal]

+1 mailgun

On Tuesday, June 2, 2015, Rod Vagg notifications@github.com wrote:

Mailgun looks awesome, I wasn't aware of this. My understanding of a brief
read is that we can use it to do simple routing so we can set up email
addresses like ken@nodejs.org
javascript:_e(%7B%7D,'cvml','ken@nodejs.org'); and have it sent to
ken@rackspace.com javascript:_e(%7B%7D,'cvml','ken@rackspace.com'); or
whatever the mapping was. That's the most basic functionality we need, can
you confirm that it does this @kenperkins https://github.com/kenperkins?
If so then I'm all in, can we use our existing Rackspace account to enable
this or do we have to sign up new? I'd love to start playing with this for
iojs.org at least.

—
Reply to this email directly or view it on GitHub
#2 (comment).

[kenperkins]

Yes, it's fully programmable. You can do very simple routing (i.e. source->dest) or much more complex parsing based on rules. https://documentation.mailgun.com/user_manual.html#receiving-forwarding-and-storing-messages

It's available through our Rackspace control panel.

[rvagg]

sweet, playing with it for iojs.org now

[rvagg]

Done!

https://github.com/nodejs/email contains email management for iojs.org, there's an aliases.json file that contains the email mappings and there's an update program to make the mailgun routing match the aliases. If you want to add yourself to the aliases.json file you can (probably via PR) and one of the people with access to the mailgun account can run the update program to update the routes. Currently myself, @kenperkins and @jbergstroem can log in to the Rackspace account and get the mailgun API key to make this work.

It's set up so that we can just as easily make an aliases.json for nodejs.org. And at the moment this is a simple 1:1 routing but we can get fancier with mailing lists pretty easily, it's just a matter of extending the update script. security@ would be a logical next addition.

[mikeal]

@rvagg this is fantastic!

[kenperkins]

Glad this was so easy. I noticed that https://github.com/1lobby/mailgun-js doesn't have route API support. I'll throw a PR on that library in my spare time ;)

[Morgul]

Definitely +1 mailgun; I've used them for some forum notifications before, and I really like them. (Plus, it sounds pretty easy to setup.)

[jbergstroem]

@mikeal why close? did something happen?

[mikeal]

This is pretty old and we have new issues elsewhere discussing what to do about email hosting of node.js.

[jbergstroem]

gotcha, thanks for the update.