14 ms·

If your email is <RFC>fan 69™@root I am not going to let you signup. Sending emails cost money and bouncing emails affects your sender reputation. Also, for eve

• josephcsible 5y ago
  This logic is why so many Web sites today won't let you use a plus sign in email addresses, which ruins a really nice Gmail feature.
  • kyrra 5y ago
    As people said, true spammers know to just strip off the "+" in the email address. This is actually a fun reason to set up your own domain and set up email forwarding for *@example.com to go to your main gmail or whatever account, then the "username" part of the email I just set to the domain of the account I'm signing up for. So I'll use amazon@example.com when signing up at Amazon (or whatever site).
    • judge2020 5y ago
      Note that you should only do this for maybe 6-18 characters, some sites will test send an email to [30-100 character random string]@example.com and see if it bounces - if it doesn't, it'll suspect that domain to be some spammer with a catch-all email inbox and block it.
      • alufers 5y ago
        Do you know what sites do that? I have my own domain and I haven't seen anybody do that. The obvious solution is to configure your mail server to only accept usernames before the '@' that adhere to some rule which only you know. Like checking if it is a palindrome or something obscure like this.
      • bbarnett 5y ago
        I watch multiple corp's mail logs extensively, this is not even remotely a common thing. Worse, I know at least 5 or 6 people personally, which do catch all. It seems like a very poor method to reliably catch spammers.
      • jasonjayr 5y ago
        That's a terrible approach, plenty of valid, legitimate non-spamming domains use catchalls of arbitrary length for all sorts of reasons. Additionally, sending a test email like that might also get the sender placed on a black list for triggering a spam trap inadvertently.
      • pmontra 5y ago
        That's a worrying strategy because there are many reasons for using a catchall. Example: one email per site to track companies selling personal data, then maybe bounce that single email address. Do you know any site blocking domains with a catchall?
        • LorenPechtel 5y ago
          Yeah, if you have a domain of your own the sensible thing is a catchall, use a different address everywhere and block the ones that spam.
      • megous 5y ago
        Max local part size is 64 octets. So 100 chars would be out of spec.
    • rootusrootus 5y ago
      > So I'll use amazon@example.com when signing up at Amazon I go a little farther. I figure an attentive spammer might figure out that if I use amazon@johnsmith.net to sign up for Amazon, I may have exactly the scheme where *@johnsmith.net will work, so they can just add that to the spam list as a wildcard and pick a new address every time. So instead, I use john101@johnsmith.net, john102, john103, etc, to try and obscure my strategy and prolong the life of the domain forwarding.
      • willcipriano 5y ago
        I just have a entire domain for the purposes of spam. Anything sent to there ends up in my bulk folder. I use amazon@domain.com so I can tell who sells my email or gets hacked. Never noticed someone trying to send a email to any addresses I haven't previously used.
        • wastholm 5y ago
          > Never noticed someone trying to send a email to any addresses I haven't previously used. At least a few years ago, I noticed a lot of spam to <random first name>@<my domain> -- i.e., completely made-up addresses that I had never used. Since messages sent to those addresses were guaranteed to be spam, I started treating them as free training data for the spam filter. I don't know if this still happens, though, because I haven't looked.
          • Grollicus 5y ago
            This is currently happening to my email domain. Gets rejected as it doesn't have a valid hash (recipient name), but the logfiles are full of <3 letters>@mydomain.com and <english_word>@mydomain.com rejections.
            • klyrs 5y ago
              Yeah, this is an age-old issue -- in the early 00s, my mom got a domain and used the email <first_initial>@<domain>.com. She gave up battling the deluge of spam after about a year. We looked through the logs, and saw that her next choice of handle was also getting tons of spam, too, because it was also short.
    • em-bee 5y ago
      well, you could turn it around and use + addresses everywhere, so that any legitimate response must be to one of your + addresses. then treat anything without + as spam.
    • academia_hack 5y ago
      The + is also useful for knowing who sold your email address on or was responsible for a data breach. If I start getting spam to <my name>+hulu@gmail.com, then I know I could chase down Hulu on Twitter for an explanation.
    • zzo38computer 5y ago
      I do a similar thing, except that the email is actually hosted at my domain rather than being forwarded, and that I have a list of email addresses that I accept and reject all others; if I receive too much spam at one address, I disable receiving at that address. I have found this to work; I hardly receive any spam at all, and do not need any separate spam filter.
    • progforlyfe 5y ago
      Although hardly anyone uses yahoo mail anymore, they actually have this feature built in. Basically email aliases.
    • frereubu 5y ago
      Didn't you find you got a deluge of spam to generic addresess like admin@, info@, offers@ and so on? I tried this, although it was probably about 15 years ago now, and reverted it because I got about the same amount of spam as genuine emails.
    • shard 5y ago
      That makes me want to use an email address of the form +myname@mydomain.com, just to see how websites would handle stripping out everything starting from the +.
    • unanswered 5y ago
      I've run into at least one domain that blocks their own name in your email; that was fun.
  • j_wtf_all_taken 5y ago
    I don't really think that's the same. Forgetting the "+" in the validation regular expression is something else than refusing to implement all kinds of extra checks to support very weird and very unused things.
  • deleted 5y ago
    [deleted]
  • tyoma 5y ago
    The best are sites that let you sign up with a ‘+’ but not log in. Zappos used to be the most prominent example.
    • dangoldin 5y ago
      Interesting. How did that work? Does that mean that they would only create the user account under the + suffix? I imagine they must have had two email fields - the canonical email for login and then a separate notification email?
    • tshaddox 5y ago
      I’ve seen sites send emails where the unsubscribe link doesn’t work because the URL contains the email address I signed up with and that email address contains a character that their web server doesn’t play well with.
    • scubbo 5y ago
      I once had a site _silently strip_ the + from signup email. So when I submitted `myname+yoursite@gmail.com` as my email address, they started sending mail to `mynameyoursite@gmail.com`. Madness.
      • not2b 5y ago
        This is common; spammers know the semantics of '+' for gmail and will strip it. You need to assume that it will happen.
        • cgriswald 5y ago
          GP said the site stripped the “+” only, essentially sending his email to another address entirely. Spammers strip the “+” and whatever follows it, so the spam ends up at the same address.
        • scubbo 5y ago
          If spammers are converting from `myname+yoursite@gmail.com` to `mynameyoursite@gmail.com`, they are welcome to spam it as much as they want - it won't get to me. EDIT: moreover, a service is perfectly within their rights to _internally_ store my email as `myname@gmail.com` if they want - but they should still accept `myname+yoursite@gmail.com` as the identifier used to login with.
  • raffijacobs 5y ago
    Can't you use "." Anywhere in your email to use the same multiple times in Gmail?
    • josephcsible 5y ago
      Yes, assuming the websites following this logic don't block that too, but then you have to keep track of a mapping of dots to websites yourself instead of it being obvious from what you put after the plus sign.
      • alfon 5y ago
        Or use a password manager.
  • toxik 5y ago
    OTOH, it being a standardized thing, a spammer would absolutely just strip that plus part off. Better do it secretly like a catch-all.
    • gxnxcxcx 5y ago
      I think that when using email aliases to identify spam sources, the crucial part is that you can filter the stripped address (as well as any unapproved alias) to be directly identified as spam and then the +alias part becomes a key to properly get into the inbox. That whole setup for tidiness is broken the moment a desired website does not accept an alias in your address, of course.
    • nybble41 5y ago
      It's not really all that standardized. The use of a '+' character to indicate an alias or label is merely convention—if you run your own server you can set the separator to any character you wish, or disable the feature altogether. As far as the RFCs are concerned the '+' character is just part of the account name and there is no reason why it cannot be a mandatory part of the account name on any particular server, such that stripping off the '+' and any trailing characters results in an invalid e-mail address, or even someone else's e-mail account. For sending email or using an email address as an account identifier it's definitely incorrect to treat abc+xyz@example.com and abc@example.com as equivalent. The same goes for account names which differ only in capitalization or placement of periods: some servers are case-insensitive and ignore periods in account names (e.g. Google) but these are server-specific traits and compliant email senders should not assume that every server will work the same way. The '+' alias feature is a fairly common configuration, though, so for source labels it's better to either treat all unlabeled messages as spam or else use a more opaque labeling scheme (unique-hash@example.com) which doesn't hint at an alternative untracked email address.
      • stonogo 5y ago
        Subaddressing is standardized in RFC 5233.
        • 5y ago
  • ridaj 5y ago
    Why do so many people responding to this seem to assume the plus sign is to fool spammers? Of course it's not useful for antispam. It's mostly meant to make it easier to trace where a (legit) email comes from, for example to set up filters. https://gmail.googleblog.com/2008/03/2-hidden-ways-to-get-more-from-your.html https://gmail.googleblog.com/2008/03/2-hidden-ways-to-get-mo...
    • sellyme 5y ago
      > Of course it's not useful for antispam. I've received spam emails to at least 70 different +addresses. It is absolutely useful for antispam. Spammers don't care about the reputation of the company they bought or stole the data from.
  • alkonaut 5y ago
    Sites likely prefer your canonical/standard email address over any plus version. It would be easy to trim anything after the plus too I guess and just email you at your normal address
  • gumby 5y ago
    I configured my mail server to use _ as a sub mailbox identifier to stop creeps who block +. I assume they are doing it to make sure their precious spam shows up in my inbox.
  • mderazon 5y ago
    Spammers aside, I'm interested to know what strategy different saas companies do in regards to users creating an account with + alias - Do you let users create multiple accounts with the same email but different + alias ? Or do you recognize that it's an alias and say that the account already exists ? Not all email providers support the + notion so you'd have to run domain lookup on some hard coded list
    • megous 5y ago
      Why should they care though? Anyone with a catchall can create 7 billion normal looking addresses under their domain. It's not like it would prevent anything. Also anyone with gmail address can also place dots almost anywhere into the local part, to create another unique address without using a + sign.
      • mderazon 5y ago
        Because of spammers creating garbage accounts on your platform
        • megous 5y ago
          Yeah, but why care about email address format, if it's not going to stop spammers anyway, and you're just risking losing legitimate customers if you mess up trying to mangle part of an address you should not be touching according to the recommendation in the standard?
    • SilverRed 5y ago
      The email spec considers these different emails. It's not a websites job to worry about how an individual host treats them. Gmail also treats . in the user section as useless but most hosts do not.
  • jjav 5y ago
    > This logic is why so many Web sites today won't let you use a plus sign in email addresses, which ruins a really nice Gmail feature. Contrary to popular belief, it is not a gmail feature. I first heard of the + as destination filtering in the very early 90s at CMU where it was broadly used. Every single email address I've had since then has support the same (and notably, apart from a test account, I've never used gmail much, so that's not including gmail).
  • jimktrains2 5y ago
    The plus is a standard feature of email, not a Google specific thing like ignoring dots.
  • ipaddr 5y ago
    gmail != email. Breaking gmail features helps ensure a level playing field.
    • fomine3 5y ago
      It also breaks legit non-gmail address
