Mail Handling and projects

[Matt]

New to Jira/JSM and one instance spined up from a colleague without mail server, or at least it shows only "localhost", the mails they want to use are added in admin.atlassian.com . There is a variety of them.. Microsoft org domain is verified and working. Testing scenario includes x - personal MS org.com domain email for incoming x requests.
x@org.com - x requests (in: JSM) - this works
x@org.com - y and z projects (Jira) - this somehow works (as the person migrating old to new instance left)

but, when we want to implement:
abc@org.com - abc requests (shared mailbox with password) it's not selectable via default reporter on Mail Handlers. )

for another privacy@org.com (Jira space/project) we'd want to convert to privacy requests ... and
also, we want 2 or 3 distributions groups associated to requests in JSM project. We were told it's possible...

How about Jira? Is not possible? to associate a distribution group to a project? Why is the documentation lacking this information, and there's not much discussed on this scenarios as well. (or they're old, or for server edition, not cloud)

How would you rectifi this situation?
This is kinda production, so we'd like to be careful not to make the other 3/4 projects of Jira and main JSM fail. 

So, steps taken:
Emails were added in admin side.
It's available to select on Notify page of space, but then cant be selected on Mail Handling pop-up. Catch Email Address and Default Reporter should be the same, yes?
Simply we want a new Jira project with the abc being as notify/reply-to tickets (new tickets) to work. And, if JSM request types can be associated to MS distribution list mailboxes, we'd want to know how.

We'll reset password today for shared mailbox. Maybe that will help.
How to go about for the rest?

[Arkadiusz Wroblewski · Accepted solution]

@Matt 

I will repeat myself a bit but...

For standard Jira projects, it is better to think of the setup as a direct connection rather than a simple association. Jira cannot log in to a distribution list because those lists don't have their own inbox or password. Instead, you should have your distribution list forward all messages to a physical mailbox that Jira is configured to read.

When setting up the mail handler, the Catch Email Address acts only as a filter to ensure Jira only processes mail intended for that specific address. More importantly, the Default Reporter must be a real Jira user account with "Create Issue" permissions in your project. If this user lacks those permissions, the process will fail.

If you need professional features like branded templates or the ability to reply to external senders directly from an issue, the built-in handlers may be too limited. In that case, the Email This Issue  add-on is the best way to give standard projects the communication power usually found in JSM. 

I used this on Data Center for years, including quite complex multi-level support setups and even Software projects where email was used for a kind of double communication flow.

What is important to understand is that JSM makes this much easier because it is designed around customer communication and request handling. It becomes more complex when you start using standard Jira projects for mail handling, because those projects were never really designed for that purpose.

[Arkadiusz Wroblewski]

@Matt 

I answered under instead directly answer. Excuse me.

[Matt]

All okey, I've got it... Where can a person contact you, or email? Some aspects you mention here are gold, for our team to present, as not only me advising the corporate about this...

[Arkadiusz Wroblewski]

@Matt 

You can find most of us on Linkedin.

[Arkadiusz Wroblewski]

Hello @Matt 

It sounds like the wires might be getting a little crossed between outgoing notification settings and incoming mail processing. The address you set up in the admin console is usually just the "From" address for notifications; it doesn't automatically tell Jira to start "listening" to that mailbox for new tickets.

A common point of confusion is the Catch Email Address vs. the Default Reporter.

The Catch Email is just the address Jira looks for in the "To" field of an incoming email. The Default Reporter, however, needs to be a real Jira user account with permission to create issues. It shouldn't be the shared mailbox address itself, it’s just the fallback user Jira uses when it doesn't recognize who sent the email.

For your JSM setup, you’ll have a much smoother experience using the dedicated Email Channel rather than the generic Jira mail handler. If you head to your project settings under Channels & self service → Email, you can connect external accounts and map specific addresses like privacy@org.com directly to a "Privacy" request type.

Since you're dealing with Microsoft distribution groups, keep in mind that Jira can't "log in" to a distribution group because it doesn't have its own inbox. The best move there is to have that group forward emails to a dedicated mailbox that Jira can authenticate with.

I'd definitely recommend testing this with a single new alias or test project first before touching your production mailboxes. Once you can successfully fire off a test email and see it pop up in the JSM email logs, you’ll have a clear template to follow for the rest of your addresses.

[Matt]

Care to elaborate further , especially for Jira spaces, projects? I am very familiar with JSM, the Jira incoming flow, make new requests and reply-to is the annoying part at the moment. 

So, we've been said that distribution list to request for JSM was possible, They either meant with Microsoft flow/forwarding rule, as I havent found any other way (unless we talk about shared mailboxes, and create a password for that) and I dont know of any other ways.

[Matt]

It would be amazing, if documentation would get better examples for people new to Atlassian. Like here, the examples for adding ms domain, mail handling of them and google business similarly to be included: Create work items and comments from email | Atlassian Support