I used to work with a platform that used smtp for telemetry (ish, event-based rather than stream-based). I'm not sure I'd ever do it again. It was essentially

I used to work with a platform that used smtp for telemetry (ish, event-based rather than stream-based). I'm not sure I'd ever do it again. It was essentially email alerting, but I consider it a close equivalent because the messages were sent machine-to-machine and (hopefully) never surfaced to a human, and they were sent realtime with no rate limiting (sent realtime, where reception is anything but). The single largest issue we had was that customers would use their own email address as the Sender as it was the easiest way to have it accepted by their own network. And then if anything went wrong with our MX, customers would get thousands of bounces back to their address. But the cause of a lot of issues is that mail does not have reliable delivery. The sending device cannot promise the email was delivered, only that its session with an smtp server ended without fault. It can't promise the message was forwarded or delivered (I have seen mailservers accept emails and disappear them), It can't interrogate the chain of custody from end to end. Receiving email is a near-unrelated second path that rarely exists in embedded applications, so the bounce/feedback mechanism is rarely a closed loop in these applications.