Issue 18.0.73#1 Not playing with Apple Mail

[shogunswb]

Server operating system version

Almalinux 9.1

Plesk version and microupdate number

18.0.73#1

I upgraded from 18.0.72#3 direct to 18.0.73#1 & on checking services Dovecote service hadn't started. Started Dovecote without any problem but neither Apple mail on my Mac or my wife's would connect to the domains on the server.
They are IMAP accounts I have mail set manually with ports 993 & 587 (587 set as the mail server port) & to use TLS/SSL & when I checked the 6 accounts I have on the server with Connection Doctor neither IMAP or SMTP would connect.
Thought it was mail down on the server but on investigation I then realised that my iPhone & my wife's Android phone were still able to send & receive & also booted up windows in VMWare & Thunderbird mail client was also working.
Went back to Apple Mail & set all accounts to "Automatically manage connection settings" & mail started working again.
I also contacted Plesk Support who created an account using Thunderbird on Windows & concluded that Apple Mail was at fault & I sort of agree, but the problem only occurred after this update which before the #1 update had a Dovecote issue & needed the fix.
I have also set the mail accounts back to manual port settings & they still work now.
Also had one of my clients have exactly the same issue.

 

[scsa20]

I tested it on a mac VM running macOS 15.7, with Apple Mail version 16 build 3826.700.81 and it worked just fine.

Some questions:
Is there any errors in Apple Mail?
Have you tried removing and readding the account?

Also check the logs and see if there's any errors. You can use the log browser to easily view the mail logs and just filter it by the email address.

 

[_sashok]

Issue - Plesk 18.0.73 - postfix/smtpd fatal: no SASL authentication mechanisms

Morning, I was just sending a test mail on my systems to make sure everything was ok after the Dovecot update, only to find my mail being held in the queue. I see lots of...mail postfix/smtpd[3261]: fatal: no SASL authentication mechanisms in the mail.err log since the update to 18.0.73...

talk.plesk.com

 

[shogunswb]

I tested it on a mac VM running macOS 15.7, with Apple Mail version 16 build 3826.700.81 and it worked just fine.

Some questions:
Is there any errors in Apple Mail?
Have you tried removing and readding the account?

Also check the logs and see if there's any errors. You can use the log browser to easily view the mail logs and just filter it by the email address.

This happened on three different Mac OS's from bang up to date to 3 or 4 versions old & three different Mail builds.

I did check the logs & it was throwing authentication errors for most of the accounts that Apple Mail was trying to access.

It probably is the way that Apple Mail communicates with the mail server as the reason I have all the account ports set manually is because if I set them to manage automatically then they randomly throw authentication errors & I have to change it.

All I can do is keep an eye on it & was interested if anyone else using Apple Mail was having the same issue.

 

[Lexz]

We see the same issue here. Any ideas?

 

[Lexz]

Just read the issue _sashok posted. Hopefully that will fix it

 

[Kaspar]

[...]

If I had to make an educated guess, I'd say the issue is probably not related to the ports you're using. But instead caused by the changed authentication mechanisms for email introduced with the Plesk .73 update. I think this is also what @_sashok was referring to with his post.

Because the authentication mechanisms changed and your mailboxes where created before the Plesk .73 update I suspect authentication for your mailboxes failed after the Plesk update. And as a result your own IP('s) probably got banned by fail2ban, temporarily blocking any mail related connections. This is just my assumption, the cause might be entirely different too.

In any case, removing the email accounts from your email client (Apple mail, Thunderbird, ect) and re-adding them later should resolve the issue. Alternatively you could change the available authentication mechanisms on the server as discussed in this forum thread.

 

[shogunswb]

We see the same issue here. Any ideas?

The way I fixed it was to change all of the IMAP accounts to "Automatically manage connection settings" as opposed to the way that I had it previously which was manually assigned ports 993 for IMAP & 587 for SMTP or 465 SMTP depending on the way you have your mail server set.

Also check that fail2ban hasn't banned your IP although I have mine in the trusted list.

If you already have them set at automatic then try manually assigning the ports & use connection doctor under the window menu in the task bar to check which accounts are connecting.

I have only seen this Issue on Apple Mail, Outlook on Mac didn't give an issue & neither did Thunderbird on Win 11 & both iPhone, iPad & Android phone Outlook carried on as before.

It possible does have something to do with Sash's post but I need to dig into the way that Apple Mail negotiates on IMAP accounts.

 

[flex1]

After upgrading to 18.0.73 Update 2, we are also experiencing this issue with many customers who use Apple Mail on Mac (iOS continues to work without any problems). All customers experiencing this issue have disabled ‘Automatically manage connection settings’ and selected ‘Password’ as the authentication type. Interestingly, the problem can be solved by changing the authentication type to ‘MD5 Challenge Response’ or similar, clicking ‘Save’ and then changing back to “Password”. After clicking ‘Save’ again, the mailbox can be used without any problems.

 

[TobiasP]

I'm still having issues with dovecot even after updating to 18.0.73 Update 2 - it seems since the update to dovecot 2.4.1-4 thunderbird and outlook on mac (legacy) cannot be used anymore - all I get in the logs is:

dovecot: imap-login: Login aborted: Connection closed (no auth attempts in 0 secs) (no_auth_attempts): user=<>

auth_debug=yes does not yield any helpful output - its just like thunderbird is not even trying to authenticate - why is the transmitted user empty??

 

[TobiasP]

followup:
seems the problem was with a imap_capability = +XLIST I had in a special_use config file...