What are the security reasons for disallowing the plus sign in email addresses?

  • My question is based on this tweet after I commented about forbidding + symbols in email addresses. The tweet says, "This is a measure we've taken for security reasons."

    This can be frustrating and inconvenient for people that have (or use) plus signs in their email address, and I'm sure web sites don't intend to do that. I'm unaware of the security vulnerabilities related to using the + character; is this something I should change to improve my own security? What is the security reason for a web site to disallow that character on an email field?

    Update: Meetup Support responded positively. Turns out it's more of a UX issue than a security one. They clarified in this tweet that they disallow + to prevent spam (?) and they acknowledged a suggestion for improving the user experience. (My intent here was not to gripe about Meetup; let's be gentle! I wanted to make sure I was not missing something important in my own web sites that receive email addresses.)

    I doubt they have any valid security reason, rather they are just lazy and don't want to fix it.

    As an aside, it may be possible to bypass that validation if it is done client-side (IE by javascript). Also, @martialdidit, you should just mark the question as a favorite and not comment saying that it is something you will come back to.

    One reason is that, at least with Gmail, anything after the `+` is ignored. That means that `[email protected]`, `[email protected]`, etc. are all delivered to `[email protected]`'s email. This is useful in finding out who is selling your information. For example, if I sign up for Fabrikam Inc.'s newsletter with `[email protected]`, and I get an email from Contoso Ltd. directed to `[email protected]`, I'll know Fabrikam is selling my information.

    I too use the + sign a lot in my Gmail address to filter out mails and to see who has sold my mail address. I believe most sites just use the same regex to check the validity of an entered mail address and that this regex doesn't allow a + sign. I've contacted many sites for this and most answer it's just the way the system works (i.e. they're to lazy to fix it)

    1 thing I can think has nothing to do with registering on a site. Some mail clients might show a mail coming from `[email protected]` as a mail from PayPal. Although this issue is already years old and has been 'fixed' by most mail providers

    I wonder who from MeetUp has seen this post...

    Gmail allows unlimited numbers of addresses containing a plus to forward to the same address. I.e. [email protected] forwards to [email protected] If the site allowed users to use emails addresses like these, spammers would have an easy way of creating an unlimited number of accounts from a single email address.

    @JamesT.Huggett At that point it's more of an engineering/UX problem than a real security issue. There's ways to strip out or ignore the "plus" portion of a Gmail address and check for duplicates. It can be inconvenient to implement, but it gives more security/control to the user.

    The way I read their response is "we would like to be able to sell your email address with others without you being able to tell we've done this".

    @Cole another use for that is filtering emails: I can set mail sent to `[email protected]` to go in a specific folder.

    That's why I just configured my mail server to use the underscore as the decoration character (in addition to `+` of course)... so now I can sign up with `[email protected]` and it actually goes to `[email protected]` with all my other email, but is filterable and accountable, and underscores are common enough in email addresses that most places accept it :D

    An additional problem with the + sign is that you *must* get URL-escaping right, otherwise it can be silently reinterpreted as a space character, since spaces were encoded as a + in URL parameters on the early web. I've seen many web forms accept a + character in an email address, but change it into a space on the next page. The solution is to edit the URL, changing the + into %2B, which is a URL-encoded + character.

    @gpvos Yes, I found this problem on a retailer website a few weeks ago and reported it. (They rewarded me with a voucher.) So plus addressing has still been profitable...

    One possible security vulnerability is that a hacker can sign up for one valid email address that might require phone verification to prove that the person is real. After that one verification, the hacker now has an unlimited number of email addresses to use when registering accounts on various sites. This could be a problem for sites that require minimal identity verification, like a birthdate and matching some contract number. In those cases, a hacker can write a script to register for multiple accounts that aren't theirs, and they don't need to get another "real" email address to do this.

  • gowenfawr

    gowenfawr Correct answer

    7 years ago

    There is no security vulnerability per se with having a '+' in your email address. It's permitted as per RFC 2822, and not particularly useful for SQL or other common forms of injection.

    However, many systems (let's call Meetup a system for this purpose) enforce security through whitelisting, not blacklisting. Someone defined a limited list of characters they expected to see in email addresses (probably upper, lower, numeric, ., _, and -) and wrote a filter to block anything outside that list. And they didn't think anyone would use +, so you're out of luck.

    This article describes how to set up Postfix to tag, and to use '-' instead of '+' because:

    However, during a recent discussion on the Postfix user list, it was mentioned that some websites (particularly banks) use JavaScript to try and validate email addresses when they are entered into online forms, and that many don’t allow the plus symbol as a valid character in an email address.

    I switched from '+' to '-' over a decade ago, for similar reasons.

    Can you use a combination of + and -? I know gmail will attempt to filter your + tags into separate labels where possible, ie, [email protected] will send any emails from that particular service to the spam tag. I've never tried [email protected] though.

    In short, both + and - are legal characters and you can use both, in any combination, in your email address. However, it's up to your mail server how that's handled. Courier and Postfix both support tagging with simple configuration settings, but I don't think either will support two tag markers without extra work. YMSMV (Your Mail Server May Vary).

    If you're not running your own mail server, you can't control how they will process a hyphen. In most cases, "[email protected]" is a completely different email address/account from "[email protected]". OTOH, most providers treat "[email protected]" the same as "[email protected]", allowing you to use it for client-side filtering purposes.

    It's important to note that according to RFC 822 the only characters explicitly not allowed are: `( ) < > @ , ; : \ " [ ]` (technically `.` belongs here too, but it's handled a little differently, and is permitted in a fashion)

    @DoktorJ isn't anything permitted inside a quoted local-part? Or does RFC 822 not allow quoted local-parts? (RFC 821 does, so that seems like a problematic inconsistency)

    @Seiyria I just tested that, and it does not work, at least not with custom labels.

    @immibis Yes, you are correct: RFC 822 allows the local part to be a sequence of dot-separated `word`s, and a `word` can be a quoted string, which can contain any character (some of which may need to be backslash-escaped). RFC 2822 also allows this, but specifies that it "SHOULD NOT" be used.

    Is there any reason to *not* support all valid email addresses (besides perhaps the simplicity of validating the address)?

    @Kat I've done some client-side validators, and I've found that I always want to enforce a `.domain` at the end of an e-mail, even though something like `[email protected]`is technically a valid address.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM