5 ms·

Absolutely. I don’t blame people who don’t interact with email for not reading the relevant RFCs, but not verifying control and expecting local part uniqueness

Absolutely. I don’t blame people who don’t interact with email for not reading the relevant RFCs, but not verifying control and expecting local part uniqueness to mean uniqueness of users is obviously busted to anyone who has worked with email. This is Netflix failing to understand part of their product surface. Both the dot behavior and the even more common ‘+’ feature are perfectly spec compliant.

uiri 8y ago
It really bothers me the number of web services which reject email addresses containing '+' in the local part. If you're going to try to "validate" an email address, read the goddamn RFCs.
- siimtalvik 8y ago
  One of the two reasons i changed my recipient_delimiter parameter to '.' The other would be that spammers know that anything after a + is usually optional and strip it. Can't do that when the delimiter is a '.'
  - wyclif 8y ago
    I do the same thing, for the same reason. I haven't A/B tested both options or anything, but I know I've gotten spam where they stripped the "+" parameter.
  - __david__ 8y ago
    I also did that, but I made '_' work, too. Part of me wants to add 'x' as an alternative just for further obfuscation.
- hawktheslayer 8y ago
  I like the idea of adding +spam@gmail.com, but it would be really easy for this to be invalidated by just stripping this from your email before selling it in a mailing list.
  - QasimK 8y ago
    Instead of blacklisting the +spam@gmail.com email, you could whitelist emails like +netflix@gmail.com. You can create a filter so that if it doesn't match the whitelist - including stripping the plus - then it will be automatically binned. I describe this technique in my blog post[0]. I'll warn everyone now though, you'll probably want an email address for real people that you trust (like +friends@gmail.com). Also, you'll rarely have to email companies, but it is a pain if you need to do it from the +plus email. [0]: http://iamqasimk.com/2016/10/16/absolutely-zero-email-spam/ http://iamqasimk.com/2016/10/16/absolutely-zero-email-spam/
    - hawktheslayer 8y ago
      Thanks for sharing! You thought this one through more thoroughly than I have. And your closing line about it being impractical is unfortunately all too true.
    - thegeomaster 8y ago
      >Also, you'll rarely have to email companies, but it is a pain if you need to do it from the +plus email. This is absolutely true, and it's very painful. I sadly now recommend against using +plus addressing if there is a possibility you'll need to get in touch with support for a website for any reason, and I have a cautionary tale. So many websites have incredibly shitty "security features" and incredibly shitty code. I had an account with a payment processing website with myname+website@mydomain.tld. They sent me an email requesting some additional info about a payment I was to receive in order for it to clear. I responded from myname@mydomain.tld. The automated system helpfully informed me that they can only accept email from the email in the account (argh). So I sigh, go over to the website, and change my email to myname@mydomain.tld. No luck---there's already an account with that email. OK, I might have created one before and don't remember. I try to login with this info, hoping I can delete that account, but can't seem to get the password right, and it's not saved anywhere. So I use the "Forgot Password" feature. Oops, it looks like I haven't finished the onboarding process with that account, and so I can't reset the password on it (who even thought of this?!). So I make an alias of website@mydomain.tld, change my email to that, and try responding from that alias. No luck. Turns out that you have to actually use the address they originally sent the email to. If you've changed it, oh, that's too bad---please open a support ticket with us. It took around 7 days of back-and-forth and waiting for responses from support (lots of waiting!) to explain that I'm just trying to respond to an email they sent me, and a lot of canned responses from people completely misunderstanding what my problem is. Would not recommend to anyone.
