3 ms·

You're going to need to quote the RFC(s) that specifically mention bounce tracking to keep marketers in check. My original reply arose because there are times

You're going to need to quote the RFC(s) that specifically mention bounce tracking to keep marketers in check. My original reply arose because there are times when a receiving domain or destination email address can be "temporarily" unavailable. I pointed this out to demonstrate that services that pre-validate recipient addresses upon submission of a form don't take into account transient outages due to any number of valid factors. SMTP was designed with this in mind, i.e. try to re-deliver up to some acceptable threshold and then at some point give up (the hard bounce which is the thing that should cause the "ding", especially if they keep retrying beyond "soft bounces").

johncolanduoni 5y ago
You’re going to need to show me the RFC(s) that specifically mention bounce tracking is for the convenience of marketers. Or maybe give up on every practical aspect of a technology defined in RFC(s) being covered by those RFC(s). SMTP seems a particularly bad example if you expect to be able to write a useful program using only the RFC(s), since every MTA has a whole host of workarounds for non-spec behavior.
- teh_klev 5y ago
  > You’re going to need to show me the RFC(s) that specifically mention bounce tracking is for the convenience of marketers. Perhaps re-read "jusssi"'s comment then mine. I didn't assert that bounce tracking was for the convenience of marketers, or suggest it was mentioned in any way in the RFC's, they implicitly did and I wanted to point out the error in their understanding. > SMTP seems a particularly bad example if you...etc But the central theme of this whole HN discussion thread is about SMTP. If you're interested, sections 6 of RFC5321[0] are where bounce messages are mentioned (just three times in the whole RFC - bouncing, bounced and bounce) with no reference to marketers. See also 6.1: Some delivery failures after the message is accepted by SMTP will be unavoidable. For example, it may be impossible for the receiving SMTP server to validate all the delivery addresses in RCPT command(s) due to a "soft" domain system error, because the target is a mailing list (see earlier discussion of RCPT), or because the server is acting as a relay and has no immediate access to the delivering system. Which brings us back to my original comment, far above, that services that check once if an email address is "valid" using trumail.io or whatever when upon form filling are flawed solutions. [0]: https://datatracker.ietf.org/doc/html/rfc5321 https://datatracker.ietf.org/doc/html/rfc5321

johncolanduoni 5y ago

You’re going to need to show me the RFC(s) that specifically mention bounce tracking is for the convenience of marketers. Or maybe give up on every practical aspect of a technology defined in RFC(s) being covered by those RFC(s). SMTP seems a particularly bad example if you expect to be able to write a useful program using only the RFC(s), since every MTA has a whole host of workarounds for non-spec behavior.

teh_klev 5y ago
> You’re going to need to show me the RFC(s) that specifically mention bounce tracking is for the convenience of marketers. Perhaps re-read "jusssi"'s comment then mine. I didn't assert that bounce tracking was for the convenience of marketers, or suggest it was mentioned in any way in the RFC's, they implicitly did and I wanted to point out the error in their understanding. > SMTP seems a particularly bad example if you...etc But the central theme of this whole HN discussion thread is about SMTP. If you're interested, sections 6 of RFC5321[0] are where bounce messages are mentioned (just three times in the whole RFC - bouncing, bounced and bounce) with no reference to marketers. See also 6.1: Some delivery failures after the message is accepted by SMTP will be unavoidable. For example, it may be impossible for the receiving SMTP server to validate all the delivery addresses in RCPT command(s) due to a "soft" domain system error, because the target is a mailing list (see earlier discussion of RCPT), or because the server is acting as a relay and has no immediate access to the delivering system. Which brings us back to my original comment, far above, that services that check once if an email address is "valid" using trumail.io or whatever when upon form filling are flawed solutions. [0]: https://datatracker.ietf.org/doc/html/rfc5321 https://datatracker.ietf.org/doc/html/rfc5321