Back in those days not only was there was no DKIM or SPF, most SMTP servers would accept email from anyone anywhere to anyone anywhere (i.e. 'open relay').
[ Note: Anyone who has been a geek since the 90s, there's nothing you don't already know here ]
> most SMTP servers would accept email from anyone anywhere to anyone anywhere (i.e. 'open relay').
to date that claim, I'd say that by the late 90s at least, true open relays ("from anyone to anyone") were still numerous but carried a huge assumption of being part of spam operations (willingly or through ineptitude), and the most basic spam filtering would reject mail that came out of one.
That said, (before things like SPF) it was easy enough to deliver email to anyone you wanted even if you didn't have your own real email account and SMTP server; you could just look up the destination's MX and connect to it with telnet like that. Since your own random IP probably wasn't blocklisted it would generally be accepted and delivered.
Back then it was still basically considered bad form to reject email simply because the server didn't know where it was from... sadly, if we were still playing by those rules today, I can only imagine how useless email would be. Now it's definitely guilty-till-proven-innocent.
It used to be even more literally so - network mail started off as using FTP to SNDMSG onto a remote system instead of your own. In RFC475, FTP has MAIL and MLFL (mailfile) commands to support this.
I think it's neat that you can still find echoes of this. MAIL worked by just appending to MLFL, separating records with CRLF.CRLF - which is still how Data segments are terminated in SMTP.
Was that before or after UUCP? I know that UUCP carried a command in each message, so you would specify a message body with a tag that says pass it to the mail receiving peogram.
SNDMSG-over-ftp pre-dates UUCP by 5 years, so I think that one's pretty clear-cut.
(Not that I'm claiming anything's original here, ftp & smtp are both in the nwg/ietf family tree, which makes it easy to draw parallels. There's probably 100 other influences.)
> That said, (before things like SPF) it was easy enough to deliver email to anyone you wanted even if you didn't have your own real email account and SMTP server
Yup, this was also a fun exercise. Use nslookup, find the MX records, then telnet to them and deliver some mail destined for domains that email server handled. At that point you're just a slower version of a mail daemon.
In 2006 when FIOS first rolled out they assigned ARIN IP blocks to anyone who requested a static IP and I hosted my own webserver and email server on the web. So for a long time I had my own netblock and my email server had been around for so very long it was in everyone's legacy trusted list. Even gmail never bounced emails from me, despite not having SPF or DKIM and whatever else. Though I did eventually set those up. Only authed users could send email and that was a limited list so my netblock never actually delivered a spam message.
Funny enough I also setup default routing so all non-registered addresses went into a separate mailbox for me and I used the "companyname@mydomain.net" for everything. For many years I knew about every single data breech before anyone else. Often months or years ahead as spam would arrive out of nowhere to that address.
When I finally moved to the bay area to work in tech for real the entire world had changed. You couldn't just get a netblock assignment anymore. And lord knows even if your ISP wasn't deliberately sabotaging your ability to run a server every other system on the internet would assume you're a scamming spammer. I had to give up self-hosting on-prem.
Guess streams was a mixed analog / digital world thing[0]. Is 'curl' the higher order wave crest of LC_NETWORK (aka 'sane' http protocol reference to type bundled 0,1,2 file descriptors)
One can have curl as a bash loadable routine without the need to recompile bash. Headless or not, much more sane[4] than ctypes.sh[1] as curl binary epilog/prolog handle the non-http protocol items within the context of curl module/program. More relevant logic level related to topic beyond http protocol only curl : socat[2] and gnu netcat[3].
Ah, HN doesn't provide a way to conjure up * data tapes (comments not withstanding). Ebnf being battle tested for years & grepping the ANTLER[7] by the horns:
awk interpeting http stream via http protocol[5] via ebnf of http protocol likely to better handle the different protocal layers more gracefully than bash script. Would need to make sure awk is in bit mode and not character/byte mode to avoid line discipline issues / 'stty sane'[4]. Note:
Perl/python provide better layers of abstraction than shell coding for the different levels of protocols used in/with http protocol/ ebnf,Kleene* coding.[6] In shell, having a different command programm for every ebnf set/protocol level vs. awk, different ebnf for each Kleene* protocol level)
> most SMTP servers would accept email from anyone anywhere to anyone anywhere (i.e. 'open relay').
to date that claim, I'd say that by the late 90s at least, true open relays ("from anyone to anyone") were still numerous but carried a huge assumption of being part of spam operations (willingly or through ineptitude), and the most basic spam filtering would reject mail that came out of one.
That said, (before things like SPF) it was easy enough to deliver email to anyone you wanted even if you didn't have your own real email account and SMTP server; you could just look up the destination's MX and connect to it with telnet like that. Since your own random IP probably wasn't blocklisted it would generally be accepted and delivered.
Back then it was still basically considered bad form to reject email simply because the server didn't know where it was from... sadly, if we were still playing by those rules today, I can only imagine how useless email would be. Now it's definitely guilty-till-proven-innocent.