The user account password is stored somewhere "on the user". The user is theoretically responsible for protecting his own password. Ideally, he keeps it in his head and types it again when needed.
Some (most) users won't like it, and will instead enabled the "remember password" button, which will make the email client remember the password. If the email client is reasonable and runs on a reasonable operating system, this storage can be somewhat protected. For instance, on MacOS X, using Apples "Mail" application, account passwords will be stored in the user's Keychain, which is stored encrypted, the decryption key being the main user password (the one he types to open a session or unlock it). That way, the email account password is never stored as plaintext equivalent; an attacker stealing the complete hard disk of the machine will not immediately find it. (But it won't save the user against an hostile but discreet hijack of the machine, because of, at least, key loggers.)
Some other applications and/or operating systems won't be as reasonable as that.
Among possible mitigations:
Each user shall have his own account and password. This one, you already do. This ensures that a stolen password unlocks the account of only one user, which is better than nothing.
The email account password could be specific to email, and not be used anywhere else, in particular not to open SSH or RDP sessions. Users won't like it (they really prefer remembering one password than two). Also, most "password reset" systems fall back on email, so stealing an email account password can open access to a lot of other systems.
Implement one-time passwords. Hardware tokens such as this one are granted to users. Email applications won't have anything to save poorly.
However, user education is of paramount importance.