I don’t see your issue with dropping a connection before issuing any SMTP commands. Your problem is with not being able to determine delivery status, right? If your server never even gets to send the message, then you know with 100% certainty that the message wasn’t delivered. And if it’s denied, you know with near certainty that it wasn’t delivered. (I don’t know of any servers that will issue a hard deny after receiving the message and then still deliver it, but that’s technically possible.)
I have read Gmail’s requirements, and I’m familiar with IP reputation. I didn’t mean that they don’t check FCrDNS, I meant that only having that is not enough. They now require both SPF and DKIM. Whereas my service will still accept your messages and not automatically mark them as spam if you only pass FCrDNS.
Generally if you’re getting your emails denied right off the bat, it’s because your IP or the block your IP comes from already has a bad reputation (basically any IP a cloud provider will give you). But yeah, you don’t want to spin up a server on a brand new IP and start firing off 10,000 emails a day, just like you said you don’t want to fire off 10,000 messages a day on WhatsApp. That’s a bad idea for any platform.
WhatsApp is not distributed, nor is it an open protocol, so that’s right out. It will never be the standard.
Gmail only calls the shots for Gmail users. If you never interact with Gmail users, you don’t have to obey any of their requirements. Like imagine a system that you’ve set up to receive notification emails from your own servers. You don’t have to obey anyone’s rules.
Your spoof mail may be perfectly valid for the base ESMTP spec, but there is not one single email provider on the planet that only considers that spec. Email isn’t just one spec. It’s a system that’s made of many specs and common practices, some required, some de facto required, and some optional.
I don’t see your issue with dropping a connection before issuing any SMTP commands. Your problem is with not being able to determine delivery status, right? If your server never even gets to send the message, then you know with 100% certainty that the message wasn’t delivered. And if it’s denied, you know with near certainty that it wasn’t delivered. (I don’t know of any servers that will issue a hard deny after receiving the message and then still deliver it, but that’s technically possible.)
I have read Gmail’s requirements, and I’m familiar with IP reputation. I didn’t mean that they don’t check FCrDNS, I meant that only having that is not enough. They now require both SPF and DKIM. Whereas my service will still accept your messages and not automatically mark them as spam if you only pass FCrDNS.
Generally if you’re getting your emails denied right off the bat, it’s because your IP or the block your IP comes from already has a bad reputation (basically any IP a cloud provider will give you). But yeah, you don’t want to spin up a server on a brand new IP and start firing off 10,000 emails a day, just like you said you don’t want to fire off 10,000 messages a day on WhatsApp. That’s a bad idea for any platform.
WhatsApp is not distributed, nor is it an open protocol, so that’s right out. It will never be the standard.
Gmail only calls the shots for Gmail users. If you never interact with Gmail users, you don’t have to obey any of their requirements. Like imagine a system that you’ve set up to receive notification emails from your own servers. You don’t have to obey anyone’s rules.
Your spoof mail may be perfectly valid for the base ESMTP spec, but there is not one single email provider on the planet that only considers that spec. Email isn’t just one spec. It’s a system that’s made of many specs and common practices, some required, some de facto required, and some optional.