4 ms·
1. There are no "obviously invalid email address[es]". 2. Getting billed for sending emails? WTF?
by zAy0LfpBZLC8mAC 10y ago
1. There are no "obviously invalid email address[es]".
2. Getting billed for sending emails? WTF?
- random_rr 10y agoYou haven't worked in email, I presume. Yes, it does cost money to send emails at a large scale.
- zAy0LfpBZLC8mAC 10y agoI am not sure what you are trying to say. Yes, of course, it costs money. Just like serving websites costs money. And just as checking the syntax of an email address costs money (CPUs cost money and need power to run!). Now, how is that an argument for checking the syntax of an email address to avoid sending a single email and seeing whether it bounces?
- scaryclam 10y agoSending a lot of bounced emails is going to get your mailservers reputation tanked, which is not an acceptable tradeoff for removing email validation. Email validation is actually really important if you send even a medium amount of email. Testing by bouncing is not a very good idea, especially since there are a lot of ways to test the deliverability of the email before you try and send it. That's not to say use a regex instead, you can do some simple checks on the domain etc or you can use one of the many services to check for you (for of a fee of course). It's understandable not to know this unless you've run a medium - large site, so here's some best practices to follow: https://documentation.mailgun.com/best_practices.html#email-best-practices https://documentation.mailgun.com/best_practices.html#email-...
- zAy0LfpBZLC8mAC 10y ago> Sending a lot of bounced emails is going to get your mailservers reputation tanked, which is not an acceptable tradeoff for removing email validation. ?!? OK, let's break this down: What could be reasons for an email to be bounced due to an invalid address? 1. Because the address is syntactically invalid: Your own email server will notice and reject/bounce the email. Noone outside your own server will notice. 2. Because the domain doesn't exist or has no inbound mailserver: Your own email server will do the DNS lookup(s) and bounce the email. Noone outside your own server will make any note of that (and you can't find out without doing DNS lookups anyway). 3. Because the localpart doesn't exist: You can't find that out without trying to actually send an email (and consequently risking a bounce). So, what exactly was the point of email validation "without bounces" again? The only thing you can actually do to avoid unnecessary bounces is to make sure your emails have a valid return path and to make sure that you somehow process all the bounces that arrive there to make sure that you don't continue sending emails to addresses that start sending bounces (i.e., that don't exist (any more)). If you send lots of mails, it's probably best to employ VERP for that.
- deleted 10y ago[deleted]
- zeveb 10y ago> There are no "obviously invalid email address[es]". An email address which doesn't validate against the applicable RFC is ipso facto obviously invalid. Validating against the RFC is somewhat complex though.
- zAy0LfpBZLC8mAC 10y ago> Validating against the RFC is somewhat complex though. Hence, not obvious :-) If there is one thing we can learn from all the misguided attempts at validating email addresses that we have seen over the years, it is that it is obviously not obvious which email addresses are syntactically invalid.
- tedmiston 10y agoWith respect to (1), the cases I had in mind as "obviously invalid" is something that doesn't contain all of the required components of an email address. For example, if the user submits their email as "foo" or "foo@bar" or "foo@bar." I should have provided examples as the way I wrote it was definitely ambiguous.
- zAy0LfpBZLC8mAC 10y agoHow about foo@[1.2.3.4] ? "foo", ok, I agree with the blogpost, if there isn't even an @ in there somewhere, maybe it's sensible to catch that and reject it outright. But that's probably about it.
- nulbyte 10y agoBoth "foo@bar" and "foot@bar." are valid email addresses. "bar" can be a host name or a top-level domain name. "bar." is a top-level domain name. That said, "foot@bar." may be valid, but ICANN says it should not be functional. They prohibit dotless domain names (that is, top-level domain names may not have A, AAA, or MX records).