By dropping silently I meant really litteraly. If you answer to SMTP commands, you are not silent. You essentially say a spammer server that you are a valid target and that they can go on.
It’s not even a question if spammer buy domains to spam.
It’s well known and the reason why commercial products provides a feature to filter too fresh domains.
There are procedures to “warm-up” an IP if you are a large provider and if you don’t do it and attempt to send a lot of mails to Gmail this will not work. It’s not just about DNS records. You could have donne everything perfectly DNS wise and still be blocked by Gmail servers.
You should take a look at the requirements of Gmail for large providers. As far as I recall Gmail does check FcrDNS since last month. On top of more requirements for authentication.
Still you can’t just buy an IP, a server, set MX, SPF, DKIM, DMARC, ARC?, FcrDNS and expect large amounts of mail to go through right away.
And again, any communication method will have a spam problem
The major issue here is that anybody can send any email to whoever. Most communication apps won’t let you do that certainly not like emails.
You can’t open WhatsApp and start spamming the whole world.
You basically can only do that with phone calls and emails ?
So no, SMTP/IMF has rotten foundations. No matter how many (optional) protocol you add on top, it will always be such an hassle to maintain and there will be always people who can’t afford that much effort.
Small businesses having to set that up just to reach Gmail is a big problem that they usually externalize with Outlook365 and so on.
Again, Gmail calls the shots because they are the leader. But on paper my fully unauthenticated mail from Barack.obama is perfectly RFC compliant and legit. These protocols that are essential are optional at the end of the day. They became virtually mandatory because of the spam issue and Gmail pushing in the (right) direction because they have leverage.
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.
By dropping silently I meant really litteraly. If you answer to SMTP commands, you are not silent. You essentially say a spammer server that you are a valid target and that they can go on.
It’s not even a question if spammer buy domains to spam. It’s well known and the reason why commercial products provides a feature to filter too fresh domains.
There are procedures to “warm-up” an IP if you are a large provider and if you don’t do it and attempt to send a lot of mails to Gmail this will not work. It’s not just about DNS records. You could have donne everything perfectly DNS wise and still be blocked by Gmail servers.
You should take a look at the requirements of Gmail for large providers. As far as I recall Gmail does check FcrDNS since last month. On top of more requirements for authentication.
Still you can’t just buy an IP, a server, set MX, SPF, DKIM, DMARC, ARC?, FcrDNS and expect large amounts of mail to go through right away.
The major issue here is that anybody can send any email to whoever. Most communication apps won’t let you do that certainly not like emails.
You can’t open WhatsApp and start spamming the whole world. You basically can only do that with phone calls and emails ?
So no, SMTP/IMF has rotten foundations. No matter how many (optional) protocol you add on top, it will always be such an hassle to maintain and there will be always people who can’t afford that much effort.
Small businesses having to set that up just to reach Gmail is a big problem that they usually externalize with Outlook365 and so on.
Again, Gmail calls the shots because they are the leader. But on paper my fully unauthenticated mail from Barack.obama is perfectly RFC compliant and legit. These protocols that are essential are optional at the end of the day. They became virtually mandatory because of the spam issue and Gmail pushing in the (right) direction because they have leverage.
SMTP on its own is trash.
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.