search

hyphacoop / organizing

Coordination and documents for our member and board meetings 📑 🌴
https://meetings.hypha.coop
11 stars 7 forks source link

Email address policy #131

Closed benhylau closed 4 years ago

benhylau commented 5 years ago

Shared Description

:speaking_head: Loomio: https://loomio.hypha.coop/d/6MDv8TWd/tool-talk-email
:date: Due date: April 27, 2020 :dart: Success criteria: Have guidelines as to how to use our hypha.coop email addresses and every member is clear on how to use them

To Do

Related examples and links:

benhylau commented 5 years ago

@ASoTNetworks @patcon I see you guys are discussing on loomio about this. I want to raise that I am blocked on this because I'd like to sign up for TransferWise and QuickBooks with the appropriate email. Can we at lease decide on and set up finance@ for me to move forward?

ASoTNetworks commented 5 years ago

I am fine with finance@ that.

YurkoWasHere commented 5 years ago

Should software and services be linked to the INFRA account?

But for the sake of unblocking, i say lets create finance@ we can (probably) change it later

patcon commented 5 years ago

Again, as i understand, there is no block here. No one should be blocked: use members@.

If people disagree, pls clarify. If there's a block, we can just poof one immediately and make a real decision on our email namepacing after

benhylau commented 5 years ago

I would prefer to use finance@ for TransferWise and QuickBooks. Can @ASoTNetworks please create that for me as a distribution list and distribute to members of @hyphacoop/finance-wg?

@patcon I would prefer that the separation be made now and there is not future confusion that some emails from these platforms end up in one email vs. another, especially if the email gets listed on bills send to clients. It is not always easy to swap out these emails once they have gone out to the wild.

patcon commented 5 years ago

It is not always easy to swap out these emails once they have gone out to the wild.

I hear ya. But would rather quickly deal with that. Docs like this could make it easy: https://docs.google.com/spreadsheets/d/1D27I7edzwpDMpw8R0XIrgz-u_O6kyCRGl8cbmG7x1IE/edit?usp=drivesdk