- f2n 8y ago
  Try using an email address with .wedding or .solutions TLD. Loads of absolutely brain-dead sites refuse to allow them, sometimes they validate by TLD length (all TLDs are 2 or 3 characters, apparently) or other times rejection TLDs they haven't whitelisted.
  - rsync 8y ago
    "(all TLDs are 2 or 3 characters, apparently)" Which is odd, since there are some very, very old TLDs that are "long" ... I am thinking of .bitnet, .uucp and even the old .ussr[1] ... [1] "Initially, before two-letter ccTLDs became standard, the Soviet Union was to receive a .ussr domain." (https://en.wikipedia.org/wiki/.su https://en.wikipedia.org/wiki/.su)
    - ameliaquining 8y ago
      Those were never in widespread use in the email era. Anyone who knows about them is already technically sophisticated enough not to make this mistake.
- emodendroket 8y ago
  Someone definitely just copied a regex from StackOverflow (frankly if you actually look at the RFC a regex seems like a crazy approach).
eric_h 8y ago
I was under the impression that literally anything goes on the left side of the @. It’s all up to the individual mail server
- AndrewSnow 8y ago
  IIRC, not quite literally, but pretty close. The email RFCs in general tend to be much less constrained than one might expect.
  - tajen 8y ago
    Yup. Even spaces are allowed if you put double quotes around the local part: “Kevin Spacey”@example.com. It’s really surprising, there’s very little that can be verified if you strictly follow the RFC.
    - MichaelGG 8y ago
      This is a common issue with text based formats and ietf/RFCs. HTTP allows comments in some headers. And allows line breaks: H: hi Mom Is the same as H: hi Mom Bets on how many http clients and servers get this right? Without losing speed? My guess is when you're not responsible for ensuring compatibility or having to deal with writing robust, fast, code, the temptation to be cute with your format overtakes things.
      - loeg 8y ago
        I expect all commonly used HTTP clients (Chrome, Firefox, IE, even libcurl) and servers (Apache, Nginx, does IIS still exist?) get this right.
        MichaelGG 8y ago
        I, too, would expect that the most common pieces of software with massive amounts of engineering time invested get it right (but almost certainly with a performance hit). But I'd be unsurprised to find that one doesn't handle the http parsing spec correctly somewhere. The issue is that such a spec is entirely unneeded and overly complicated. No benefit, only downsides. And for something as simple as basic parsing rules! Not even getting into anything that should be difficult.
sandov 8y ago
No one's saying that they aren't spec compliant, the writer is complaining that google doesn't tell its users that their inbox will include emails for more than 1 address.
- saghm 8y ago
  When I get an email to an address that isn't exactly the same as mine (e.g. due to extra dots in it), desktop gmail does actually show a small informational link next to the receiving address saying something along the lines of "yes, this really is you; click here to learn more". I haven't seen this on mobile, although I use the Inbox app, so it's possible that this it's there on the vanilla gmail app
chrisweekly 8y ago
Yeah they're both spec-compliant, but (IIRC, as of a few months ago), in gmail at least, there's a huge difference: janedoe+acme@gmail.com resolves to janedoe@gmail.com, and the "+acme" is simply a useful bit of metadata for Jane to track the provenance of the sender's mailing list. the "+" and anything following it are ignored. It signifies an optional suffix. Whereas janedoe.acme@gmail.com resolves to janedoeacme@gmail.com -- a completely different address than janedoe@gmail.com. The "." is simply ignored as if it weren't there, making j.anedoeacme and jane.doeacme and janedoe.acme equivalent. Yeah this is specific to how gmail chooses to handle these spec-compliant-though-often-mishandled characters, but anyone who works with email professionally absolutely has to come to terms with how gmail works.

uiri 8y ago

It really bothers me the number of web services which reject email addresses containing '+' in the local part. If you're going to try to "validate" an email address, read the goddamn RFCs.

siimtalvik 8y ago
One of the two reasons i changed my recipient_delimiter parameter to '.' The other would be that spammers know that anything after a + is usually optional and strip it. Can't do that when the delimiter is a '.'
- wyclif 8y ago
  I do the same thing, for the same reason. I haven't A/B tested both options or anything, but I know I've gotten spam where they stripped the "+" parameter.
- __david__ 8y ago
  I also did that, but I made '_' work, too. Part of me wants to add 'x' as an alternative just for further obfuscation.
hawktheslayer 8y ago
I like the idea of adding +spam@gmail.com, but it would be really easy for this to be invalidated by just stripping this from your email before selling it in a mailing list.
- QasimK 8y ago
  Instead of blacklisting the +spam@gmail.com email, you could whitelist emails like +netflix@gmail.com. You can create a filter so that if it doesn't match the whitelist - including stripping the plus - then it will be automatically binned. I describe this technique in my blog post[0]. I'll warn everyone now though, you'll probably want an email address for real people that you trust (like +friends@gmail.com). Also, you'll rarely have to email companies, but it is a pain if you need to do it from the +plus email. [0]: http://iamqasimk.com/2016/10/16/absolutely-zero-email-spam/ http://iamqasimk.com/2016/10/16/absolutely-zero-email-spam/
  - hawktheslayer 8y ago
    Thanks for sharing! You thought this one through more thoroughly than I have. And your closing line about it being impractical is unfortunately all too true.
  - thegeomaster 8y ago
    >Also, you'll rarely have to email companies, but it is a pain if you need to do it from the +plus email. This is absolutely true, and it's very painful. I sadly now recommend against using +plus addressing if there is a possibility you'll need to get in touch with support for a website for any reason, and I have a cautionary tale. So many websites have incredibly shitty "security features" and incredibly shitty code. I had an account with a payment processing website with myname+website@mydomain.tld. They sent me an email requesting some additional info about a payment I was to receive in order for it to clear. I responded from myname@mydomain.tld. The automated system helpfully informed me that they can only accept email from the email in the account (argh). So I sigh, go over to the website, and change my email to myname@mydomain.tld. No luck---there's already an account with that email. OK, I might have created one before and don't remember. I try to login with this info, hoping I can delete that account, but can't seem to get the password right, and it's not saved anywhere. So I use the "Forgot Password" feature. Oops, it looks like I haven't finished the onboarding process with that account, and so I can't reset the password on it (who even thought of this?!). So I make an alias of website@mydomain.tld, change my email to that, and try responding from that alias. No luck. Turns out that you have to actually use the address they originally sent the email to. If you've changed it, oh, that's too bad---please open a support ticket with us. It took around 7 days of back-and-forth and waiting for responses from support (lots of waiting!) to explain that I'm just trying to respond to an email they sent me, and a lot of canned responses from people completely misunderstanding what my problem is. Would not recommend to anyone.
f2n 8y ago
Try using an email address with .wedding or .solutions TLD. Loads of absolutely brain-dead sites refuse to allow them, sometimes they validate by TLD length (all TLDs are 2 or 3 characters, apparently) or other times rejection TLDs they haven't whitelisted.
- rsync 8y ago
  "(all TLDs are 2 or 3 characters, apparently)" Which is odd, since there are some very, very old TLDs that are "long" ... I am thinking of .bitnet, .uucp and even the old .ussr[1] ... [1] "Initially, before two-letter ccTLDs became standard, the Soviet Union was to receive a .ussr domain." (https://en.wikipedia.org/wiki/.su https://en.wikipedia.org/wiki/.su)
  - ameliaquining 8y ago
    Those were never in widespread use in the email era. Anyone who knows about them is already technically sophisticated enough not to make this mistake.
emodendroket 8y ago
Someone definitely just copied a regex from StackOverflow (frankly if you actually look at the RFC a regex seems like a crazy approach).

eric_h 8y ago

I was under the impression that literally anything goes on the left side of the @. It’s all up to the individual mail server

AndrewSnow 8y ago
IIRC, not quite literally, but pretty close. The email RFCs in general tend to be much less constrained than one might expect.
- tajen 8y ago
  Yup. Even spaces are allowed if you put double quotes around the local part: “Kevin Spacey”@example.com. It’s really surprising, there’s very little that can be verified if you strictly follow the RFC.
  - MichaelGG 8y ago
    This is a common issue with text based formats and ietf/RFCs. HTTP allows comments in some headers. And allows line breaks: H: hi Mom Is the same as H: hi Mom Bets on how many http clients and servers get this right? Without losing speed? My guess is when you're not responsible for ensuring compatibility or having to deal with writing robust, fast, code, the temptation to be cute with your format overtakes things.
    - loeg 8y ago
      I expect all commonly used HTTP clients (Chrome, Firefox, IE, even libcurl) and servers (Apache, Nginx, does IIS still exist?) get this right.
      - MichaelGG 8y ago
        I, too, would expect that the most common pieces of software with massive amounts of engineering time invested get it right (but almost certainly with a performance hit). But I'd be unsurprised to find that one doesn't handle the http parsing spec correctly somewhere. The issue is that such a spec is entirely unneeded and overly complicated. No benefit, only downsides. And for something as simple as basic parsing rules! Not even getting into anything that should be difficult.

sandov 8y ago

No one's saying that they aren't spec compliant, the writer is complaining that google doesn't tell its users that their inbox will include emails for more than 1 address.

saghm 8y ago
When I get an email to an address that isn't exactly the same as mine (e.g. due to extra dots in it), desktop gmail does actually show a small informational link next to the receiving address saying something along the lines of "yes, this really is you; click here to learn more". I haven't seen this on mobile, although I use the Inbox app, so it's possible that this it's there on the vanilla gmail app

chrisweekly 8y ago

Yeah they're both spec-compliant, but (IIRC, as of a few months ago), in gmail at least, there's a huge difference: janedoe+acme@gmail.com resolves to janedoe@gmail.com, and the "+acme" is simply a useful bit of metadata for Jane to track the provenance of the sender's mailing list. the "+" and anything following it are ignored. It signifies an optional suffix. Whereas janedoe.acme@gmail.com resolves to janedoeacme@gmail.com -- a completely different address than janedoe@gmail.com. The "." is simply ignored as if it weren't there, making j.anedoeacme and jane.doeacme and janedoe.acme equivalent. Yeah this is specific to how gmail chooses to handle these spec-compliant-though-often-mishandled characters, but anyone who works with email professionally absolutely has to come to terms with how gmail works.