E-mail Advice Sought

Home » CentOS » E-mail Advice Sought
CentOS 15 Comments

I’m working on setting up an e-mail service.

I’ve got the e-mail servers working beautifully and am presently working on re-writing the parts of Roundcube I don’t like (e.g. it uses inline JavaScript in a few places so CSP breaks it) but –

Is there any advice on characters to allow in usernames?

I know there are some wacky characters that are legal in e-mail addresses but are generally frowned upon – like

“very.(),:;<>[]\”.VERY.\”very@\ \”very\”.unusual”@example.com

is apparently a legal address – but I know I don’t want to allow ampersands and brackets etc. in an address.

I don’t think a whitelist alphabet is best approach because of people with names that are not spelled with Latin characters.

Is there an existing blacklist of characters that technically legal but are generally avoided in e-mail addresses?


15 thoughts on - E-mail Advice Sought

  • Alice, you may be a lifesaver! Are you considering to also take a fresh look at rouncube plugins? There is one thing I couldn’t find. On my mail servers I use amavis as a superstrcture above spamassassin and clamav. And there is a way to have users individual spam/virus preferences in mysql database (alas, PostgreSQL didn’t work in all my attempts). And the only missing thing here I never found is how to give users a way to edit their whitelist/blacklist preferences. There is long list of things I tried to harnes… so far amacube is the closest to giving users the way to edit preferences, and only whitelist/blacklist is missing from it.

    Thanks a lot for all your efforts!!


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • The RFC uses a list of allowed characters, and so must you.

    My advice is, first, don’t write this yourself. There is almost certainly a library for validating RFC-compliant usernames in whatever programming language you use; locate one and use it.

    Second, when validating user names, you must be aware of the features of your email server. For instance, it may use the ‘-‘ character or the
    ‘+’ character as a way to allow user-local extensions. Thus
    “example-foo,” “example-bar,” and “example” may all be the same user/mailbox. If you are not aware of this, then a new user might be set up as “example-bar” and one would mask the other. Either the old user would prevent the new one from receiving any mail, or the new one would begin intercepting some of the old user’s mail. Thus, because a character is allowed by RFC does not mean that you should allow it in usernames.

    Third, you should be aware that non-ASCII support was defined in RFC
    6531, in 2012. That’s very recent as RFCs go, and it is not widely supported today. None of the mail servers shipped with CentOS 7, for instance, include such support. Even if you build your own software that supports the RFC, users with non-ASCII usernames will not be able to send or receive email with remote domains that don’t include such support.


  • Those are things I want to have, so I will try to figure it out.

    I’m not positive it will be compatible with stock Roundcube though, I’m rewriting a lot of Roundcube in DOMDocument because I really prefer XML
    output for a variety of reasons.

  • For e-mail sent to people, yes.

    But for what usernames are allowed when creating an account, I don’t see why blacklisting characters that are not allowed in a username is a standards problem.

  • I think there is a mis-understanding.

    All I was looking for was if there was a common set of characters typically blasted from new usernames *on the domain being set up*

    I have no desire to refuse delivery to any valid e-mail address.

    For example, avoiding spaces in usernames for addresses on the system is handy because it avoids bugs where the path to the mailbox on the filesystem isn’t properly quoted.

    So user names on the system won’t be allowed to have spaces even though they are legal when within quotes or escaped.

    That’s all I was looking for, was experience on what legal characters to avoid allowing users to have for the mailbox portion of their e-mail address, the username.

    Of course I have no desire to restrict who they can send to if it is a legal address.

  • Am 01.05.2016 um 06:43 schrieb Alice Wonder :

    blacklisting is not a good practice, use the suggested whitelist …

  • I think this is my autism coming in to play, I think what is very clear to me I just am not able to adequately communicate because clearly people are not even remotely grasping what I am trying to convey.

  • Basically whether it is a white list or a black list doesn’t matter.

    One is just the complement set of the other.

    It’s the set I’m after. Or its complement. I don’t care. Not whether my code should use set A or its complement.

  • I disagree from practical experience. My Exim mail servers (MTAs)
    refused connections from ‘amateur’ mail senders such as:-



    et cetera

    and from professional spammers


    et cetera

    My philosophy is not to be a willing victim of spam and other unwanted time-wasting junk. It is only when concerned citizens like Alice (in)
    Wonder(land) critically re-examine the status quo, and the justification for it, that things may improve.

    Mankind never advances when there is no questioning of established practises.

  • See Gordon’s previous answer above:

    That is, [A-Za-z0-9._][A-Za-z0-9._-]

    In other words, allowable characters are A-Za-z (upper and lower case),
    0-9 (numerics), . and _ (period and underscore).

    Hyphens are allowed, but NOT as the first character, so maybe easier to just not allow hyphens in your account usernames.

  • Then you’re after RFC 5321 section 4.1.2 and possibly 6531 section 3.3
    (but probably not for a few years yet). You should also consider shadow-utils’ chkname.c, where valid local user names are restricted to
    “[a-z_][a-z0-9_-]*[$]” of less than USER_NAME_MAX_LENGTH characters
    (though not with a regex).