technology from back to front

Yahoo doesn’t know what an email address is

Many websites refuse to accept email addresses of the form ``, despite the fact that the `+sometext` is perfectly legitimate1 and is an advertised feature gmail offers for creating pseudo-single-use email addresses from a base email address.

My guess is that the developers of these sites think, because they’re either lazy or incompetent, that email addresses have more restrictions than they in fact have. It’s reasonable (and fairly easy) these days to check the syntax of the DNS part of an email address, because few people use non-DNS or non-SMTP transfer methods anymore, but the mailbox part is extremely flexible and hard to check accurately. A sane thing to do is just trust the user, and send a test mail to validate the address.

I picked on Yahoo in the title of this post: Yahoo are by no means the only offender, but I just signed up for a yahoo account, so they’re for me the most recent. Their signup form also refused to provide any guidance about why they were rejecting the form submission: I had to use my previous experience of sites wrongly rejecting valid email addresses to guess what the problem might be. Fail.


Footnote 1: According to my best reading of the relevant RFCs, anyway. See the definition of `dot-atom` in section 3.2.4 of [RFC 2822](, referenced in this context by section 3.4.1.

  1. Dave Cridland
    on 17/03/09 at 10:47 am

    As someone who has (and ought to continue) edited an internet draft on the subject of “plus addressing”, or “subaddressing”, I’d agree it’s entirely legal.

  2. Yes it’s legal in my reading of the RFC too, and yes it’s annoying the number of sites who do this – unhappy that it extends to companies like Yahoo with such a large email customer base.

  3. The reason I tend to block e-mail addresses with plus signs in them is when I’m trying to combat multiple account spam. Plus signs allow e-mail addresses for the same user to be considered “non-unique” when I run the database query, and I don’t want that :)

  4. Even your blog can’t accpet email like these: customer/

    Funky valid email addresses: (from : )

    * "Abc\@def"
    * "Fred Bloggs"
    * "Joe\\Blow"
    * "Abc@def"
    * customer/
    * $
    * !def!
  5. Oh this is one of my major pet peeves. I completely agree with you, and in fact ran into just this same problem the other day. I’m tempted to start a simple re-mailer that will allow me to use Gmail’s useful auto-sort feature.

  6. Fred Clausen
    on 19/03/09 at 2:52 pm

    It would be a valid complaint if you were talking about Yahoo not relaying your email messages, but if you are just talking about them rejecting it in the course of an account signup it’s not like the RFC compels them to accept anything there.

    If you were rejected (a) trying to create a Yahoo email address with a plus in it, that has nothing to do with compliance – just with their business logic. If you were rejected (b) trying to provide them with an ‘alternate email’ address that had a plus in it, that might be annoying but it is their privilege.

    Out of curiosity, was it (a) or (b)? Also, do you complain when a sysadmin doesn’t let you specify whatever username you want?

  7. @Test User: Thanks for that link, it’s a good one. Regarding this blog: WordPress clearly gets it wrong, too! :-( How annoying.

    @Fred Clausen: It’s the latter — they seem not to accept “alternate email” addresses with plus signs in the local part. They are of course free to do what they want — nobody can force them to play nicely — but the behaviour they (and many other sites) have implemented is in violation of the RFC and so limits email interoperability. The link above gives a little more detail, or of course you could take a look at RFC 2822 itself to see what’s required.

  8. I agree that plus sign should be valid. On the other hand RFC 2822 accepts some email addresses that are completely broken in real world. My favorite is routing information in email address:

    Section 4:

    Though some of these syntactic forms MUST NOT be generated according to the grammar in section 3, they MUST be accepted and parsed by a conformant receiver.

    Section 4.4:

    The route is simply a comma-separated list of domain names, each preceded by “@”, and the list terminated by a colon.

    Example A.6.1

    I’m not sure if conforming to this RFC is a good idea.

  9. Marek, section 4.4 covers a bunch of deprecated obsolete forms. As you observe, these have to be accepted, but are forbidden from being generated. I think bringing up section 4.4 in this context is a bit of a red herring: my complaint was about the rejection of tokens conforming to production dot-atom, which is not an obsolete production. If you were to strip all mention of the deprecated syntaxes from the RFC, Yahoo et al would still not be conformant.

  10. God, fails at this too.

  11. Also! Sigh

  12. I had this same problem with yahoo. So I thought I would give it a different email address just to get past the sign-up process. But once I was in their system I tried to add another address to my account and it still would not accept the + character.

    I only use this feature so I can easily deal with the possibility that I just gave my good email address to a company that is going to send me stuff I don’t want. My email provider translates to be an email to ‘’ and puts it the IMAP folder ‘bar’ where it can’t get mixed in with my mail from REAL PEOPLE.

    I recommend never giving out the one-and-only email address that maps to your inbox. For instance, someone might have a great address like that they would like to always keep and its good because humans can actually remember it in their minds (can you imagine!?). I could make something like and have that forward to or to Later the forwarding could be shut off if necessary or changed to point to a different email address. Although if it forwards to and the messages in turn go into their own IMAP folder called ‘yahoo’ there would be almost no reason to ever end the forwarding even if they send tons of crap because it is all nicely contained in one folder, never mixing with important mail.


four + = 6

2000-14 LShift Ltd, 1st Floor, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK+44 (0)20 7729 7060   Contact us