Re:Complexities of e-mail validation logic
by jchw on Monday May 24, 2021 @12:36PM
(#27266444)
If you can show that "just follow the spec" ends up opening up more opportunity than it closes off, then you can convince people. However, when gmail, outlook, etc. do not allow these zany e-mail addresses, you're going to have a hella hard time convincing me of this unless you are in the 1% of spenders.
[ Parent
| on HN ]
Re:Complexities of e-mail validation logic
by BenjiWiebe on Monday May 24, 2021 @01:39PM
(#27267335)
Do GMail et al actually prevent you from sending to and receiving from these zany addresses? Or merely prevent you from creating one @gmail.com?
Creating one. But when you consider just how many customers are using gmail and outlook addresses, and not to mention, GSuite/fastmail/etc. addresses under custom domains, it makes more sense why rejecting @[email protected] is worth more than allowing some crazy e-mail feature that is effectively not used.
The routing features are obsolete; they go back to the days when lots of email users weren't on the Internet directly and had to use relays. They are still in the spec, yes.
I assume it comes from similar lineage as UUCP paths. Either way, email standards are a bit ridiculous. It needs the kind of rehaul that occurred with HTML5 of looking at what email implementations actually do and pushing them in one direction. I suspect that is not happening ever, so failing that there will probably always be things in the spec that just simply don’t work across everything anymore.