• deleted 5y ago
  [deleted]
• welder 5y ago
  Yes, in practice I've found the exact same thing. Either use an email validation service or be more restrictive than the RFC. [1] Also prompting "Did you mean bob@gmail.com?" when the user types "bob@gmaail.com" helps a lot with human input errors. [2] [1] https://www.mailgun.com/email-validation/ https://www.mailgun.com/email-validation/ [2] https://www.npmjs.com/package/mailcheck https://www.npmjs.com/package/mailcheck
  • ivraatiems 5y ago
    Except that as someone with an email at a .co domain, I get really irritated when it asks me "do you mean [mydomain].com?" I always have to tell people, in real life, "it's .co, not .com," just in case - humans do this too.
    • welder 5y ago
      Yep, it's solving for the majority case. As long as it doesn't block signup you can just ignore it.
    • cygned 5y ago
      Worse, I had services trying to be smart correcting .co to .com
• WindyLakeReturn 5y ago
  It depends upon where you are validating email input at. For the initial email input, your logic works fine. Once it is applied downstream in a process, it begins to get messy. Someone might do an incorrect email validation that happens to block emails that you have already accepted or which you are importing from a valid source. Someone has already given the example of a login field not allowing them to use the email they signed up with. If such upgrades occur later in a projects life cycle, not only might you have to spend developer's time, you may also have a production outage. Personally, I suggest using some, even if imperfect, validation when gathering the email initially (for the reasons you point out) and then not validating that information any further.
  • paulmd 5y ago
    I actually run into this all the time with passwords using a password manager. Lots of places will accept the creation of a password that's long/complex/etc but then when you actually try to log in with it it won't accept a long password, won't accept certain characters, will silently truncate it and throw an invalid password error, etc. Sometimes disabling Javascript will fix it, sometimes not. I occasionally have resort to using "I forgot my password" until I figure out what the actual underlying requirements of the passwords are.
    • lcuff 5y ago
      Yup! Same thing with the ridiculous verify-my-identify questions. One I encounter all the time is the local community college, which let me use spaces in my answers on creation, but not at entry time. Grrrr.
    • feanaro 5y ago
      I don't encounter this very often myself. So far the only place I've seen this is Paypal. facepalm
    • CodeMage 5y ago
      As a user, I got burned by that several times. Now, when I create a new account somewhere, the first thing I do is log out and try to log back in.
