Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Email usernames seem case sensitive. Error "Cannot send mail as" whenever the text case doesn't match.



  • Hello,

    Recently ran into an odd one to me, mostly because I understood from various specs that emails should be case insensitive, but it seems this may conflict with Cloudron authentication which I guess is case sensitive?

    A client recently setup their Mail client app after a rebuild, and while I always encourage my clients to use all lowercase for their usernames as a best practice, they used Michelle@example.com for their username instead of michelle@example.com. Received the following error in the logs when she tried to send:

    Jun 14 09:54:23 [INFO] [84E9F590-D0B1-4CB6-8F29-053BB08D3EEF.1] [core] hook=mail plugin=cloudron function=authorize_mail_from params=<michelle@example.com> retval=DENY msg="Authenticated user Michelle@example.com cannot send mail as michelle@example.com"
    

    My concerns are the following:

    1. Usernames and email addresses should be case insensitive. Is Cloudron case-sensitive when it comes to usernames?
    2. If usernames were case sensitive (which seems to be the case here), then why is it even authenticating Michelle@ in the first place when the mailbox name is established in Cloudron as michelle@?

    My expectations:

    1. User logs in as Michelle@example.com or even MICHELLE@example.com which Cloudron should equate as michelle@example.com
    2. User able to send mail as anything that matches their username email, since case sensitivity should not matter.

  • Staff

    @d19dotca We have tests to make sure that mailbox delivery code is case insensitive. But maybe there is a bug that authentication username is case sensitive.



  • @girish Yes, definitely seems like a defect somewhere. I initially didn't think it was related to that case sensitivity and had even informed my clients before that they're not case-sensitive, but this seems to either not be the case any longer (changed inadvertently?) or I just perhaps never ran into it before but it maybe was case sensitive for a while now, not too sure. Hopefully this can be fixed though, as this will certainly present more issues as the business grows too and more clients are onboarded.


  • Staff

    I managed to reproduce it:

    dd32ed12-1e76-405d-abbd-d8d75022cce7-image.png


  • Staff

    Indeed, there was a missing normalization. I have fixed it for the next release.