One of my back burner projects was to write a mail forwarder which did not store messages. When someone opens an SMTP connection to it, it opens an SMTP connection to the destination and passes through the message, while holding the input connection open. When the message has been delivered, then the sender gets a completion status back. No need to return bounce messages. Any problem at any stage results in an immediate reject to the sender. You don't invisibly lose messages in transit.
Outbound ISP SMTP servers should work that way. This makes email behave much like instant messaging.
Messages with many recipients may need to take a store and forward path. They can be redirected to a slow bulk mail server.
Historically, mail servers are store and forward because the destination might be offline, or on some store and forward UUCP system or something. Today, that's very rare. We don't have to emulate Sendmail forever.
> One of my back burner projects was to write a mail forwarder which did not store messages.
I wrote one of these years ago, as a front-end to my Exchange server. At the time Exchange had this thing where it ALWAYS accepted messages as long as the domain part was an accepted domain, and then it would do a fuzzy match on the mailbox names and dump the mail anywhere it felt matched.
So I had to have this SMTP front-end forwarder to weed out mis-addressed mail... which I eventually added SpamAssassin to as well. It ran for over 10 years without issue.
What I never solved/wrote was the TLS stuff, as it always seemed to complicated to code from scratch.
Right, that's the sort of thing I had in mind. Web site has addresses such as "employeename@example.com", and they forward to some mail server that actually knows if "employeename" is valid. Bogus names result in a status code, not an outgoing bounce message.
I'd reject spam at SMTP time, but also capture the rejected messages, so that users could view them in an online quarantine. Worked pretty well, though I think these days the original perl-based project has been reworked into a nodejs thing:
Outbound ISP SMTP servers should work that way. This makes email behave much like instant messaging.
Messages with many recipients may need to take a store and forward path. They can be redirected to a slow bulk mail server.
Historically, mail servers are store and forward because the destination might be offline, or on some store and forward UUCP system or something. Today, that's very rare. We don't have to emulate Sendmail forever.