In T41785#3567033, @Legoktm wrote:

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.

In T41785#3567268, @bd808 wrote:

In T41785#3567033, @Legoktm wrote:

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.

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.

In T47828#7203503, @taavi wrote:

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?

I don't think that adding specialty forwards at the Developer account level is necessary. We could add support for <account>+<arbitrary suffix>@wmcloud.org style subaddressing fairly easily via local_part_suffix config in exim.

When poking at T347512: Some emails from The Wikipedia Library aren't being received as expected I realized that we will probably also need to create SPF records for each <project>.wmcloud.org subdomain if we go with the subdomain per-project option or folks will end up surprised when they try to send mail with their <something>@<project>.wmcloud.org addresses as the envelope From.