Comment by yellowapple | Hacker News Reader

Comment by yellowapple | Hacker News Reader

Parent Full thread

> I want that data type to have helpful methods such as .Domain() or .NonAliasValue() which would return gmail.com and foo@gmail.com respectively for an input of foo+bar@gmail.com.

No the hell you don't.

Please please please do not attempt to separate the alias from an email address I submit. It's there for a reason - specifically, to hold you accountable if I experience a sudden influx of spam, and generally to keep things categorized in a world where senders can be sending things from all sorts of domains. Knowing that this is something one would even remotely consider is grounds to never touch anything one has built with a ten-foot pole, and I am now very strongly inclined to look into the author and compulsively scrub any accounts of mine from anything said author might've touched.

I am not exaggerating. The thing before the @ is meant to be opaque. Deeming otherwise for the sake of something so blatantly user-hostile as removing aliases is plain evil, and I will not sugarcoat my condemnation of such practices.

If you're sufficiently sociopathic to have no regard for the morality argument here, then at the very least take heed of RFC 5322 (https://datatracker.ietf.org/doc/html/rfc5322) and recognize that trying to parse any meaning from an email address' local-part is blatantly ignorant of IETF specifications and almost certainly will create bugs. Just don't do it - if not for your users' sake, then for your own.

> "recognize that trying to parse any meaning from an email address' local-part is blatantly ignorant of IETF specifications and almost certainly will create bugs"

I am sorry but this makes no sense. You do realize that the only reason you are able to use aliases is because your email provider chooses to parse meaning out of the supposedly "opaque" text right? If your email provider is free to "break" the spec, so are people you give your id to.

And that is solely the business of myself and my email provider. It's my email address, and therefore I am within my rights to assign whatever internal meaning I so choose. It is absolutely not the business of someone sending an email whether or not that opaque text has further-parseable meaning, and pretending otherwise absolutely will cause bugs (say, when sending emails to mailservers which don't use that alias syntax).

EDIT:

> If your email provider is free to "break" the spec, so are people you give your id to.

Wrong. See above. The email provider is free to "break" the spec because it is the thing in control of that email address and can therefore process it as it sees fit. The people to whom I give an ID are not my email provider, and therefore do not have the same degree of control; consequently, attempting to parse meaning from that opaque string will cause bugs, and also is a dick move which will not be tolerated.

If you're defending this practice because you, too, are parsing the opaque components of email addresses which you do not control, then I will take note to look into your code contributions as well and avoid anything you've touched.

Do. Not. Parse. The. Local-part. For. Aliases. Full stop. It's my email address, not yours. Respect how I enter it, or else remove it from your system entirely. Anything different is asking for bugs and is blatantly disrepsectful to users.

> If your email provider is free to "break" the spec, so are people you give your id to.

There is no reasoning behind this argument; it is purely a verbal construct memetically derived from some inapplicable equality ethic that might make sense in a completely unrelated situation.

The correct application of ethics is that someone agency who is given abc+def@gmail.com, and infers from it that this gives them permission to send email to abc@gmail.com (or, worse, sell that address to harvesters) is behaving unethically.

True enough, as far as it goes. But if you are concerned about subscribing to something twice, you may want to try to check delivery uniqueness. They might be your own addresses.

Of more interest to me, omitted from the presentation--as almost always--is anything about what is disliked about a malformed address. You see this when some web form says it doesn't like your address, but won't say why, leaving you to guess and try things until it is satisfied.

Another example is the password filter that idiotically demands "at least one capital letter, one digit, and one swear character" in your already several-word passphrase, and dislikes your choice of swear characters but won't say so.

> But if you are concerned about sending an e-mail to the same address twice, you need to check delivery uniqueness.

For one, you shouldn't be concerned about that, and for two, you can't tell delivery uniqueness anyway, since someone can have multiple completely different addresses going to the same inbox.

> But if you are concerned about subscribing to something twice

I'm concerned about some service collecting my email address and "accidentally" exposing it to spammers.

> Of more interest to me, omitted from the presentation--as almost always--is anything about what is disliked about a malformed address. You see this when some web form says it doesn't like your address, but won't say why, leaving you to guess and try things until it is satisfied.

That is indeed yet another reason why you should never ever try to parse meaning from email addresses you do not own.

If you don't want to store ill-formed addresses, you need to parse them before you store them.

At issue here is only how much parsing is allowed.

And the extent of that parsing should be in accordance with the relevant RFCs (namely, 5322). Per that RFC, the local-part is an opaque string of permitted characters. Attempting to parse the local-part beyond that when you ain't the one who owns/controls that address is bug-prone at best and user-hostile at worst.

> Another example is the password filter that idiotically demands "at least one capital letter, one digit, and one swear character" in your already several-word passphrase, and dislikes your choice of swear characters but won't say so.

  1> (jp-hash "correct-battery-horse-staple")
  "Pyochu1ponu*fuson"

https://addons.mozilla.org/firefox/addon/jp-hash/

Thank you, installed.

I bought a domain that forwards *@example.com to my personal email address. Easy to set up on google domains.

This ensures everything before the @ is opaque, i.e. foo+bar@gmail.com is now bar@foo.com

Services that block my domain are usually the ones that also block foo+bar@gmail.com

Reply on news.ycombinator.com