On digital signatures and client security issues
One of the technical problems with 'sender stores messages' schemes for email-like things is that it lets a malicious sender generate messages on the fly for up to the moment customized malware (and this gets much, much worse if the protocol helpfully includes things that you can use to fingerprint specific client software).
It is tempting to deal with this problem by making the identification for messages include a hash verifier or address, in the way that current version control systems identify files by their hashes. This would mean that while a malicious server could still try to send you different content, your mail client would detect a hash mismatch and reject the message as corrupted.
(Let us set aside a number of pragmatic problems with this idea, some of them social and some of them technical, and the fact that it would be relatively weak protection in general.)
But this has not solved the problem; it has merely reduced the attack surface. You still have to trust that your client will not have bugs in the code that runs up to the point where it rejects a message for not having the right hash (and you have to trust your client to not have hash verification bugs). Depending on the message access protocol, this may amount to a significant amount of code, some of it complex.
This is of course not a problem unique to 'sender stores messages' email systems; it is a general issue with anything that uses hash verification or other digital signatures in an attempt to reject malicious input. Hash verification can reduce your risks, but it does not magically make them all go away (and it adds new risks, like 'did the people who wrote the libraries you're using understand the proper way to verify signatures').