Why does having a blank catch email address work?

[kris]

We have a lot of incoming mail server/handlers configured. One of the projects has an old email they are trying to phase out and a new email address. When I put the new address, predictably, only mail sent to that address creates/comments. When I remove the address (so catch email address is blank) both emails create/comment tickets.

Why does this work? How does it know to creates tickets from those emails in the correct project? Would it break if there were another project with a blank catch address (not something I'm going to test)?

[darylchuah · Accepted solution]

The purpose of catch email address is to allow JIRA to recognize the parameter that is being set in the mail handler so that JIRA would know which mail handler service to fire and then create the appropriate issue in that respective project.

If there the catch email address is not being defined, JIRA would still fire up other mail handler service which will according to the order of the mail handler that are being available in JIRA itself.

With that being said, you will need to defined the catch email address for each of the available mail handler to avoid wrong created issue/comment in the incorrect project in JIRA itself.

[kris]

Thanks Daryl! Is this how it happens: Email comes in somewhere (this is controlled elsewhere in my company so I'm not famililar with it) and Jira somehow knows it's for Jira. The mail handlers are fired, but the TO address on the mail doesn't match the catch address for all those handlers. Until it gets to the blank one. Which it doesn't match, but also doesn't conflict. So that's the project that gets the mail.

Therefore, any incoming mail that does not match the other handlers could get dumped into this project with the blank catch email. Is that correct?

My follow up (if that is a correct understanding) is how does Jira know the email is meant for Jira and not some other person in the company? Don't need a technical answer, just curious as it's obvious that it does know.

Thanks much!

[Andy Brook [Plugin People]]

unfortunately its not that simple, as mail handlers do not fire in a specific sequence, so depending on when the one with 'no' catchemail fires, it will consume email regardless of whether another handler has a suitable catchemail address.

JEMH allows many catchemails to be defined, for regular expression matching over those addressees, and even, can use rule-based Project Mappings of email address to project based on either addressee or sender address.

If you only have a fistfull of inbound addresses, just add additional mail handlers to poll the server for each and every addressee catchemail match, but if you go to far with that approach you will experience scalability issues which is what JEMH addresses.

[Stephen Hayden]

Maybe catch email isn't as releavant for our setup? We have a dedicated mail server entry for each listener. If a team needs mail-based ticket creation we have them create an account for us to monitor, we set up a server and a listener and tickets are created - done! In this instance unless we need to squelch out other noise that might make it into the inbox we don't need a catchemail right?

To be clear, we've established a very linear process in the application. There's a mail server entry and a listener for each relevant project, there's no fighting over an inbox, no competing listeners looking for mail.

It sounds almost like we could have all of these mail servers on the mail admin side of things, outside of the application, have them forward to a single inbox for JIRA to poll and then let the listeners do their job. Is that a best practice? We've got an AUG meeting this week, maybe I'll bring this up there?

With a dozen or so listeners/servers we just haven't run into scalability issues.

[Andy Brook [Plugin People]]

if you have one addressee per mailbox, there is no need for catchemail. When you have shared mailboxes, and want to handle that mail differently, the default mail handlers use catchemail to match on.

If your needs are satisfied and unlikely ot grow with only a dozen mailboxes, you are done. If this is the beginning and you need to scale, you are heading for a wall.

Based entirely on andecdotal experience, depending on the mailservers poll cycle-time, eg 3S, with 12 it takes 36S to cycle through, when you have 24, it takes more than a minute, effectively your JIRA is polling round continuously, make that 36 and add any real quantity of traffic and the delays will start to become noticeable, people may start complaining about the perceived time JIRA takes to create an issue and notify. Up the numbers further, and if you are unlucky enough to have a busy mailserver and/or shared infrastructure (network io etc), delays increase all round. The reason JEMH exists is because JIRA email processing choked on WAN connection to remote mailserver when I had 60 concurrent mailboxes...

Pushing all mail into one mailbox has advantages, it means you only need one mail connection, but it will still be 'polled' for every mail handler you have, still not an ideal solution (even if the connection is kept 'alive'). In this scenario you would need to have a catchmail for each and every incoming addressee. In this case, you can support 12 projects with 12 handlers and their catchemails. You'll be fine at 12 but the pattern of One Mailbox to One Mail Handler is not a scaleable one as mentioned.

[kris]

Thanks Andy, that's a really helpful explanation. We'll definitely keep this in mind if more teams start requesting email setup.