• scotu 5y ago
  I found websites not allowing perfectly valid tlds, so maybe they could be starting not using .com in their regex. (.email)
• the_arun 5y ago
  Instead of every developer implementing validation logic, shouldn't we have validation libraries to take care of this?
• 3np 5y ago
  How about not doing any pre-validation (save for whitespace stripping) and have a validation e-mail (which you should require anyway) take care of any typos? With precious dev time, you can do better by doing less.
  • edoceo 5y ago
    You risk sending a junk message tho, which affects your sender-spam score with other providers. I just make folks email me first.
    • jacobobryant 5y ago
      I do the validation email, works great. Just be sure to protect the sign up form with some type of bot detection (I use recaptcha, but simpler methods are fine for most sites).
• markonen 5y ago
  You absolutely should check the MX records, though. It’s easy and catches tons of typos. I was floored by the difference when I implemented this as pre-check before a Stripe Checkout form.
• jcranmer 5y ago
  The basic rule of thumb I use this: are you implementing email at the MTA level (needing to build/parse RFC 5321 commands or RFC 5322 blobs directly), or are you using email closer to a "universal internet ID" purpose (i.e., application perspective)? If you are in the former category, then yes, follow the spec to the letter. If you're in the latter, then screw the precise guidelines of the spec and reject emails that are very unlikely to be valid: no quoted localparts, no IP address literals. In addition, go ahead and say that email is case-insensitive (more precisely, case-preserving). The hard part is if you're writing an email client, because you're basically forced to have your hands in both pies.
