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.