The "Connection Test" fails on the Outgoing Mail server when the option "Change password" is not ticked

Issue Summary

If the change password option is unticked, and if there is no username/password specified in the Outgoing Mail configuration page, testing the connection fails with the error below:

AuthenticationFailedException: failed to connect, no password specified?

Steps to replicate

To replicate the bug, make sure that you have an SMTP mail server that does not require a username and password.

1. Install Jira Server on any version from 9.2.0
2. Log into Jira as a Jira System Admin user
3. Go to ⚙ > System > Outgoing Mail
4. Configure a the SMTP Mail Server without specifying the combo username/password and verify that the Connection Test is successful:
   
5. Save the configuration and verify that the configuration is successfully saved:
   
6. Click on Edit next the Outgoing Mail configuration
   • You'll be redirected to the Outgoing Mail configuration page
7. Don't change anything, and test the connection

Actual behavior

Even though nothing was changed in the Outgoing Mail Server configuration, the connection test fails with the following error:

AuthenticationFailedException: failed to connect, no password specified?

Expected behavior

The connection test should be successful as it was earlier, since:

• nothing was changed in the outgoing mail configuration
• the SMTP mail server does not require any username/password for the authentication

Workaround

Tick the Change password option and make sure that the username/password fields are still empty (some browsers like Chrome might autofill these fields with random values), and then test the connection again. The Test should be successful:

Important Note about this workaround

If after ticking the Change password option, you are getting an authentication error with an error code instead of the error "failed to connect, no password specified?", then you might be facing the bug JRASERVER-74878. In this case, please refer to the workaround from that other bug to ensure that the connection test is successful.

Additional notes

When issue is replicated, we can see that the following payload is sent with the request /secure/admin/VerifySmtpServerConnection!update.jspa:

{
	"name": "Test",
	"description": "",
	"from": "some@test.com",
	"prefix": "Test",
	"protocol": "smtp",
	"serverName": "smtp",
	"port": "1025",
	"timeout": "10000",
	"authenticationMethod": "password",
	"username": "",
	"password": "",
	"id": "10000",
	"type": "smtp",
	"clientTokenId": "",
	"atl_token": "BKBX-HRUW-P4GD-UDCQ_525313fae08d8ac534c4d4140b6a6777782c466f_lin"
}

When the issue is not replicated, we can see that the following payload is sent with the request /secure/admin/VerifySmtpServerConnection!update.jspa:

{
	"name": "Test",
	"description": "",
	"from": "some@test.com",
	"prefix": "Test",
	"protocol": "smtp",
	"serverName": "smtp",
	"port": "1025",
	"timeout": "10000",
	"authenticationMethod": "password",
	"username": "",
	"changePassword": "true",
	"password": "",
	"id": "10000",
	"type": "smtp",
	"clientTokenId": "",
	"atl_token": "BKBX-HRUW-P4GD-UDCQ_525313fae08d8ac534c4d4140b6a6777782c466f_lin"
}

We can see that the only difference between both payloads is the presence of the parameter changePassword when the issue does not occur (while it's not there when the issue is replicated).