First of all, whether it works or not is for recipients to judge (you seem to lean towards the "it doesn't work" camp).
Now, regarding the "trust" system: the reality is that every e-mail provider that is receiving e-mails chooses its own policy. In general, a provider receiving an e-mail will choose one of:
a) Accepting the e-mail and delivering it to the users' inbox
b) Accepting the e-mail and delivering it to the users' spam box
c) Rejecting the e-mail at SMTP time (at least the sender realizes it hasn't been delivered)
d) Accepting the e-mail and quietly deliver it to /dev/null (the sender thinks it has been delivered, but the recipient cannot ever know about it).
Providers try to be as smart as possible to pick one of the 4 actions above. They do it by using a combination of rules that happen at different times of the delivery process. For instance:
- Noticing that an e-mail is being sent to a non-existing address is easy (a simple check against the addresses db). Hence, most providers do this during the SMTP conversation (and choose option c above when the recipient doesn't exist).
- Checking a zipped powerpoint attachment for viruses may take a while. Hence, most recipients do this _after_ having accepted the e-mail where option c above cannot be used anymore. For viruses, most providers would then go for option (d).
Now, when people speak about the "cold IP" problem they are mostly speaking about one of the common techniques used by large providers (gmail, outlook, etc.). Do note that business domains that use Google Workspace, Outlook 365, etc. are also managed by these large providers.
What these providers do is they keep an internal "reputation" map for every IP (and/or network) that they've received e-mail from in the past. These lists are private and the precise effect they have are treated as internal secrets. However, between the scarce statements made by the providers plus the observed results by many senders the following "common understanding" ensued:
- When they don't have information about an IP, they treat that as a negative signal. No reputation for a specific IP + bad network reputation (for instance, anyone sending e-mails from OVH has bad network reputation because there are many spammers in their network) probably leads to the recipient applying (d) or (b).
- When an IP that hasn't built a reputation starts sending large volumes of e-mail, they treat it as a _very_ negative signal. (d) is practically guaranteed here.
- Unfortunately, most providers _also_ require a minimum sending volume to start tracking the reputation of an IP. This is what bites self-hosted users the hardest (whether they know it or not). For instance: outlook only updates an IPs reputation when that IP has sent more than 100 e-mails (to outlook-managed addresses) that day. If you send less than that, your IP will never build a good reputation there even if the recipients mark every single e-mail you've ever sent as non-spam.
Finally, notice that this is an ongoing arms race. Spammers try to adapt to these measures, and e-mail providers keep changing their techniques, scores and effects. The really bad place you can find yourself in as a self-hoster is the following:
- You've taken all known measures to be a nice sender (you have a reverse record, you send mails through TLS, you've got SPF/DMARC policies setup, you are DKIM-signing your e-mails, you _never_ send spam e-mails, you've signed up for the feedback-loops at all major providers and everything).
- You've had regular e-mail conversations with john@outlook.com over the last few months without any issues.
- You send an e-mail to john@outlook.com and outlook's servers accept it.
- John _never_ receives that e-mail (not in their inbox, not in their spambox, they just don't have it anywhere). For the avid reader: outoook has taken the (d) option above.
Now, if John was expecting the e-mail he will probably complain at some point and you'll both find a way to get the information to him. However, if the e-mail said "Hey, I've convinced my wife to stay at your place for the weekend! We'll arrive on Friday around 8pm." you can imagine how this might be a problem.
The fist time something like this happens you contact outlook's "support" to complain about it. If you are lucky, they reply saying that "your IP qualifies for a temporal exemption" or something like that. Then it doesn't happen to you for a while, until it does. If you are unlucky, the response is on the lines of "send good e-mails and tell your recipients to mark them as non-spam and this will stop happening to you". But the recipients aren't receiving any of you e-mails, so they can't mark them as non-spam. Now you waste a few hours going back-and-forth with the "support agents" until you give up in despair.
Then you see an article on HN about how easy it is to self-host your e-mail. Sadly, you know that self-hosting (to receive e-mails) is easy enough and trouble-free. However, self-hosting to _send_ emails is another story entirely, a story where you are all but a small bug in a world of elephants that may (accidentally or not) stomp you without even realizing nor caring the least bit.
Hi this is pretty right but I’d point out that a provider like gmail never silently drops a message. Viruses that are detected after smtp are stripped from the message and replaced with a warning. By the way viruses are also checked again when you open a message.
Low reputation traffic gets temporary failure codes at smtp time, not silent acceptance nor permanent failure.
What do you mean by ‘a provider like gmail’? Because Outlook.com arguably is a provider like Gmail and it accepts and then silently discards emails all the time. My experience with them is exactly the same as kilburn’s.
Now, regarding the "trust" system: the reality is that every e-mail provider that is receiving e-mails chooses its own policy. In general, a provider receiving an e-mail will choose one of:
a) Accepting the e-mail and delivering it to the users' inbox
b) Accepting the e-mail and delivering it to the users' spam box
c) Rejecting the e-mail at SMTP time (at least the sender realizes it hasn't been delivered)
d) Accepting the e-mail and quietly deliver it to /dev/null (the sender thinks it has been delivered, but the recipient cannot ever know about it).
Providers try to be as smart as possible to pick one of the 4 actions above. They do it by using a combination of rules that happen at different times of the delivery process. For instance:
- Noticing that an e-mail is being sent to a non-existing address is easy (a simple check against the addresses db). Hence, most providers do this during the SMTP conversation (and choose option c above when the recipient doesn't exist).
- Checking a zipped powerpoint attachment for viruses may take a while. Hence, most recipients do this _after_ having accepted the e-mail where option c above cannot be used anymore. For viruses, most providers would then go for option (d).
Now, when people speak about the "cold IP" problem they are mostly speaking about one of the common techniques used by large providers (gmail, outlook, etc.). Do note that business domains that use Google Workspace, Outlook 365, etc. are also managed by these large providers.
What these providers do is they keep an internal "reputation" map for every IP (and/or network) that they've received e-mail from in the past. These lists are private and the precise effect they have are treated as internal secrets. However, between the scarce statements made by the providers plus the observed results by many senders the following "common understanding" ensued:
- When they don't have information about an IP, they treat that as a negative signal. No reputation for a specific IP + bad network reputation (for instance, anyone sending e-mails from OVH has bad network reputation because there are many spammers in their network) probably leads to the recipient applying (d) or (b).
- When an IP that hasn't built a reputation starts sending large volumes of e-mail, they treat it as a _very_ negative signal. (d) is practically guaranteed here.
- Unfortunately, most providers _also_ require a minimum sending volume to start tracking the reputation of an IP. This is what bites self-hosted users the hardest (whether they know it or not). For instance: outlook only updates an IPs reputation when that IP has sent more than 100 e-mails (to outlook-managed addresses) that day. If you send less than that, your IP will never build a good reputation there even if the recipients mark every single e-mail you've ever sent as non-spam.
Finally, notice that this is an ongoing arms race. Spammers try to adapt to these measures, and e-mail providers keep changing their techniques, scores and effects. The really bad place you can find yourself in as a self-hoster is the following:
- You've taken all known measures to be a nice sender (you have a reverse record, you send mails through TLS, you've got SPF/DMARC policies setup, you are DKIM-signing your e-mails, you _never_ send spam e-mails, you've signed up for the feedback-loops at all major providers and everything).
- You've had regular e-mail conversations with john@outlook.com over the last few months without any issues.
- You send an e-mail to john@outlook.com and outlook's servers accept it.
- John _never_ receives that e-mail (not in their inbox, not in their spambox, they just don't have it anywhere). For the avid reader: outoook has taken the (d) option above.
Now, if John was expecting the e-mail he will probably complain at some point and you'll both find a way to get the information to him. However, if the e-mail said "Hey, I've convinced my wife to stay at your place for the weekend! We'll arrive on Friday around 8pm." you can imagine how this might be a problem.
The fist time something like this happens you contact outlook's "support" to complain about it. If you are lucky, they reply saying that "your IP qualifies for a temporal exemption" or something like that. Then it doesn't happen to you for a while, until it does. If you are unlucky, the response is on the lines of "send good e-mails and tell your recipients to mark them as non-spam and this will stop happening to you". But the recipients aren't receiving any of you e-mails, so they can't mark them as non-spam. Now you waste a few hours going back-and-forth with the "support agents" until you give up in despair.
Then you see an article on HN about how easy it is to self-host your e-mail. Sadly, you know that self-hosting (to receive e-mails) is easy enough and trouble-free. However, self-hosting to _send_ emails is another story entirely, a story where you are all but a small bug in a world of elephants that may (accidentally or not) stomp you without even realizing nor caring the least bit.