But +1 on finance@ going to WG. Maybe finance.wg@ so we have an explicit WG style format to indicate that sorta address (e.g. infra@ currently exists and doesn't go to that WG)

benhylau commented 4 years ago

I would +1 on WG-specific email addresses and use the same text as the name of the GitHub Team. I want to propose aligning:

You can see them here.

I think the slight misalignment will lead to huge overhead over time and propose we choose one format and change everything to it. I know that once we change the GitHub Team name, previous messages that @mention will no longer filter properly, whereas labels are easy to change names. So my proposal is to do:

Do the same for each working group, and forward each to member emails according to their GitHub Team membership. I hope this can happen asap so I can use the proper email to set up financial and accounting services.

patcon commented 4 years ago

I've created alias for finance@hypha.coop => members@hypha.coop at your request Ben.

Your policy suggestions can be taken into account, but you're no longer blocked. Does that work?

patcon commented 4 years ago

Ok, created some demo aliases in mailcow to show how the below could work. Didn't change any existing aliases, so "reverting" is as simple as a bulk delete. My proposal should be clearer if you log in and explore, so pls don't worry so much about wrangling with the text below.

cc: @hyphacoop/infra-ops-wg

Here's my proposal:

For later consideration, I might even suggest we create an internal alias per platform we sign up for (e.g., platform.freephonline@hypha.coop), so any rejigging of things is always done in Mailcow via aliases, not within platforms itself. But happy to save that for later.

EDIT: :bulb: For cleaner mailcow interface (which alpha sorts, might suggest prefixing these groups with a type: group.some-wg, user.patcon etc

patcon commented 4 years ago

From our 2019-11-19 Infra & Ops meeting, there was some feedback on the above proposal:

Adding new todos above.

patcon commented 4 years ago

Will present at next WG meeting. No need to spend substantial time on this until then, though comments welcome :)

Revised Proposal

Demo: See mailcow interface. Screenshot:

Screen Shot 2019-11-26 at 1 37 23 PM

Working sample route that sends to https://www.mailinator.com/v3/index.jsp?query=testing-hypha-123

platform.demo@hypha.coop > group.testing@hypha.local > user.testing@hypha.local > testing-hypha-123@mailinator.com
benhylau commented 4 years ago

I am not in the WG but what @patcon suggested sounds reasonable to me, although I don't know enough about email routing to comment on whether this presents any technical complexity that I am not seeing.

RE: personal email accounts in the format user.GITHUB_USERNAME@hypha.local:

  1. I wonder if we want to make these hypha.coop addresses, instead of using forwarders, so if we end up in a thread with external parties, we can reply with personal coop emails (I am fine either way, just wanted the clarification)

    I am thinking if someone emails a project.something@hypha.coop (are there project lists too?) then ben replies with gmail and pat replies with protonmail, it may be confusing who's even hypha :)

  2. I wonder if we can drop the user. and directly use GITHUB_USERNAME@ for simplicity, since groups and platforms (and perhaps projects) have x.

patcon commented 4 years ago

I wonder if we want to make these hypha.coop addresses, instead of using forwarders, so if we end up in a thread with external parties

Good point. Thanks! I feel like external emails would work well along with this proposed "internal routing" strategy. The internal user email would just be "permanent", like a machine name. So an external email alias like patrick.connolly@hypha.coop would point to user.patcon@hypha.local, which would point to patrick.c.connolly@gmail.com (or some future email address that I consider my primary). Any internal group email aliases (like infra@ or finance@ or members@ or platform.whatever@hypha.coop), they all point to user.patcon@hypha.local, which will be the same no matter what my personal email or external hypha email is.

Does that make sense?

I am thinking if someone emails a project.something@hypha.coop (are there project lists too?)

Not opposed, if you feel a need. Would you like that added to the proposal?

I wonder if we can drop the user. and directly use GITHUB_USERNAME@ for simplicity, since groups and platforms (and perhaps projects) have x.

We could. The prefixes admittedly do make things look less crazy in the mailcow interface, which alpha sorts. If no objection, I'd keep it just to create sanity/clarity in there. Feeling mild preference for a clear convention that all internal aliases get a prefix. I think this rationale might feel more self-evident when looking at an interface with dozens of them :)

patcon commented 4 years ago

Unrelated: Initiated convos in infra chat room about individual email aliases for hypha.coop. I hope to be seeking feedback from everyone on that soon.

Regardless, feel free to leave any thoughts or preferences here, related to individual external hypha.coop emails

patcon commented 4 years ago
benhylau commented 4 years ago

I think user.USERNAME@hypha.local is fine as long as they are kept internal. The external addresses with hypha.coop should be just USERNAME@hypha.local.

I think each person should only have one hypha.coop personal email, more just creates confusion.

I'd prefer to match GitHub handles, but not necessary if people feel it's too restrictive.

I'd like a way to mail out from personal hypha.coop email address. The From from my emails should come from benhylau [at] hypha.coop, so it's clear @benhylau sent it and that I am a hypha.coop member.

I understand the desire of not wanting to host mailboxes, and not requiring members to add another mailbox. If clients have requirements as to how we manage emails, this makes things more confusing, but I don't foresee this being an issue at our stage and with internal routing, we can easily adapt, so I'm not worried about it now. My question now is, can we send from benhylau [at] hypha.coop when it is configured just as a forwarder?

YurkoWasHere commented 4 years ago

I'd prefer to match GitHub handles, but not necessary if people feel it's too restrictive.

I would prefer it to be first@hypha.coop but i do see the logic in handles to to keep things smooth. So maybe first@hypha.coop + github-handle@hyph.coop as an alias to it?

My question now is, can we send from benhylau [at] hypha.coop when it is configured just as a forwarder?

This is a mix of EMAIL CLIENT + TARGET SYSTEM scenario

:heavy_check_mark: SMTP will allow you to send emails on behalf of a foreign mailbox. :x: SPAM FILTERS on the target mailbox will MOST LIKELY flag those as spam :( as they are coming from an unauthorized source

:heavy_check_mark: You can setup a forwarder and use the webclient when you need to send @hypha.coop emails :x: ITs cumbersome as you need to login to a webmail to send out the email :(

:heavy_check_mark: You can configure your mail client to use the "official" SMTP server :thought_balloon: Some mail clients MAY be smart enough to pick the right source reply to email address (ie gmail will) but others may not.

Understand the desire of not wanting to host mailboxes, and not requiring members to add another mailbox.

:x: To sync properly across Clients mail has to remain on the server that means storage space + backups etc etc :heavy_check_mark: Hosting a mailbox is the "catch all" to allow all the solutions: :heavy_check_mark: It can be access through a local client, or through a web interface or as a forwarder

Limiting Liability

Perhaps to early to worry about this now but ill flag it anyway as it has come up recently at my place of work.

Providing "corporate resources" is a means to make sure that not only to make sure everyone has the resources they need to do their job but that the company's interests are protected. It also releases employees from having to adhere to strict requirements on their personal resources but forces them to do so for corporate ones.

Some examples of possible issues:

patcon commented 4 years ago

Personal Email Address

Adapted from my Loomio comment

These are my preferences for hypha.coop personal email aliases :)

patcon commented 4 years ago

My question now is, can we send from benhylau [at] hypha.coop when it is configured just as a [alias/]forwarder?

@benhylau I wrestled with this yesterday, with infra WG support. For gmail, answer on this stackexchange: No, not possible with Gmail anymore. Possible elsewhere,but usually advanced tier pricing is where feature enter that keep you out of spam filters (fastmail, protonmail, gsuite).

With mailbox approach, I got a minimal demo of patcon@hypha.coop working, using instructions in this technical document, with outgoing/incoming working from gmail. https://github.com/hyphacoop/organizing-private/pull/10/files

patcon commented 4 years ago

paraphrased @YurkoWasHere, migrated from loomio comment:

  • :heart: I'm not a fan of yet another mailbox (IMAP/POP3 hook in) in my email client
  • :mag: Hosting email mailboxes requires lots of storage
  • :mag: Forwarders/aliases don't work for outgoing, as recipients spam-mitigation makes it unreliable
  • :mag: Loose naming policy helps eliminate predictive spam
  • :heart: too many aliases, may create chaos during turnover offboarding
  • :heart: mailboxes have lots of pro's and con's
  • :bulb: let's have a convo
patcon commented 4 years ago

Open question: :bulb: would we consider using a third-party service for sending email? could we start with our own mailboxes, but agree that we use another service at the first sign of trouble? would this prevent us from managing our group forwarders together?

:mag: I have a demo inbox that seems to work. :heart: I feel like I don't know what i don't know about how much time maintenance/troubleshooting might take later. :heart: I feel like relying on another co-op could be a good practice.

Potential Email Hosters

benhylau commented 4 years ago

Based on above discussion, what if hypothetically Hypha infra offers:

  1. Email forwarding to an address that the Member provides (e.g. @benhylau wants it go to his gmail)
  2. Internal routing so @benhylau receives emails to all groups that he is in
  3. A Hypha SMTP server to send from benhylau [at] hypha.coop (e.g. @benhylau can use this with Gmail as @patcon did, or use another service that supports this feature)

Note that Hypha does not provide a mailbox. What mailbox service to use, Gmail or some paid service, is left as an individual choice by the Member.

If I understand above conversation correctly, this allows any member to get emails routed / forwarded to their existing mailbox, and if they like to use the SMTP server with their mailbox provider that supports it can also send from the hypha.coop email address. I also assume this will not add a lot of infra overhead to Infra WG, or trigger some sort of spam detection that makes our emails unreliable.

Thoughts?

patcon commented 4 years ago

I like the spirit of your suggestion ben. In practice, might need to do it slightly differently due to how Mailcow works. (I assume we're using Mailcow.)

Please do confirm that I've got this right on wrong, @ASoTNetworks:

In mailcow, a mailbox is a must. It's what creates the POP3 and SMTP. A mailbox gets created, but we can choose to never care about it nor depend on data stored there from incoming/outgoing email. We can just plan to use the SMTP for outgoing only. (My prior suggestion was even to expunge the mailbox(es) nightly :information_source:, so no one mistakenly decides to depend on them. @YurkoWasHere and @ASoTNetworks advised against that, though I don't understand why.)

Also, found this doc and realized that we could perhaps just keep one organizational SMTP account, and create an alias for each personal email to send from. So, for example, we could create a single mailbox of smtp@hypha.coop as the shared user. Within mailcow, we'd then create an alias for each personal email we want to send as, e.g., patcon [at] hypha.coop and benhylau [at] hypha.coop, and point each one to smtp@hypha.coop. This would tell mailcow that these are aliases, and would let us send from them.

And then we'd each set up email like so:

Screenshot at 21-38-47 Screenshot at 21-39-23

Could perhaps even set up mailbox as smtp@hypha.local, and so no one would ever be able to send directly to it ;) Though I suspect that the mailbox's hypha.local domain differing from the aliased hypha.coop domain, miiiiight raise flags. I'll let the experts speak to that.

benhylau commented 4 years ago

What @patcon wrote seems to also satisfy my [puts on user hat] expectations from a functional perspective.

I generally like to have infra that prevents people from messing up (such as what @patcon said about using .local or have a purge job, to prevent accidentally relying on the hosted mailbox). Though I really have no experience managing emails and would leave these implementations to @hyphacoop/infra-ops-wg to decide.

dcwalk commented 4 years ago

I don't want to blow up the amount of care that has gone into this conversation, but at first read it seems overly complex and potentially creating another desire line/flow for group discussions over email if the intent is to use loomio and github for conversations. It seems like we could have gone with an mvp to our immediate need but now need to see through a policy given the time toward this.

My brief thoughts:

:heart: I feel like there isn't a strong understanding/comment here about maintenance/troubleshooting, I'm not sure self-hosting/managing is a valuable use of our time as a result :heart: I feel, based on previous experience, that setting up a mailbox will minimize future troubleshooting. I have had to deal with a lot of fighting spam filters in the past and I see this on our horizon given the current solutions pitched :heart: I think using another co-op would be a good practice and is inline with our values :heart: I have a slight preference for a separate mailbox to not pollute my other namespaces

My use case:

patcon commented 4 years ago

I'm not sure self-hosting/managing is a valuable use of our time

:100: same concern.

:100: on using another co-op before hosting our own. but also not in a rush to start paying yet.

slight preference for a separate mailbox

can you clarify? by this, you mean POP3 mailbox of your own to pull from? (I'm not sure I understand your overall preference.)

It should be noted that infra WG earlier today discussed reaching out to the UK's Web Architects in relation to hosting infra with them.

ASoTNetworks commented 4 years ago

I wonder if we are over thinking / over complicating the issue.

What if we make emais for all of the membes with firstname@hypha.coop and let the mailbox owner decide what to do with it eg: have it setup in gmail, in your own client ect. Mailboxes doesn't take a lot of space to host and it is easy to move data off later using IMAP if you are using the current mailcow as your mail store.

For my clients I hardly touch their email accounts as changes only occurs when someone joins the org or leaves so making admin over head very low.

As for our forwarder it is nice to have a sapperate email for each service but in the end will make us spent lots of time configuring the forwarder for those different emails.

As for using code to manage our emails I am not a fan of because it adds another layer of complexity to something that works fine.

Also in mailcow we can share contact list and calendar too to make use of its functionality.

ASoTNetworks commented 4 years ago

Also instead of all the @hypha.local routing we can have <wg>@hypha.coop forward to our personal firstname@hypha.coop.

I know there would be some duplication of people in the forwarder but it would be easier to manage than looking at how the mail routes through @hypha.local to edit just one forwarder and less chance of something breaking.

benhylau commented 4 years ago

There was a huge discussion above, but it seems we have already converged into a configuration and practice. I think what remains is to document our current practice and close this off, then if new needs come up in the future we can discuss a revision to current practice.

Some of the current practice I observe are;

Anything else?

benhylau commented 4 years ago

We currently use @ASoTNetworks's infra as third-party email provider, we should capture that in our inventory.

ASoTNetworks commented 4 years ago

All these assigned to @ASoTNetworks

ASoTNetworks commented 4 years ago

finally done