Not signed in (Sign In)

Tech Support: What's wrong with a "+" being in an email address?

Bottom of Page

1 to 8 of 8

  1.  
    • CommentAuthorMarkB
    • CommentTimeMay 19th 2009 edited
     
    If I send an email to myself from my gmail account (like myemail.address+extra@gmail.com) it goes through with no problem back to my gmail account, but won't appear on my Peek.

    Also, while it took some doing, I finally managed to get a "+" in the To: field of an email on my Peek and got a new error that I've never seen:

    "Oops! It looks like your recipient addresses may have some formatting errors. Would you like to send anyway?"

    I know that some email servers really don't like a "+" in the email address, so that may be a reason, but what's up with the + being bad?
    •  
      CommentAuthortmel
    • CommentTimeMay 19th 2009
     
    Hmm!

    What software version you running? :-)
    • CommentAuthorMarkB
    • CommentTimeMay 19th 2009
     
    I'm on 1.08.11 for the moment.
    • CommentAuthorwmoritz
    • CommentTimeMay 20th 2009
     
    MarkB,

    Your question is a very complicated thing. The short version of the answer can be found at:

    http://en.wikipedia.org/wiki/E-mail_address

    The gory details with all kinds of other info is available in RFC 5322 and RFC 3696:

    http://tools.ietf.org/html/rfc5322
    http://tools.ietf.org/html/rfc3696

    And of course a Google search on "legal email address characters" has more info that you would likely care to read:

    http://www.google.com/search?hl=en&client=safari&rls=en-us&q=legal+email+address+characters&revid=2042610344&ei=c0AUSv7BOMnJtgfu5bWcBA&sa=X&oi=revisions_inline&resnum=0&ct=broad-revision&cd=5

    The simple answer is what you have already touched on, the + sign can cause problems and should likely be avoided even though it can be argued that it is a legal character.

    wmoritz
    • CommentAuthorcgingerich
    • CommentTimeMay 20th 2009
     
    I don't see it being an issue. I am using a few email addresses with a + in them without any problems.
    •  
      CommentAuthorJanaKay
    • CommentTimeMay 23rd 2009
     
    I've gotten that formatting error as well, I just tell it to send anyway, and it works fine.
    These aren't emails with +'s in them, but usually to yahoogroups. Yahoo sometimes puts <> around an email address, as well as listing it separately, and apparently my Peek doesn't like that all the time.
    • CommentAuthorjrobgood
    • CommentTimeMay 24th 2009
     
    Plus addressing is legal and should be supported, in my opinion. It's a great organizational tool for delivering directly to a specific IMAP folder on the receiving end, where honored by the recipient's server.
    • CommentAuthorklotz
    • CommentTimeJul 10th 2009 edited
     
    @wmoritz Is this fixed in the 1.09 versions?

    According to RFC 5322, which is normative, section 3.2.3. the production for atext includes "+" and according to 3.6.4, id-left is dot-atom-text, which is a sequence of dot-separated atext.

    Similarly, RFC 3696, though merely informative, states
    | Forms such as ... user+mailbox@example.com ... are valid and are seen fairly regularly

    The cited Wikipedia article on "E-mail_address" says
    | ... some mail servers violate RFC 5322, and the recommendations in RFC 3696,
    | by refusing to send mail addressed to a user on another system merely
    | because the local-part of the address contains the plus sign (+).
    | Users of these systems cannot use plus addressing.

    However, this comment is not addressed at users sending mail with MUAs (such as the the Peek service) but instead at users receiveing mail through MTAs/MDAs which would inhibit the plus. By definition, if someone gives you an email address containing a plus, and it works for them, it's your fault if your MUA or MTA can't handle sending it.

    So my conclusion is that while the Wikipedia article is correct in cautioning that not all mail users will be able to set up their own MTA to receive mail with the legal character "+", it's incorrect to infer that MUA/MTA vendors such as the Peek service should inhibit the character.

1 to 8 of 8

  1.