Catch Email Address does not work when sent to a "named" recipient Edited

We have an inbox setup to accept email tickets from staff and external users. We need to support two products so we have setup an alias on the inbox to support the second product.

Product 1: (primary)
Product 2: (alias)

We use two JIRA mail handlers and the Catch Email Address feature to divert the issue to the correct product. This alias works great when the email is sent from an external user (not provisioned in our Exchange). However, we have noticed this does not work when sent from internal staff. I have been investigating the behavior and I believe I have found the problem. 

When the email is sent from an external address, the resulting headers of the email that JIRA reads is

To: "" <>

However, when sent from internal staff, the header changes to.

To: Issues <>

When I test the mail handler, I get the following error for the email sent by internal staff.

Cannot handle message as the recipient(s) ( do not match the catch email

This seems like a bug to me.
1. You can clearly see is listed in the header of both emails.
2. Why is listed as a recipient. It is the username on the POP account but nowhere within the headers of the email in question. 





2 answers

0 votes

I know there is an existing feature request to improve the logging in regards to the catch email address in Jira   I would agree that there should probably be some more improvements in regards to the way Jira logs this info.

It appears that this INFO level message can be thrown for each recipient in the to, cc, bcc fields of the processed message.


However if the logs in Jira are stating that the recipient is actually the domain on product 1, but the headers of the message all show product 2 domains, I could see how this would happen when the message is actually be taken from mailbox #1.  And given that you mentioned the pop login appears to be this other domain #1 account, that likely explains why Jira is rejecting this as an invalid recipient when compared to the catch address #2.   The fact that exchange is using these as aliases is confusing mail in regards to where this message exists.  

The mail handler documentation might not make this as clear as it should be, but so far with the information at hand, I'm not convinced this is actually a bug in the mail handler.  

Perhaps it would be better to use the default reporter option instead of this catch email address in order to be able to create new issues from all users instead.

Here is the text that appears beneath the Catch Email Address field.

If set, only emails having the specified recipient in fields To, Cc or Bcc will be processed.

Any logical person reading that would think the following.

"If I leave the Catch Email Address field blank, all email will be processed as issues. Otherwise, I can provide a specific email address to process."

The username on the POP account shouldn't matter here.

In my first post, you can see my Catch Email Address appeared in the To field of both email, character for character. However, only the email that had it appear inside double quotes (i.e. "") was processed successfully. I am not reporting this feature does not work, I am reporting this feature only works some of the time. It is like the mail handler code is specifically searching for a quoted version of the Catch Email Address somewhere in To, Cc, Bcc. But based on my observations, addresses do not always appear in a quoted form (at least not when the address represents a named recipient) within the email headers. 

Please have someone technical review the code in question and my posts. There is definitely something wrong with the underlying logic given the description/documentation for this feature.  

If you still do not think this is a bug, answer the following. Why should a mail handler with catch email address behave differently for the following To values?

1 - To: "" <>
2 - To: Issues <>

Makes no sense why it would work for (1) but not for (2).

Hi Chris,

Your Exchange instance is behaving differently for internal mail vs external mail.    Your internal messages are not leaving this mail server at all likely.  Instead when someone within the internal organization sends a message to that address, Exchange already knows who that alias belongs to and in turn since it knows who "Issues" is, it instead selects the primary account mailbox instead of the alias.  External users don't have the ability to do this kind of address lookup.

You can also see from this spiceworks post that other users have noted the same behavior completely unrelated to Jira: Spiceworks: emails sent internally to alias address doesn't have proper To: address

As such, I would recommend the same solution that Alan does in that post; instead of using a mailbox Alias, setup a distribution list with just a single recipient.   This way even internal users would still have their messages sending to the correct address without Outlook/Exchange short-circuiting this process by doing this internal account lookup.


Hi Andy,

What you describe and linked from Spiceworks is not the behavior I am seeing. I am looking at headers on the received mail processed by JIRA and my headers show the correct email recipient in all cases. The problem is the address format may change (see RFC 5322), and it seems JIRA's mail handler only processes one format.

Here is the scenario again. Two different emails with the following To headers. 

1 - To: "" <>
2 - To: Issues <>

You can see they both have the correct recipient. My question again. Why does JIRA's mail handler configured for works only for (1) and not (2).

Unless you can answer that question we not going to solve anything.

I suspect JIRA's mail handler implementation does not respect RFC 5322 and specifically section 3.4 which defines the address specification in email headers. From that...

Normally, a mailbox is composed of two parts: (1) an optional display name that indicates the name of the recipient (which can be a person or a system) that could be displayed to the user of a mail application, and (2) an addr-spec address enclosed in angle brackets ("<" and ">"). There is an alternate simple form of a mailbox where the addr-spec address appears alone, without the recipient's name or the angle brackets.

You guys have coded your mail handlers to look for the Catch Email Address in the optional "display name" part of the address spec and not the required addr-spec section enclosed in angle brackets.

Now that I have laid this out can we get it fixed?


Hi Chris,

I have created a ticket for you and you should receive an email shortly.  We're going to need full email headers to figure out why you're getting the following message:

Cannot handle message as the recipient(s) ( do not match the catch email

On our end we're going to need to figure out how JIRA is handling the email address and on your end you're going to need to figure out why this is coming from and throwing that error since JIRA does not determine where the email is coming from so we can work with you to figure out if Exchange may be manipulating the headers in some manner which makes JIRA think the messages should go to thus providing the error that the recipient does not match the catch all email address.



Thanks Branden,

I will provide the information you are looking for in the ticket you created.


0 votes

Hi Chris,

I have been notified that the issue has been resolved on the support side and I wanted to recap so hopefully others can benefit from the proposed solution as well:

You noticed a problem in the previous POP3 test. It appears the test was done with an email sent externally. When the attempt was made with an internal email you were able to determine the headers received by a POP3 client were in fact different.

Hopefully all is well at this point as the issue has been closed.  If you're set, go ahead and accept this answer or Andy's initial answer so others can benefit when searching the community.



Hi Branden,

Your summary is correct.

I would suggest keeping this ticket open a little longer. I am working with support on the Microsoft side to investigate this odd behavior. Still working though it with them. 

I will post back as that investigation progresses.

Thanks for letting us know and let us know when you have an update!

One other thing Branden,

If you have another customer report this, the Spiceworks link reports the issue but incorrectly describes the behavior in the "Best Answer".

From Spiceworks:
Outlook will do a lookup when you send a mail to find out which "account" the alias belongs to.  The mail will then be sent to that "account", rather than the email address they enter.

That is not what I see. In my testing, Outlook always shows the correct recipient - it is always what is specified by the sender (alias or primary / external or internal). So clearly within the mail server the right recipient is recorded. If there is a lookup, it doesn't happen at the time the email is sent (as Spiceworks best answer indicates), but rather when the POP3 client retrieves the email. This is why I did not accept your previous answers. Once I interacted with the mail server at the POP protocol level and saw the behavior myself, I was able follow what you guys had been telling me. 

So this seems to me to be a problem with how Exchange supports POP3 clients. My guess is they do things differently for POP3 vs. EAS/MAPI/etc.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Mar 05, 2018 in Jira Software

Jack Graves: Real Ale enthusiast with a knack for Jira Software implementation

@Jack Graves [AC] first caught our eye with his incredible breakdown of what, in his opinion, can make or break a Jira software implementation. (Read his thoughts on this thread)! In this follow...

96,845 views 4 14
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you