• jcelerier 5y ago
  > Sending emails cost money and bouncing emails affects your sender reputation. that works as long as <RFC>fan 69™@root does not write articles for ZDNet
• vorpalhex 5y ago
  My email address is valid and has been valid for a really long time.. but about 5% of ecommerce shops refuse to accept it.. so they don't get my money. Don't get clever, just follow the spec.
  • lisper 5y ago
    > about 5% of ecommerce shops refuse to accept it That's surprising to me because there is nothing particularly weird about your email address. What exactly do they complain about?
    • mixmastamyk 5y ago
      Quotes included or not?
      • lisper 5y ago
        Not. Obviously, or the rejection ratio would be a lot higher than 5%.
    • brlcad 5y ago
      I would assume because it's only 2-chars (me) and they're filtering anything <3 as invalid.
      • lisper 5y ago
        Yeah, that's what I would guess as well. But there's a big difference between "follow the [ridiculously complicated] spec to the letter" and "don't do obviously stupid things like filter out email addresses with short names". The latter is good advice, the former not so much IMHO.
        • Domenic_S 5y ago
          For a couple glorious years I had a 2-letter email address at a single-letter .com domain. It was rejected a surprisingly small number of times.
• forty 5y ago
  100% agree. This is especially true if the address mail is going to be displayed somewhere for example, it's generally a good idea to limit email address to a sunset of what the RFC allows. To adapt from a famous quote: "all email validation logics are wrong, but some of them are useful" ;)
• unoti 5y ago
  Totally agree with this. Trying to be perfect is a good road to paralysis and not getting things done. Software is like people: it's ok to not be perfect, especially if they're always trying hard to be better and doing good things for society.
• paulmd 5y ago
  This sounds great but what you think is "common" probably isn't. When I was validating myself for Amazon Prime Student, I literally had Amazon refuse to accept my student email in the form first.m.last@myschool.edu because there were two '.'s in the mailbox portion. I had to send an email to support and it was eventually dutifully fixed. And that's not an uncommon format for, you know, school emails. And that's an Amazon engineer who should have known. I imagine there's developers who think "domain.tld" is the only thing valid to put in the domain portion, and that's going to fail with "domain.co.uk", or uncommon TLDs, or other perfectly valid constructs. And sure "it's only x% of the users" but it's a pain in the ass if you're that user. You need to be reasonably permissive. (but on the other hand "myname@..." is not valid either, and that will fail and cost you money as well... hence leading us back to 'just follow the spec')
  • incrudible 5y ago
    This is a false dichotomy. Supporting dots in the email address is trivial, following the spec is not. Furthermore, for a user, it is trivial to get another email address if the one they have causes issues, so it is not really an accessibility issue either.
• throwaway09223 5y ago
  How do you reconcile your concern for the cost of sending emails with your unwillingness to do super basic validation like checking an MX record?
  • nawgz 5y ago
    From where I sit, both of those concerns sit on the same side of fence. GP argues against extensive developer time spent on validating edge-case emails, and says they do so in no small part to avoid having emails bounce etc., as doing MX or other validation to follow-up on these edge-case emails validity within your service does nothing to imply others have put in this same costly and nearly superfluous support, likely leading to more emails bouncing and accordingly degrading the trust in their business as a sender
