Page MenuHomePhabricator

Implement mail aliases for Cloud-VPS projects (<novaproject>@wmcloud.org)
Open, LowPublic

Description

Project membership information can be pulled from the OpenStack keystone API.

The Toolforge project itself has something like this that routes emails for <tool>@tools.wmflabs.org to the shared tool account where it can be processed using .forward files. That processing is LDAP based, using a lookup script and exim4 configuration.

Possible implementations:

  • *@<project>.wmcloud.org forwards to project admins
  • <project>@<something>.wmcloud.org forwards to project admins
  • <project>-(admins|members)@<something>.wmcloud.org forwards to project admins/members
  • ...

Having some kind of optional per-project address -> destination mapping similar to the Toolforge feature would also be nice, but that is not necessary for an initial implementation.

Ideally this base feature can also be leveraged to fix T61142: root@<labs-instance> should email project admins either directly or indirectly.

Details

Reference
bz45828

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:25 AM
bzimport added a project: Cloud-VPS.
bzimport set Reference to bz45828.
bd808 added subscribers: herron, bd808, Legoktm.

I was actually just asking @bd808 about the status of mail access for Cloud VPS projects yesterday. At least for my use case, it would be great if mail to <something>@<projectname>.wmflabs.org (where something is fixed string(s) or any string) just worked for forwarding to the project members, without any setup required in the individual project.

it would be great if mail to <something>@<projectname>.wmflabs.org (where something is fixed string(s) or any string) just worked for forwarding to the project members, without any setup required in the individual project.

I'd love to see some solution for this too. One potentially tricky step here is that project membership information has been moved out of the LDAP directory and is now completely managed in OpenStack's keystone API. Next tricky step is that <projectname>.wmflabs.org does not exist in DNS by default. This could be handled by the *.wmflabs.org MX record suggested by @herron in T41785#3566374 though. It is possible for projectX to register an HTTP proxy named projectY.wmflabs.org which could complicate/confuse things based on hostname level forwarding. It might be simpler to use addresses like <projectname>@<vps mail relay identifier>.wmflabs.org for the "contact a project's members" use-case. <vps mail relay identifier> could be something like projects or vps.

bd808 renamed this task from Labs: Implement mail aliases for projects (<novaproject>@wmflabs.org) to Implement mail aliases for Cloud-VPS projects (<novaproject>@wmflabs.org).Aug 30 2017, 8:15 PM
bd808 removed a project: Cloud-Services.
bd808 updated the task description. (Show Details)
bd808 renamed this task from Implement mail aliases for Cloud-VPS projects (<novaproject>@wmflabs.org) to Implement mail aliases for Cloud-VPS projects (<novaproject>@wmcloud.org).Oct 20 2020, 5:19 PM
bd808 updated the task description. (Show Details)
Nintendofan885 updated the task description. (Show Details)
Nintendofan885 updated the task description. (Show Details)

Another usecase for this: https://gerrit.wikimedia.org/r/c/operations/puppet/+/675352/1 root@ cronspam, etc. should go to the VPS maintainers, not whomever answers root@wmcloud.org.

I have a use case for this as well (T128715), so I'll work on this at some point unless someone else is faster or explicitely wants to deal with mail server configuration. My plan for this is the following, questions and feedback are appreciated.

  1. Add mail servers in WMCS that deal with incoming mail for WMCS domains. Those will likely exist in the "cloudinfra" project, and be either co-located with the outgoing mail servers (mx-out*) or have their own dedicated servers. Currently wmflabs.org is handled by production mx*.wikimedia.org (and sends some aliases to Andrew only), while wmcloud.org, wikimediacloud.org and wikimedia.cloud have no MX records. This first iteration can be rather simple and do nothing except respond to some important pre-defined addresses (root@, security@, abuse@, so on) by forwarding those to some TBD group of people.
  2. Add support for username@wmcloud.org forwarding, like username@toolforge.org currently forwards to the LDAP-defined address for Toolforge user "username". We can likely adapt the lookup script Toolforge uses and replace "project-tools" with "project-bastion" (which is IMO a suitable check for Cloud VPS access).
    • do we need forwarding config support, like we have with ~/.forward on Toolforge? if so, how?
  3. Finally we add support for project forwards. I'm not exactly sure which form those will take yet, but will likely be implemented as a Exim redirect script that loads the list of project members / admins from LDAP or Keystone and returns them in the form of "shellname1@wmcloud.org, shellname2@wmcloud.org". Exim is smart enough to note those addresses have additional forwarding rules set.