Summary: headers in GitLab email notifications are changing, you may need to update your email filters
# Background
I am working on building a development server for GitLab, where we can go wild testing things without breaking the production environment. For email to work there, I need a configuration that is separate from the current production server.
Unfortunately, the email address used by the production GitLab server doesn't include the hostname of the server (`gitlab.torproject.org`) and only the main domain name (`torproject.org`) which makes it needlessly difficult to add new configurations.
Finally, using the full service name (`gitlab.torproject.org`) address means that the GitLab server will be able to keep operating email services even if the main email service goes down.
# Proposal
This changes the headers:
From: gitlab@torproject.org Reply-To: gitlab-incoming+%{key}@torproject.org
to:
From: git@gitlab.torproject.org Reply-To: git+%{key}@gitlab.torproject.org
If you are using the `From` headers in your email client filters, for example to send all GitLab email into a separate mailbox, you WILL need to make a change for that filter to work again. I know I had to make such a change, which was simply to replace `gitlab@torproject.org` by `git@gitlab.torproject.org` in my filter.
The `Reply-To` change should not have a real impact. I suspected emails sent before the change might not deliver properly, but I tested this, and both the old emails and the new ones work correctly, so that change should be transparent to everyone.
(The reason for that is that the previous `gitlab-incoming@torproject.org` address is *still* forwarding to `git@torproject.org` so that will work for the foreseeable future.)
# Alternatives considered
## Reusing the prod email address
The main reason I implemented this change is that I want to have a GitLab development server, as mentioned in the background. But more specifically, we don't want the prod and dev servers to share email addresses, because then people could easily get confused as to where a notification is coming from. Even worse, a notification from the dev server could yield a reply that would end up in the prod server.
## Adding a new top-level address
So, clearly, we need two different email addresses. But why change the *current* email address instead of just adding a new one? That's trickier. One reason is that I didn't want to add a new alias on the top-level `torproject.org` domain. Furthermore, the old configuration (using `torproject.org`) is officially [discouraged upstream][] as it can lead to some security issues.
[discouraged upstream]: https://docs.gitlab.com/ee/administration/incoming_email.html#security-conce...
# Costs
N/A, staff.
# Approval
This needs approval from TPA and tor-internal.
# Deadline
This will be considered approved tomorrow (2022-06-30) at 16:00 UTC unless there are any objections, in which case it will be rolled back for further discussion.
The reason there is such a tight deadline is that I want to get the development server up and running for the Hackweek. It is proving less and less likely that the server will actually be *usable* *during* the Hackweek, but if we can get the server up as a result of the Hackweek, it will already be a good start.
# Status
This proposal is currently in the `proposed` state.
# References
Comments welcome by email or in issue [tpo/tpa/team#40820][].
[tpo/tpa/team#40820]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40820
tor-project@lists.torproject.org