Hacker News new | past | comments | ask | show | jobs | submit login

I use the Gmail "+" hack to mail myself on different topics.

name+ideas@ for app ideas

name+notes@ for random notes

name+writing@ for article ideas

(edit: formatting)






This is also a fun way to use an email-based coupon multiple times...I have yet to find an instance where this fails validation.

Isn’t that just an email hack?

No, not every email server supports it. For example, I know that Office 365 Exchange doesn't support it as I tried it yesterday.

that just means Office 365 has a bug in it, not that using that feature is an "email hack"

the plus syntax is part of the email address specification. any server that doesn't support it is by definition buggy because some mail won't work as expected or designed.


I don't believe that "a@" and "a+tag@" being treated as the same address is part of any specification, but I could be mistaken about this.

Many mail servers have a setting to configure which character to use; some default (or used to default?) to "-" instead of "+".


I think you're talking about just allowing the symbol. The plus sign is an allowed character in the local part in the spec. But mailservers are not required to treat it specially and apparently Exchange doesn't. That seems to be the thrust of the comment you answered to.

Tangentially, what's impossible to solve is all the developers out there who build input forms that will not accept an address with a "+" in it and flag it as invalid. They just use a regex that looks for alphabets, numbers, underscores, dots and one @ sign (I've also seen forms that won't accept any TLD other than .com).

The @ is a regular email character that Google happens to treat specially. Same with them disregarding the period character.

No, it's a gmail-specific "feature". Other mail services may also implement it, I guess.

Yeah, seems there is enough other services that a RFC (under "Subaddress Extension") has been proposed https://tools.ietf.org/html/rfc5233 Maybe it'll get enough steam.

Edit: doesn't mean everyone will use it though! But guess the plus sign in addresses would be more "email" than just email.


It’s nice that they’re trying to standardize it but it’s an impossible standard since you can’t assume that any particular domain adheres to to it so you end up with a whitelist either way.

I guess you're seeing it from the service owners point of view, and in that case it doesn't really matter no? AFAIK, it's for the owners of the email to use the subaddressing, not for others to magically come up and use subaddressing.

So as long as you, the user and owner of an address, know that your domain supports/not supports it, you can use it.

I don't understand who would have to add any allow/blocklists?


It is supported by most mail servers, I guess, and at some time nerds all over the world were heavily promoting this scheme.

I know someone who constantly complained that web site X or company Y are stupid, because they don't follow the RFCs, don't know the syntax of mail addresses, because mail validation in web forms often rejected anything with a plus sign.

The correct answer would have been "don't do it then" or maybe "how about configuring your Exim so that instead of '+' you're using '-' as a separator, but I suppose the complaining was a big part of the fun.


Companies don't follow RFCs, as a rule, bc the only mechanism or means of doing so is if the engineering team implementing the product is aware of the relevant RFCs, and can make a case for following them to the product team. (I.M.Exp.)

There's also a generational memory issue here, and I'm not aware of any C.S./C.E. programs that cover RFCs as part of the core curriculum.


I was using this well before gmail even existed; support is not universal, but it's certainly not a "gmail feature".

https://tools.ietf.org/html/rfc822

(viz. not a gmail-specific feature)


I didn't see where the + had any special significance in RFC822 beyond being part of an atom. foo+a and foo+b could be two different recipients if the server desired.

fair enough



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: