Can 'incoming_email_email' check folders:? (Rackspace)

I am trying to implement Service Desk functionality in GITLAB and technically everything works correctly. My issue is that my email provider (rackspace) processes sub-addressing differently than any other provider I have tested. My google and microsoft email addresses just have the incoming email go into the inbox with the +{tag} there and ignored. For rackspace it creates subfolder in the inbox for the +{tag}. For example if I send an email to, rackspace will create a folder inbox\test and put the email in it. Then when GITLAB runs and checks inbox it says there are no emails because the email is in inbox\test. So like the title suggests, can I configure GITLAB to check the folders created by +{tag} in my inbox, instead of just the inbox.

If rackspace mail server does not support extended mail addresses then it would need to be without the additional part.

Unfortunately not all mail servers support it. The downside in such instance means requiring multiple email addresses for each separate integration rather than one single mailbox with the extended addressing eg +test1 +test2 etc etc.

1 Like

Thank you for your reply. I hadn’t thought of going that route.

The rackspace mail server does support extended email addresses, it just handles them differently than expected. With GITLAB setup using the default settings for incoming email and service desk enabled on my projects,

I can send an email to each created servicedesk enabled project I.E. and When I do this, looking at the incoming mailroom log, there are no new messages. Looking in rackspace at The inbox is empty however, there are two new folders 1. IT-project1-1-issues- and 2. IT-project2-2-issues- . Inside these two new folders are all the emails I sent to their respective service desks.

If I take the emails in the folders and move them out of the folders and up a level to inbox, the mailroom log then says “Getting new messages, unread, count x”. Looking in GITLAB the respective projects now have new issues in service desk as expected.

I contacted rackspace and, while extremely helpful, their customer service was not very knowledgeable. Ultimately there is no documentation nor settings that can manipulated to affect this behavior for extended addresses. If I could configure GITLAB to look in the folder that gets created for new emails that would solve my issue. Otherwise I’ll have to go the route you suggested and create an alias or new email for each project hich would, needless to say, rapidly get annoying and unwieldy.

What I found in the docs for the IMAP side:

  mailbox: "inbox/test"

and maybe this in gitlab.rb as well:

gitlab_rails['service_desk_email_mailbox_name'] = "inbox/test"

all I found in the docs for custom email: Service Desk | GitLab

That’s the only other thing I can think of that might allow it to work.

Aliases to the same mailbox won’t work, otherwise every single account will get the same email/issue, etc. They would have to all be individual email addresses with physical mailboxes. The only way to do it is with the extended addressing to the same mailbox. So hopefully those config options I gave might help from the docs.

1 Like

Thank you for your reply,
I had tried inbox+{tag} ← just like that and it didn’t work. I’ll try explicitly putting the tag in there and see if it will work.

In case it does, might it be possible to configure multiple service_desk_email_mailbox_name I wonder. Probably not as that pretty much bypasses the configuration of the extended email address I would think. I’ll test and reply.

I was able to configure GITLAB so that it now looks in the explicit folder for the project.

Given an expanded email → as seen in project > general > servicedesk
gitlab.rb configuration changed to
→ gitlab_rails[‘service_desk_email_address’] = "servicedesk+%{key}
→ gitlab_rails[‘service_desk_email’] = “
→ gitlab_rails[‘service_desk_email_mailbox_name’] = “IT-project1-1-issue-”

Follow up question , can I add another gitlab_rails[‘service_desk_email_mailbox_name’] = “IT-project2-2-issue-” for example and have it look in 2 mailboxes?

For the gitlab-rails configuration, rather not. The only things that seem to be able to configured differently, are at the project level. For gitlab.rb there isn’t any option for it. Would have been nice for example service_desk_email_mailbox_name1 and service-desk_email_mailbox_name2 as config options, then it would have been possible. But nothing like that exists.

I expect just setting that gitlab_rails mailbox_name to inbox doesn’t work as you probably had it configured that way before. So not really sure how you would be able to do that. Ideally it would have been nice for all the email just to end up in the main inbox rather than a sub-folder and just use extended addressing. That way gitlab.rb would just have config for the main inbox, and then you would be able to have multiple extended addresses work properly.

Perhaps rackspace can configure it to deliver directly to the inbox instead of a subfolder. But I expect that won’t be an option available to you unless that you can custom choose where you want extended email addresses to deliver, sub folder vs main inbox.

1 Like

Have you considered simply setting up a rule in the mailbox to move all e-mail into the inbox?

I’m not sure if i’ve missed anything or if that will work- but I think it might…

I tried re-direct and moves but unfortunately, rackspace doesn’t allow you to forward email to yourself from yourself and since technically all the extended addresses are the same email address it really didn’t like that.

I would expect move to work (e.g. just moving it to a different folder not to a different mailbox?

I tested manually dragging the new email from the new folder to the inbox and that worked however, rackspaces’ UI doesn’t have a way to programatically just move everything. I suppose I could try using thunderbird rules to move everything in every folder back to the inbox and see if that would work. I could just set up the servicedesk email as an identity and have it running in the background.

Follow up - Everthing works fine for initial contact with the way I had set it up unfortunately GitLab then sends a response with a different extended email reply to which when responded to creates yet a different folder in the inbox which is then not checked.

Long story short, I am configuring GitLab back to inbox and writing a service that will log into the email and move everything in folders back to the inbox and delete the folders.