undefined | Better HN

0 pointsmike-cardwell8y ago0 comments

I'm not going to make assumptions about other peoples use cases. If your use case demands that an email be immediately accepted, then the idea is not necessarily terrible.

Regardless, that's why I said it should be configurable.

0 comments

3 comments · 1 top-level

zAy0LfpBZLC8mAC8y ago· 2 in thread

But it doesn't give you that guarantee. Just because you can connect now, does not mean you can actually send an email later, let alone that particular email. If you want that, then you should provide feedback whether the email that you want to send actually was accepted by the destination server. But even that is probably not a sensible idea: Just because the MX accepted the messages does not in any way guarantee that it will actually be delivered immediately.

mike-cardwellOP8y ago

Nothing you've said is non-obvious. What if the thing you want to do is not "send an email", but is: "test if an address is likely to be able to receive an email". Could you conceive of a scenario where a message pops up to a user stating:

"It looks like you may have entered your email address incorrectly. Are you sure it is ok?"

I'm sure there are lots of use cases. Just because you can't think of one does not mean that none exist.

zAy0LfpBZLC8mAC8y ago

Except that I have seen way too many incompetent uses of APIs that support bad ideas, and so, in reality, everyone would use "the best setting!", aka, all validations switched on, and thus probably lead to all kinds of false positives with hard rejects. See also the common rejection of +-suffix addresses, for example.

For address validation, connection checks are a bad idea. For address validation, turning any temporary failure into something that could end up as a hard reject is a bad idea.

1 more reply

j / k navigate · click thread line to collapse