5 ms·

"Thousands of people use Mailinator everyday, so clearly, its a useful tool that many sites accept" How many of you would have an outright revolt on your hands

"Thousands of people use Mailinator everyday, so clearly, its a useful tool that many sites accept" How many of you would have an outright revolt on your hands from your QA/QE folks if you banned mailinator? I think everyplace I worked would experience this same issue if we did this.

nkassis 11y ago
Could use + in the first part of email such as: youremail+blahblah@example.com to create throwaways. most sites consider those to be different email address then youremail@example.com for account purposes but email service, who respect the rfc, will threat them as the same.
- cdubzzz 11y ago
  I've always found this to be such an odd option. If the concern is people spamming you or selling your email address, how does this really help? Anyone intentionally doing nefarious things can just add a simple regex to strip the garbage.
  - kpcyrd 11y ago
    The parent mentioned QA, it would work for that. For antispam you could add a filter for emails to the direct address without suffix. Personally I prefer aliases, but I think they are very rare on freemailers.
- paulmd 11y ago
  Many sites won't accept email addresses with + in them, because many devs have extremely wrongheaded ideas about validation. I used to have a first.m.last@university.edu address and that one was touch-and-go as well due to the fact that the mailbox had two .'s in it. I actually had to file a support request to get Amazon Student to accept it, even. Nobody from a university with that scheme ever registered before? For the record, the gold standard for email validation is "send a confirmation link and see if they click it". Don't try and get fancy. One other trick is that Gmail ignores .'s in addresses entirely. first.last@gmail.com is the same as firstlast or f.irstlast.
  - aidenn0 11y ago
    I had a first.m.last@university.edu (though I have a really common name so it was actually first.m.last.3@university.edu), but fortunately they also gave us 8 character usernames (which were also our login to our shared hosting on the Sun E6500 machine), but I never used the long form since it was rejected nearly everywhere.
    - PebblesHD 11y ago
      My university address at the moment causes similar issues, it follows the first.m.last@group.uni.edu.au form which throws off lots of input validators.
  - GauntletWizard 11y ago
    My favorite is e-mails with three dots in them. Which is actually not a valid address - the RFC specifies that you must have a valid textual character between dots[1]. However, because of poor decisions by Japanese telcoms, a substantial chunk of their users have 'e-mails' associated with their mobile phones with three dots, breaking goddamn every sensible validation script. [1] https://tools.ietf.org/html/rfc2822#section-3.2.4 https://tools.ietf.org/html/rfc2822#section-3.2.4
    - ori_b 11y ago
      There's only one sensible validation script: "Send an email with a confirm link".
      - GauntletWizard 11y ago
        Sadly, if you're sending e-mail sanely, your mail provider likely validates recipients, and will be annoyed at you if you send them recipients they think are bogus.
        belovedeagle 11y ago
        The relevant rfc (on mobile; don't remember which) specifically states that intermediate servers must not validate mailboxes (local parts). And honestly the domain should be "validated" by the server doing an mx lookup; let dns handle it.
- redthrowaway 11y ago
  This is how we do it, with a predefined string after the first plus. Makes it easy to prune test accounts from the members db.
- matt_kantor 11y ago
  > Could use + in the first part of email [...] email service, who respect the rfc, will threat them as the same. I'm not aware of any RFC that says that mail sent to a+foo@example.com should go to the same mailbox as mail sent to a+bar@example.com (nor am I aware of any RFC that forbids this). I thought that GMail made up that feature and other vendors followed suit since users find it handy.
  - aaronbasssett 11y ago
    RFC 5233 - https://tools.ietf.org/html/rfc5233 https://tools.ietf.org/html/rfc5233
    - TimWolla 11y ago
      > Subaddressing is the practice of augmenting the local-part of an > [RFC2822] address with some 'detail' information in order to give > some extra meaning to that address. One common way of encoding > 'detail' information into the local-part is to add a 'separator > character sequence', such as "+", to form a boundary between the ^^^^^^^^^^^ > 'user' (original local-part) and 'detail' sub-parts of the address, > much like the "@" character forms the boundary between the local-part > and domain. (Highlighting by me) The RFC even gives an example using the hash: > o A message addressed to "5551212#123@example.com" is delivered to the voice mailbox number "123" at phone number "5551212".
- dragonwriter 11y ago
  > Could use + in the first part of email such as: youremail+blahblah@example.com to create throwaways. most sites consider those to be different email address then youremail@example.com for account purposes but email service, who respect the rfc, will threat them as the same. There is no RFC that requires this behavior. Subaddressing within the local part is recognized as a common practice (e.g., in RFC 5233), but nothing requires a system to support subaddressing, or requires a system that does to support a particular separator character or character sequence (e.g., "+") for subaddressing. Email systems are free to implement or not implement subaddressing, and to use any character sequence they want as the separator.

nkassis 11y ago

Could use + in the first part of email such as: youremail+blahblah@example.com to create throwaways. most sites consider those to be different email address then youremail@example.com for account purposes but email service, who respect the rfc, will threat them as the same.

cdubzzz 11y ago
I've always found this to be such an odd option. If the concern is people spamming you or selling your email address, how does this really help? Anyone intentionally doing nefarious things can just add a simple regex to strip the garbage.
- kpcyrd 11y ago
  The parent mentioned QA, it would work for that. For antispam you could add a filter for emails to the direct address without suffix. Personally I prefer aliases, but I think they are very rare on freemailers.
paulmd 11y ago
Many sites won't accept email addresses with + in them, because many devs have extremely wrongheaded ideas about validation. I used to have a first.m.last@university.edu address and that one was touch-and-go as well due to the fact that the mailbox had two .'s in it. I actually had to file a support request to get Amazon Student to accept it, even. Nobody from a university with that scheme ever registered before? For the record, the gold standard for email validation is "send a confirmation link and see if they click it". Don't try and get fancy. One other trick is that Gmail ignores .'s in addresses entirely. first.last@gmail.com is the same as firstlast or f.irstlast.
- aidenn0 11y ago
  I had a first.m.last@university.edu (though I have a really common name so it was actually first.m.last.3@university.edu), but fortunately they also gave us 8 character usernames (which were also our login to our shared hosting on the Sun E6500 machine), but I never used the long form since it was rejected nearly everywhere.
  - PebblesHD 11y ago
    My university address at the moment causes similar issues, it follows the first.m.last@group.uni.edu.au form which throws off lots of input validators.
- GauntletWizard 11y ago
  My favorite is e-mails with three dots in them. Which is actually not a valid address - the RFC specifies that you must have a valid textual character between dots[1]. However, because of poor decisions by Japanese telcoms, a substantial chunk of their users have 'e-mails' associated with their mobile phones with three dots, breaking goddamn every sensible validation script. [1] https://tools.ietf.org/html/rfc2822#section-3.2.4 https://tools.ietf.org/html/rfc2822#section-3.2.4
  - ori_b 11y ago
    There's only one sensible validation script: "Send an email with a confirm link".
    - GauntletWizard 11y ago
      Sadly, if you're sending e-mail sanely, your mail provider likely validates recipients, and will be annoyed at you if you send them recipients they think are bogus.
      - belovedeagle 11y ago
        The relevant rfc (on mobile; don't remember which) specifically states that intermediate servers must not validate mailboxes (local parts). And honestly the domain should be "validated" by the server doing an mx lookup; let dns handle it.
redthrowaway 11y ago
This is how we do it, with a predefined string after the first plus. Makes it easy to prune test accounts from the members db.
matt_kantor 11y ago
> Could use + in the first part of email [...] email service, who respect the rfc, will threat them as the same. I'm not aware of any RFC that says that mail sent to a+foo@example.com should go to the same mailbox as mail sent to a+bar@example.com (nor am I aware of any RFC that forbids this). I thought that GMail made up that feature and other vendors followed suit since users find it handy.
- aaronbasssett 11y ago
  RFC 5233 - https://tools.ietf.org/html/rfc5233 https://tools.ietf.org/html/rfc5233
  - TimWolla 11y ago
    > Subaddressing is the practice of augmenting the local-part of an > [RFC2822] address with some 'detail' information in order to give > some extra meaning to that address. One common way of encoding > 'detail' information into the local-part is to add a 'separator > character sequence', such as "+", to form a boundary between the ^^^^^^^^^^^ > 'user' (original local-part) and 'detail' sub-parts of the address, > much like the "@" character forms the boundary between the local-part > and domain. (Highlighting by me) The RFC even gives an example using the hash: > o A message addressed to "5551212#123@example.com" is delivered to the voice mailbox number "123" at phone number "5551212".
dragonwriter 11y ago
> Could use + in the first part of email such as: youremail+blahblah@example.com to create throwaways. most sites consider those to be different email address then youremail@example.com for account purposes but email service, who respect the rfc, will threat them as the same. There is no RFC that requires this behavior. Subaddressing within the local part is recognized as a common practice (e.g., in RFC 5233), but nothing requires a system to support subaddressing, or requires a system that does to support a particular separator character or character sequence (e.g., "+") for subaddressing. Email systems are free to implement or not implement subaddressing, and to use any character sequence they want as the separator.