Yes please. if you have the time and patience
View attachment 34258
Since you ask... There's obviously still a bunch of simplification in here, but hopefully I've got the general ideas across.
The Simple Mail Transport Protocol, or SMTP, was standardised in around 1980 and based on several previous implementations of a similar idea throughout the 1970s. This was obviously long before we had desktop email clients, let alone webmail, when people would log in to an organisation's central computer system to read and send mails. We're concerned here only with the transmission of mail from one server to another, and the software that does that is a Mail Transfer Agent, or MTA.
There are a few other big differences between 1980's Internet and today's, mostly that the connections were slower and less reliable back then, high availability redundant systems weren't really a thing, and also nobody had realised yet that it's possible to lie to a computer. The design they came up with was that when you wrote an email to someone, your end-user mail software (Mail User Agent, MUA) would put it into a queue somewhere on your local system, from which the MTA would pick it up, figure out which system it needed to connect to to deliver it to the right recipient(s), and send it on its way. However, some of these systems didn't have direct access to the entire Internet, and those would need to relay outgoing mail through an intermediate MTA.
The protocol, therefore, allows you to connect to any mail server you can reach, and say "here's an email from
alice@sender.com to
bob@recipient.com, please just figure it out". If that server accepts it from you, it takes on the responsibility of finding the actual destination server responsible for handling recipient.com's emails and passing it on. Obviously once people discovered lying to computers, the spammers loved this because they could just claim to be relaying messages from anyone they wanted, to anyone they wanted, and they could connect to any mail server on the Internet to do it. The vast majority of servers these days don't allow relaying except to domains they're explicitly configured to handle, or from authenticated and trusted users or origin servers, and those that do are quickly shunned by the rest of the Internet. But that's by the by.
Back to the unreliable links, and lack of high availability systems. If a site's email server was being upgraded, or the power was out in that building, or the Internet line was down for any reason, you can't connect to it to deliver mail. To solve that, once an MTA accepts a mail for forwarding, it doesn't immediately try to send it out. It goes into an internal queue of messages pending outbound delivery, and if it encounters a transient failure in delivery, it'll just mark it to try again later. A permanent failure (like the destination server saying that address doesn't exist, for example) results in the message being marked as undeliverable, but remember that by this point (a) the original MUA has long since finished submitting the message and closed its connection, and (b) we might be three server connections away from there anyway. That's why an email that can't be delivered results in another email coming back to you; it's the only way for a remote mail server to get the message back to you that it failed, when all it knows is your email address. But, back to the transient failure. The message will stay in the MTA's queue, pending delivery, and each time it fails it waits a bit longer before retrying, until it reaches a limit, gives up, and bounces it. So that's the first possible reason for a delay: something hiccuped on the Internet, and one of the relaying servers couldn't immediately connect to the destination, so it put it on the shelf to try again later.
Which brings us to the next piece of the puzzle: with all this business of maintaining a queue of pending messages, retrying periodically, and so on, writing a fully compliant MTA is quite a lot of work. Spammers are lazy and don't like to do that, but also spammers prioritise sending out the highest possible number of emails per second and don't care about complying with a technical specification as long as it mostly works. They generally don't implement that sort of logic, so someone figured out that if you were at all unsure of whether to trust an incoming email, you could just immediately return a temporary failure code. A compliant MTA would try again after however long you said, while a spammer would forget it and move on. That's called greylisting, and has been commonly used on very large portions of the Internet - it's a while since I was involved in the details of running any of this, but back then it wasn't uncommon for a server to greylist entire countries that were the source of a lot of spam - the legitimate messages would get through eventually, so it was an easy fix to reduce the volumes of bad stuff getting through.
Nowadays we have lots of add-on systems to try to prove that an email really is from the person in the "From:" header, but because they're all built on a protocol that pre-dates the invention of lying, they're all horrendously complicated, can break horribly if configured wrongly, and if you don't configure them because you're worried about getting it wrong, you get all your mails marked as spam. They do mostly work when everything is done correctly, though.
