F2f spam from antiquity to modern times

Spam fighters and email administrators of a certain age are likely to remember the bad old days of "formmail" spam.

I've talked about formmail before, but if you don't recall, it was a popular perl script commonly used by many websites to enable "fill out this form to send us an email" functionality. The problem? It was easily abused. The destination address was specified as part of the form POST, and there was no restriction or limit on what you put in the destination address field. Meaning it became super easy for script kiddies to call your formmail script to spam many thousands of folks, via your server, likely ending with your server's IP address ending up on a blocklist for being exploitable (and having been exploited).

Right up there with sending spam via open relaying mail servers, it was a huge problem, an early and broad example of IP reputation hijacking. Send your spam via my server, so people think my server is the source of it. Want to block the spam? An ISP has to block me, not the spammer.

This was a problem for years, as almost everybody creating a website would set up formmail on their webserver and forget about it. It took years of many folks broadly and loudly telling the world that formmail was insecure before the thing finally started to get removed from everybody's web servers.

I mention this, because, in my mind, this is pretty much a historical predecessor to "forward to a friend" spam.

Forward-to-a-friend (F2F) is functionality that I think of as an early version of viral content sharing. Implemented by email service providers (ESPs) and content publishers (news sites, for example), you would click the "forward to a friend link," and the version back in the day would literally ask you to fill out your name, email, and maybe a short little message to send to your friend, and then the PROVIDER would actually send an email message to your friend, with your note, and it would be coming from the provider's email server, saying: Dear friend, hi, it's me, I really want you to check out this cool article, product or website page.

This was implemented quite differently than now. Now, when I share an Amazon link with my wife, the share button opens up an email message (or more often, an iMessage), that I then send myself, after being able to add commentary to, or edit, the pre-provided link and message content.

See the difference there? Most F2F sharing functionality today utilize a link that typically opens up the appropriate messaging application to let me choose to hit send and send it as me, from me, to my friend. The old school "back in the day" F2F sharing didn't work this way. Back then, the email service provider or content provider sent the share for you, via their infrastructure.

And that's where the spam issues and reputation risk came from. Like with the "formmail" exploit above, old school F2F allowed bad guys to shovel their unwanted content to third parties, using somebody else's server and sending reputation.

Any time you provide an open, blank field, allowing some random person on the internet to enter text to be sent on to a third party, some number of spammers are going to find it and try to use it to do silly stuff. Spammers loved to fill out legacy F2F forms with spam links. And if it could be automated, even better! They'll happily fire up a script to call your website's F2F function 200,000 times, sending 200,000 spam messages from your server, getting YOU caught in a blocklist, instead of the spammer.

That, quite possibly, is why F2F doesn't typically work that way any more. But it's still something seen every once in a while, like in the recent case of bad guys exploiting Microsoft 365's admin portal to send extortion emails. I share this not to shame Microsoft, but to remind them and all of us to be vigilant, and that we need to remember the bad old days, and be careful when allowing somebody else to submit text that you'll then forward on to a third party, using your own servers, your own IP and domain reputation.

In the Microsoft case, it doesn't look to me like anything was actually hacked or cracked -- it just seems like plain old F2F spam that those of us in email service provider land dealt with (and mostly addressed) years ago. The best practice reminder here: Restrict the ability for someone to submit message text along with the share. Consider eliminating it. At the very least, add a CAPTCHA to slow down potentially abusive utilization. Because you don't want bad guys to be able to borrow your sending reputation and send yucky stuff with your domain in the from address, from your servers.

Some Concrete Advice

I guess this post ended up being a bit of a long rant that boils down to this: Why you should be concerned about F2F (forward to a friend) spam as an abuse vector:

• It can damage your domain and IP reputation. The mail is coming from your domain and server IP address, and is going to pass authentication checks. But it won't be loved by recipients; there will be spam complaints.
• People will annoyingly, falsely assume that you have been hacked. Because, again, the mail is coming from your domain and will pass authentication checks. I don't really consider it akin to hacking, as systems generally were not accessed nor was data breached, but people are often quick to assume the worst.
• It could potentially make you (company or domain owner) open to legal liability under CAN-SPAM. You are, potentially, arguably, the sender of the email in question.
• This isn’t new territory; as I note above, we’ve been down this road before, we know from experience: any time you place an open box to type in along with an ability to submit text or content and a recipient address, some bad guy will try to exploit it at some point. Be prepared!