Error mail queue piling up - JIRA sending email to project email address

[Gergely Groupama]

We found that one of our projects is filling up the error mail queue.

The project is trying to send emails to the project email address, the one that the outgoing emails are configured to go out from, but is not accepting incoming email traffic. This happens only in the case of this particular project, but the notification scheme does not have any unique settings, it contains sending notifications to the standard current assignee, and two project roles that we use.

In the project roles there are the normal users we have in several other projects, where we don't have any issues with notifications.

I've pretty much stared at the notification scheme for hours, not getting any closer to actially seeng anything wrong there. I'm stuck.

We are running Server, v8.13.6

Has anyone encountered such a situation when the notifications are going to an email they arent supposed to go to?

[Jim Knepley - ReleaseTEAM]

Hi @Gergely Groupama 

Sorry that this isn't the clearest answer. From Atlassian:

A reply-to address is the email address to which customers' replies to email notifications are sent.

In Jira Service Management, when customers reply to email notifications for requests created using channels other than email, it goes to a reply-to address. By default, the auto-configured Atlassian cloud email address is set as the reply-to address for your project.

(emphasis mine)

I wonder if the project settings for this specific project are causing the behavior.

ref: https://support.atlassian.com/jira-service-management-cloud/docs/manage-reply-to-address-for-your-service-project/

[Gergely Groupama]

Hi @Jim Knepley - ReleaseTEAM !

Thank for your reply.

Do I understand correctly that the default email address would be the reply address that - in case a user answers a system notification - would pick up reply emails?

If yes, then why would this result in outgoing email failure, thereby filling up the error mail queue? 

What project level settings would you check? i've checked the notification scheme but I can see nothing out of the ordinary there.

Btw, we are not using cloud. We're still on server v8.13.6.

Thanks,

Greg

[Florian Bonniec]

Hi @Gergely Groupama 

What do you mean by sending to project email address ? Did you try to remove the notification scheme and flush the queue to see if it occur again ?

Do you have any error in the logs file ? (outgoing-mail)

Regards

[Gergely Groupama]

Hey, @Florian Bonniec

Thx for your reply.

There is a default email set up for the project (which I can see when I check the notification scheme in project settings.). I would guess its an automatic setting, because I never set it up when creating the project. It is the same email account that is used to SEND the emails and which is not set up TO RECEIVE mails.

This email is not an addressee in the notification scheme, and it is not attached to a user in "users and roles", so I don't know why any mails would be going to this email address.

I did not flush, but I tried the resend option, which was unsuccessful: the same number of errors returned to the error mail queue. I did delete the queue now and I will monitor.

The log files basically just say that the address the mails are being sent to (the one set up as the project email by default) an email address that is invalid.

Thanks,

Greg

[Jim Knepley - ReleaseTEAM]

"Relay access denied" makes things much clearer. That suggests that your server sends messages via a SMTP host that requires the servers it relays for to be explicitly allowed (often by IP address).

The exact configuration on the SMTP host side depends on the SMTP software.

[Gergely Groupama]

That's as maybe, but the same email and same SMTP settings apply to ALL our project but only this specific project is filling up the mail error queue. 

So, what I'm trying to figure out what else I should need to check if the notification scheme does not contain sending the email to the address that is otherwise not permitted to send to.  :)