4 ms·

What about + signs? That's the trick I use.

dbbk 6y ago
They also don't matter, but you already know this
caseysoftware 6y ago
In theory, providers/servers should ignore everything from the + to the @ so that should work just about everywhere else. And since most forms don't filter that out, you can make numerous "unique" addresses connected to a single one. Now odds are, someone is going to respond with the one service where the + becomes significant..
- pricechild 6y ago
  > providers/servers should ignore everything from the + to the @ Why? I'm not sure it has ever been a standard and it's certainly not a default implementation for most providers?
  - moviuro 6y ago
    A quick google search returns https://www.cs.rutgers.edu/~watrous/plus-signs-in-email-addresses.html https://www.cs.rutgers.edu/~watrous/plus-signs-in-email-addr... . Although not standard, its use is "legal"
    - deleted 6y ago
      [deleted]
  - warkdarrior 6y ago
    There is a standard, RFC 5233 on subaddressing: https://tools.ietf.org/html/rfc5233 https://tools.ietf.org/html/rfc5233 Adoption is a mixed bag.
- judge2020 6y ago
  Been using this for a while - https://github.com/johno/normalize-email https://github.com/johno/normalize-email
  - jeffbee 6y ago
    That is a shamefully bad library. There's a million ways this is broken but the worst by far is that it lowercases the local part. Case MUST be preserved in the local part.
    - kevincox 6y ago
      It is fine if you want to try to block duplicate emails, but you should always continue to use the original. But yes, it has false positives and false negatives. I don't think I would call it "broken". But at the end of the day doing this kind of comparison probably raises more questions than it solves.
      - jeffbee 6y ago
        It's not even fine for that. If you assume that JayNesmith@ and JayneSmith@ are duplicates, you're eventually going to annoy someone.
        judge2020 6y ago
        Does MS Exchange or any other relatively big email server allow multiple emails with mixed case? As far as i'm aware all of the big consumer providers (Google, Yahoo, Outlook) don't allow it.
- jeffbee 6y ago
  That isn't the theory. There are almost no rules for the local part of an email address and you must not attempt to "validate" them. Whether a '+' terminates the user name or means nothing is entirely up to the domain operator.
  - Spivak 6y ago
    The exception being when you know that the domain operator supports RFC5233 then you're allowed to be aware of subaddresses.
    - kevincox 6y ago
      That does this RFC even say? I read it twice and it seems to say "Some mail servers may use the part of an email after any character as a subaddress which doesn't affect which inbox a message is delivered to." It seems to only talk about the receiving server and gives no way for the sending server to do anything useful as it doesn't specify the character to use if the receiver implements it at all. I think this is good, I would like to not have senders try to guess anything about the structure of my email, but it makes me wonder what the point of having the RFC at all is.
roel_v 6y ago
That's part of the RFC email address spec. Ignoring .'s isn't, AFAIR.
- teddyh 6y ago
  Nope, the + trick is not standardized. The RFCs only specify that everything before the @ character is specific to the recipient system and Should Not Be Messed With; even case-folding that part of an e-mail address is a no-no, since the recipient system might distinguish case, and the sender has no way of knowing. The + trick arose later, as a feature of certain mail recipient programs like Sendmail and Postfix, and most of these programs allow you to change from + to any character you like.
  - Spivak 6y ago
    Subaddressing or "plus addressing" is a standard defined in RFC5223.
    - jcranmer 6y ago
      Note that RFC5233 doesn't actually standardize the delimiter. It uses "+" "#" and "--" in examples. All RFC5233 does is specify how sieve (a protocol for specifying server-side email filters) can describe filtering on subaddresses. It does not confer any actual interpretation on email addresses, especially since many email providers don't actually use sieve for their email filters.
- pricechild 6y ago
  Which RFC spec? Not 2822?
  - Spivak 6y ago
    RFC5223 defined subaddressing.

dbbk 6y ago

They also don't matter, but you already know this

In theory, providers/servers should ignore everything from the + to the @ so that should work just about everywhere else. And since most forms don't filter that out, you can make numerous "unique" addresses connected to a single one. Now odds are, someone is going to respond with the one service where the + becomes significant..

pricechild 6y ago
> providers/servers should ignore everything from the + to the @ Why? I'm not sure it has ever been a standard and it's certainly not a default implementation for most providers?
- moviuro 6y ago
  A quick google search returns https://www.cs.rutgers.edu/~watrous/plus-signs-in-email-addresses.html https://www.cs.rutgers.edu/~watrous/plus-signs-in-email-addr... . Although not standard, its use is "legal"
  - deleted 6y ago
    [deleted]
- warkdarrior 6y ago
  There is a standard, RFC 5233 on subaddressing: https://tools.ietf.org/html/rfc5233 https://tools.ietf.org/html/rfc5233 Adoption is a mixed bag.
judge2020 6y ago
Been using this for a while - https://github.com/johno/normalize-email https://github.com/johno/normalize-email
- jeffbee 6y ago
  That is a shamefully bad library. There's a million ways this is broken but the worst by far is that it lowercases the local part. Case MUST be preserved in the local part.
  - kevincox 6y ago
    It is fine if you want to try to block duplicate emails, but you should always continue to use the original. But yes, it has false positives and false negatives. I don't think I would call it "broken". But at the end of the day doing this kind of comparison probably raises more questions than it solves.
    - jeffbee 6y ago
      It's not even fine for that. If you assume that JayNesmith@ and JayneSmith@ are duplicates, you're eventually going to annoy someone.
      - judge2020 6y ago
        Does MS Exchange or any other relatively big email server allow multiple emails with mixed case? As far as i'm aware all of the big consumer providers (Google, Yahoo, Outlook) don't allow it.
jeffbee 6y ago
That isn't the theory. There are almost no rules for the local part of an email address and you must not attempt to "validate" them. Whether a '+' terminates the user name or means nothing is entirely up to the domain operator.
- Spivak 6y ago
  The exception being when you know that the domain operator supports RFC5233 then you're allowed to be aware of subaddresses.
  - kevincox 6y ago
    That does this RFC even say? I read it twice and it seems to say "Some mail servers may use the part of an email after any character as a subaddress which doesn't affect which inbox a message is delivered to." It seems to only talk about the receiving server and gives no way for the sending server to do anything useful as it doesn't specify the character to use if the receiver implements it at all. I think this is good, I would like to not have senders try to guess anything about the structure of my email, but it makes me wonder what the point of having the RFC at all is.

roel_v 6y ago

That's part of the RFC email address spec. Ignoring .'s isn't, AFAIR.

teddyh 6y ago
Nope, the + trick is not standardized. The RFCs only specify that everything before the @ character is specific to the recipient system and Should Not Be Messed With; even case-folding that part of an e-mail address is a no-no, since the recipient system might distinguish case, and the sender has no way of knowing. The + trick arose later, as a feature of certain mail recipient programs like Sendmail and Postfix, and most of these programs allow you to change from + to any character you like.
- Spivak 6y ago
  Subaddressing or "plus addressing" is a standard defined in RFC5223.
  - jcranmer 6y ago
    Note that RFC5233 doesn't actually standardize the delimiter. It uses "+" "#" and "--" in examples. All RFC5233 does is specify how sieve (a protocol for specifying server-side email filters) can describe filtering on subaddresses. It does not confer any actual interpretation on email addresses, especially since many email providers don't actually use sieve for their email filters.
pricechild 6y ago
Which RFC spec? Not 2822?
- Spivak 6y ago
  RFC5223 defined subaddressing.