Service Desk seems to ignore "Accepted Headers"

Summary

I want to setup a more human friendly email address (support@example.org) for one of my service desk projects, as the current address (servicedesk+$groupname-$projectname-$projectid-issue-@example.com is a bit unwieldy.

I have setup an IMAP account (servicedesk@example.com), configured a mail forwarding with Postfix, added a header (as described here), and can successfully receive a mail:

# /etc/postfix/virtual_aliases
support@example.org  servicedesk@example.com

# /etc/postfix/recipient_access
support@example.org PREPEND References: servicedesk+group-project-id-issue-@example.com

# /etc/postfix/main.cf (snippets)
smtpd_recipient_restrictions =
	...
	check_recipient_access hash:/etc/postfix/recipient_access
virtual_alias_maps = pcre:/etc/postfix/virtual_aliases

Edit: Using PREPEND References: <servicedesk+group-project-id-issue-@example.com> (i.e. enclose the address in angle brackets) does not change the outcome.

Steps to reproduce

Follow the guide for Incoming Mail.
Setup a similar address for Service Desk.

Send a mail to support@example.com

Message-ID: <11970059-e4da-a146-55be-2c88a59ecaeb@gmail.com>
Date: Wed, 8 Jun 2022 15:26:30 +0200
MIME-Version: 1.0
Content-Language: en-US
To: support@example.com
From: [REDACTED]
Subject: Test
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Service Desk Test

Note: Message-ID, To and From were altered for privacy reasons.

Find the mail in the servicedesk IMAP account:

Return-Path: [REDACTED]
Delivered-To: servicedesk@example.com
References: servicedesk+group-project-id-issue-@example.com
Message-ID: <11970059-e4da-a146-55be-2c88a59ecaeb@gmail.com>
Date: Wed, 8 Jun 2022 15:26:30 +0200
MIME-Version: 1.0
Content-Language: en-US
To: support@example.org
From: [REDACTED]
Subject: Test
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Service Desk Test

Note: Return-Path, Delivered-To, Message-ID, To and From were altered for privacy reasons.

Receive a mail from Gitlab, stating:

Unfortunately, your email message to GitLab could not be processed.

We couldn't figure out what the email is for. Please create your issue or comment through the web interface.

Example Project

What is the current bug behavior?

The documentation on Accepted Headers states:

Email is processed correctly when a configured email address is present in one of the following headers (sorted in the order they are checked):

To

References

Delivered-To

Envelope-To or X-Envelope-To

Received

In GitLab 14.6 and later, Service Desk also checks accepted headers.

However, I found that this is not the case.

What is the expected correct behavior?

Service Desk should behave as documented.

Relevant logs and/or screenshots

Mailroom log show processing of incoming mail:

{"severity":"INFO","time":"2022-06-08T13:26:50.754+00:00","context":{"email":"servicedesk","name":"inbox"},"action":"Processing started"}
{"severity":"INFO","time":"2022-06-08T13:26:50.805+00:00","context":{"email":"servicedesk","name":"inbox"},"uid":6,"action":"asking arbiter to deliver","arbitrator":"MailRoom::Arbitration::Redis"}
{"severity":"INFO","time":"2022-06-08T13:26:50.806+00:00","context":{"email":"servicedesk","name":"inbox"},"action":"Getting new messages","unread":{"count":1,"ids":[6]},"to_be_delivered":{"count":1,"ids":[6]}}
{"severity":"INFO","time":"2022-06-08T13:26:50.814+00:00","context":{"email":"servicedesk","name":"inbox"},"uid":6,"action":"sending to deliverer","deliverer":"MailRoom::Delivery::Sidekiq","byte_size":3208}
{"severity":"INFO","time":"2022-06-08T13:26:50.815+00:00","delivery_method":"Sidekiq","action":"message pushed"}
{"severity":"INFO","time":"2022-06-08T13:26:50.823+00:00","context":{"email":"servicedesk","name":"inbox"},"action":"Processing started"}
{"severity":"INFO","time":"2022-06-08T13:26:50.877+00:00","context":{"email":"servicedesk","name":"inbox"},"action":"Getting new messages","unread":{"count":0,"ids":[]},"to_be_delivered":{"count":0,"ids":[]}}
{"severity":"INFO","time":"2022-06-08T13:26:50.877+00:00","context":{"email":"servicedesk","name":"inbox"},"action":"Idling"}

I could not find the correlating Sidekiq log.

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

System information
System:		Ubuntu 20.04
Current User:	gitlab
Using RVM:	no
Ruby Version:	2.7.5p203
Gem Version:	3.1.4
Bundler Version:2.2.33
Rake Version:	13.0.6
Redis Version:	6.2.6
Sidekiq Version:6.4.0
Go Version:	unknown

GitLab information
Version:	15.0.2
Revision:	c83a8f40f1c
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	12.11
URL:		https://git.example.com
HTTP Clone URL:	https://git.example.com/some-group/some-project.git
SSH Clone URL:	gitlab@git.example.com:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers: 

GitLab Shell
Version:	14.3.0
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell

Note: URLs have been altered.

Results of GitLab application Check

Expand for output related to the GitLab application check

Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 14.3.0 ? ... OK (14.3.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1

Checking Sidekiq ... Finished

Checking Incoming Email ...

Incoming Email: ... Checking Reply by email ...

IMAP server credentials are correct? ... Checking gitlab
Checking servicedesk
yes
Mailroom enabled? ... skipped
MailRoom running? ... skipped

Checking Reply by email ... Finished


Checking Incoming Email ... Finished

Checking LDAP ...

LDAP: ... LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab App ...

Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Projects have namespace: ... 
3/1 ... yes
7/2 ... yes
3/3 ... yes
3/4 ... yes
3/5 ... yes
3/7 ... yes
3/8 ... yes
3/9 ... yes
7/10 ... yes
3/11 ... yes
3/12 ... yes
3/13 ... yes
14/14 ... yes
14/15 ... yes
3/16 ... yes
3/17 ... yes
14/18 ... yes
6/20 ... yes
3/21 ... yes
16/23 ... yes
17/24 ... yes
14/26 ... yes
14/27 ... yes
3/28 ... yes
20/29 ... yes
27/30 ... yes
22/31 ... yes
23/32 ... yes
20/33 ... yes
3/34 ... yes
6/35 ... yes
3/36 ... yes
3/37 ... yes
22/38 ... yes
20/39 ... yes
6/40 ... yes
3/42 ... yes
20/43 ... yes
27/44 ... yes
27/45 ... yes
6/47 ... yes
20/48 ... yes
20/49 ... yes
20/50 ... yes
3/51 ... yes
27/52 ... yes
27/53 ... yes
20/54 ... yes
20/55 ... yes
14/56 ... yes
27/57 ... yes
14/59 ... yes
20/60 ... yes
20/61 ... yes
3/63 ... yes
29/64 ... yes
27/65 ... yes
14/66 ... yes
20/67 ... yes
31/68 ... yes
31/71 ... yes
26/72 ... yes
31/73 ... yes
26/74 ... yes
31/75 ... yes
3/76 ... yes
31/78 ... yes
26/79 ... yes
26/80 ... yes
32/82 ... yes
32/83 ... yes
29/85 ... yes
33/87 ... yes
33/88 ... yes
5/89 ... yes
5/91 ... yes
5/92 ... yes
50/93 ... yes
29/94 ... yes
20/95 ... yes
3/96 ... yes
3/97 ... yes
23/98 ... yes
23/99 ... yes
23/100 ... yes
23/101 ... yes
35/102 ... yes
35/103 ... yes
20/105 ... yes
27/106 ... yes
50/107 ... yes
5/109 ... yes
35/110 ... yes
35/111 ... yes
35/112 ... yes
36/113 ... yes
35/114 ... yes
3/115 ... yes
35/116 ... yes
29/120 ... yes
32/121 ... yes
20/122 ... yes
39/123 ... yes
39/124 ... yes
26/125 ... yes
20/126 ... yes
6/127 ... yes
20/129 ... yes
41/130 ... yes
4/131 ... yes
41/132 ... yes
47/133 ... yes
41/134 ... yes
23/135 ... yes
41/136 ... yes
23/137 ... yes
41/138 ... yes
23/139 ... yes
23/140 ... yes
23/141 ... yes
42/142 ... yes
42/143 ... yes
43/144 ... yes
42/145 ... yes
35/146 ... yes
20/147 ... yes
20/148 ... yes
5/149 ... yes
14/150 ... yes
3/151 ... yes
20/152 ... yes
47/153 ... yes
32/154 ... yes
43/155 ... yes
3/157 ... yes
3/158 ... yes
47/159 ... yes
20/160 ... yes
48/162 ... yes
14/164 ... yes
20/165 ... yes
48/166 ... yes
29/167 ... yes
58/168 ... yes
41/172 ... yes
29/173 ... yes
53/174 ... yes
2/176 ... yes
2/177 ... yes
14/178 ... yes
47/179 ... yes
47/180 ... yes
5/181 ... yes
20/182 ... yes
50/184 ... yes
6/185 ... yes
3/186 ... yes
53/187 ... yes
56/188 ... yes
56/189 ... yes
6/191 ... yes
5/192 ... yes
5/193 ... yes
58/194 ... yes
41/195 ... yes
58/196 ... yes
58/197 ... yes
Redis version >= 5.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.5)
Git user has default SSH configuration? ... yes
Active users: ... 18
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes

Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

~~It would be nice, if I could configure not only a custom email address suffix, but a real alias (such that I wouldn't to inject the real address with /etc/postfix/recipient_access).~~

Update the accepted headers documentation adding under the list of headers:

Note: The References header is specifically used to relate email responses to existing discussion threads and is not used for other purposes, such as creating issues by email.

Edited Jul 19, 2022 by John Hope