Page MenuHomePhabricator

Outgoing mail for Gitlab
Closed, ResolvedPublic

Description

How to send mail from gitlab - Involves Keith from Observability

Event Timeline

gitlab1001 has the standard exim mail package installed, so local e-mail works already. What does Gitlab need?

On gitlab-test, we're using:

gitlab_rails['smtp_address'] = "mail.tools.wmflabs.org"

So just an SMTP server seems to be sufficient for sending notifications to users. It looks like for incoming mail, we'll need an IMAP box. From the GitLab docs on incoming email:

Handling incoming emails requires an IMAP-enabled email account. GitLab requires one of the following three strategies:

  • Email sub-addressing (recommended)
  • Catch-all mailbox
  • Dedicated email address (supports Reply by Email only)

I'm not sure offhand how Gerrit handles this, but it looks like it uses gerrit@wikimedia.org. Presumably gitlab@wikimedia.org would be the right thing to do.

cc: @herron per @wkandek's original description of this task.

gerrit@wikimedia.org isn't an IMAP account, it is just a blackhole:

[mx1001:~] $ sudo exim4 -bt gerrit@wikimedia.org
mail to gerrit@wikimedia.org is discarded

I am not aware of any incoming mail feature with Gerrit.

If you really need a IMAP account you'll have to ask ITS (OIT) via Zendesk.

For the case of sending mail from gitlab outwards in production, I'd suggest using local exim instance on the gitlab hosts themselves (in other words, setting the gitlab smtp server to localhost in the prod environment). This will provide mail queueing and failover between the production outbound MXes and should be much more worry-free than if gitlab were to connect directly to a single MX.

Is the incoming mail feature in gitlab mostly for supporting the gitlab issue tracking type features? In any event since the gitlab VM has a public IP already it should be fairly straightforward to connect to a google apps inbox via IMAP once an account has been created for that in the way Daniel outlined.

A reply mail feature / incoming mail for Gerrit was requested by @Paladox in T158915 in 2017 but declined by @hashar in T158915#6806969. Then @Aklapper said in T158915#6808346 that some users _do_ comment by email but I don't know how that's possible. I think he meant "in general" some people like email.

I am not aware of any incoming mail feature with Gerrit.

Ah, I had the idea I'd used this in the past to respond to review threads, but I guess I always just vaguely assumed it was possible.

Is the incoming mail feature in gitlab mostly for supporting the gitlab issue tracking type features? In any event since the gitlab VM has a public IP already it should be fairly straightforward to connect to a google apps inbox via IMAP once an account has been created for that in the way Daniel outlined.

I think in practice it's for responding to review / merge request comments, though there may be other features. (For what it's worth, we're not planning on using the GitLab issue tracking to speak of.)

As @herron stated above, that comes in the form of a local exim server and the application emitting to localhost. The beauty of this system is that it is a one time configuration on the application side, the rest of the email routing is managed in bulk by SRE. That makes the stack simpler for everyone.

Our Gerrit is not configured for email based reviews (conf is https://gerrit.wikimedia.org/r/Documentation/config-gerrit.html#receiveemail ). I have rejected the task cause that sounds like a rather small use case (I might be wrong) and I try to dismiss adding new features which would potentially have a small user base. Phabricator does support incoming emails, and surely if that is actively used we can look at enabling the feature in Gerrit (and then I guess Gitlab). But that is a side track unrelated to adding Gitlab outgoing email based notifications.

I would recommend on just setting up the basic outgoing support for now. That sounds super easy to do (add puppet class for exim, config gitlab to use localhost as smtp server, done). Support for incoming email sounds like a feature that is slightly less trivial and does not sound like a blocker for the initial deployment. As such, that can certainly be delayed and be filed as another task to be implemented later.

Then, I am not the project manager for the gitlab initialization. I am just assuming we want a Gitlab instance with the core features as soon as possible and slicing any extra features would make it faster to deliver.

Then @Aklapper said in T158915#6808346 that some users _do_ comment by email but I don't know how that's possible.

Ah, I referred to using/interacting with Phabricator tickets via email; my comment didn't refer to Gerrit.

That sounds super easy to do (add puppet class for exim

Nothing at all needs to be done. This is included in base classes.

Support for incoming email sounds like a feature that is slightly less trivial and does not sound like a blocker for the initial deployment. As such, that can certainly be delayed and be filed as another task to be implemented later.
Then, I am not the project manager for the gitlab initialization. I am just assuming we want a Gitlab instance with the core features as soon as possible and slicing any extra features would make it faster to deliver.

+1

Gitlab outbound mail configuration is done:

https://gerrit.wikimedia.org/r/plugins/gitiles/operations/gitlab-ansible/+/refs/heads/master/roles/gitlab_server/defaults/main.yml
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/gitlab-ansible/+/refs/heads/master/roles/gitlab_server/templates/gitlab.rb.j2

Meaningful configuration being this:

Email configuration.

gitlab_email_enabled: "true"
gitlab_email_from: "gitlab@{{ gitlab_domain }}"
gitlab_email_display_name: "Gitlab"
gitlab_email_reply_to: "gitlab@{{ gitlab_domain }}"

Pretty straigthforward, but please review, thanks.

Pretty straigthforward, but please review, thanks.

LGTM thanks

brennen renamed this task from Mail for Gitlab to Outgoing mail for Gitlab.Jun 14 2021, 11:36 PM
brennen closed this task as Resolved.