Here's another hint as to this being a bug in the iOS app. When I read the message and it doesn't get marked read, I have to manually swipe right to reveal the manual Read button. This button never fails. I can swipe right and hit Read, or I can hit Unread, and the button works every time. I have never once pressed that Read button and had it not mark the message as read. Works every time. If it were my Wifi, my mail servers, the internet, etc. then this manual pressing of the Read button would surely fail randomly just as often at times too. But it doesn't It hasn't. Not once.
The bug isn't in the code that tells the servers the email is to be marked read and then removes the dot, it's in the code that tells "itself" the email was read and never even triggers the code to tell the servers. The manual Read button directly triggers the code that tells the servers, marks it read internally, and gets rid of the dot, which never fails. This is why the folks sniffing with Wireshark never see the call to the servers ever take place.
There is likely logic in the app that tries to determine if you read the email that is more complex that simply clicking on the email. I know I've received emails that I couldn't read yet because despite clicking on them the email body window simply said that it hadn't finished downloading the content. There is probably something in the read logic to that effect where a number of variables need to be set, knowing the message has fully downloaded, that you've opened the message and displayed it, probably all intertwined in the whole Swift/Objective-C (whichever version it was written in) application callback lifecycle of viewWillLoad, viewDidLoad, viewDidLayoutSubviews, etc. mess that has one of the key variables left untouched and not triggering the functionality that identifies the message as having been read locally inside the app. And if the app doesn't think you've read it internally, it's not going to tell the server that you've read it.