• toomanybeersies 5y ago
  I also came to the same conclusion some years ago. Or more specifically, my manager brought me around after I tried arguing that it was worth the time to make sure that users could use an IPv6 address as their domain (the lack of periods after the @ would cause `user@2001:0db8:85a3:0000:0000:8a2e:0370:7334` to fail validation) He made a very convincing argument that while an IP address is technically a valid domain, but how many legitimate users were seriously using an IP address as their email domain? (zero)
  • bombcar 5y ago
    You’ll love this SSL cert: https://[2606:4700:4700::1111]/ https://[2606:4700:4700::1111]/
• goto11 5y ago
  But why restrict the syntax arbitrarily in the first place? It is not going to catch the common typos anyway. Most typos will just result in a wrong but still syntactically valid email address.
  • harryf 5y ago
    I’ve always wondered if it’s possible to have a valid email address which is also an SQL injection attack, XSS or similar ?
    • malinens 5y ago
      of course it can: https://security.stackexchange.com/a/106996 https://security.stackexchange.com/a/106996 One of our testers found XSS with email injection (RFC compkiant validation passed) in our website. And we are an e-mail company and should now better :D Never trust user input!
    • goto11 5y ago
      Probably, since the local name part can be basically anything. But the way to prevent injection attacks is not to disallow or sanitize input, it is to escape correctly when interpolating strings in other languages.
• eli 5y ago
  There's also incredibly low stakes in allowing a technically-invalid email address to pass validation. Just use a very permissive pattern (e.g. contains an '@') and be done with it. No matter what you will constantly be getting addresses that conform to the spec but cannot actually receive mail.
• novok 5y ago
  I've run into some places where a subdomain email is not ok, which has been pretty annoying. All email validators should be able to at least take first.last+company@subdomain.example.com
  • macksd 5y ago
    Especially when using a country TLD, suffixes like .co.za are appended to the name of the actual ISP or email provider.
• NikolaNovak 5y ago
  I get your point, but it ends up pretty arbitrary who picks up what part of spec to implement / which part of spec they deem "common sense". e.g. It drives me BONKERS how many systems absolutely reject my single-letter email (~"N@domain.com"), which I created specifically to make it easy and safe to type on mobile devices etc. Others will reject the "+" sign, or underscore, or dot/period, or (brilliantly) two periods or underscors, etc etc etc :=/
  • hwbehrens 5y ago
    My email address ends with the .cc TLD, and the number of websites which say "Did you mean to type .ca?" and then refuse to let me continue without changing it drives me similarly batty.
  • Strom 5y ago
    There are also blacklists for names you can use. My real e-mail is admin@myname.com but Facebook doesn't allow me to use that e-mail, warning me that only personal e-mails are allowed. Paradoxically I ended up using my work e-mail to get around the restriction.
  • ivan888 5y ago
    I don’t even have anything weird going on with mine other than using my own domain with a less common 2 letter country code TLD, but it gets me rejected from signing up to at least a few services per year
  • mobjack 5y ago
    Customer complaints usually determine the spec. If enough people wrote in about not accepting one letter email addresses, then they would likely update the validation. But if customer service tells users to use another email address in that scenario and the customer does that, then it might not be worth the effort to fix it.
    • bombcar 5y ago
      It’s getting to where if you support @gmail.com and no other you’d still get 80% of signups. Better to warm an email doesn’t look right, but let them continue if they want to
• megous 5y ago
  Yes, you should reject it, because the address is invalid. You can't have unquoted <> in the local part. You can't have spaces there either. Your other reasons for breaking interop between systems/languages are just whimsical and invalid. :)
• bradknowles 5y ago
  This falls into the category of the classic “Stupid shit that most programmers believe”. Fundamentally, the problem is that if you’re trying to validate an e-mail address as being correct and you’re not sending an actual e-mail message to that address, then you’re doing it wrong. We learned this lesson back in 1995, people.
• bradknowles 5y ago
  As the Sr. Internet Mail Administrator for AOL in 1995, we quickly learned that the only real way to validate an e-mail address was to send mail to it. Even that wasn’t guaranteed, but anything less was doomed to unexpected failure and misery. And this wasn’t a new lesson then. But at least we were smart enough to listen to the people who had learned that lesson before us. It is now over 25+years later, and I’m sad to see that many people seem to be bound and determined to force themselves to re-learn that lesson the hard way.