Email is totally insecure. Despite this fact, it is relied upon for some of our most critical personal and business communications. Circa 1980, The Simple Mail Transfer Protocol (SMTP) was designed without even a glimmer of what the internet would become. Security was not as paramount a concern as it is now; it never made it into the protocol. Changing this has been an uphill struggle due to the sheer number of mail servers and users who rely on them. Even today, by default, email is sent in plain text (if both servers do not already use SSL), visible to anyone who happens to be listening. Additionally, it is not difficult for anyone to spoof the source address of an e-mail, pretending to be someone they are not. This is a not an uncommon trick for spammers looking to fool users into opening an email from a "legitimate" source.
The problem with spoofing attacks is that the ire of the internet is often pointed back at the perceived sender, i.e. the innocent person whose name is in the "FROM:" field. People will send messages back to a spoofed email notifying them that they may be infected with a virus --that their account has been compromised-- and often threaten them into cessation. The problem here is that the victim of a spoof is getting caught in the middle of the spammer and the spammed. Worse still, with the advent of botnets, the process of sending spam is cheap, so spammers will blindly send e-mails to lists of users who do not exist. The victim of the spoof might receive thousands of bounce notifications in this case.
So what can we do about this? Bounced email alerts sometimes contain details within their message headers that can help identify the message's real origin. You could report the "sender" to their ISP but this is likely a futile task. Commonly the spam will originate from a botnet infected PC of another innocent user (albeit one with poor security practices). If you did manage to notify the user, there are hundreds of thousands of botnet infected systems the perpetrator can be utilizing.
Here is what you can do:
There are several extensions to SMTP that try to prevent such spam exploits:
Sender Policy Framework (SPF): validates the source IP of the sender so that a recipient can check that the user e.g. firstname.lastname@example.org is being sent from a mail server associated with the example.com domain.
Domain Key Identified Mails (DKIM): cryptographically sign outgoing emails enabling trust that the email did originate from the specified email domain.
Unfortunately, these methods are not always supported by the sending or recipient domains and, when they are, the methods are often set to soft fail (warn and allow) rather than block.
All is not lost however; appliances like FortiMail have a range of defensive methods which can be painlessly deployed to protect your network against such attacks including:
FortiGuard Sender IP Reputation Database - a real-time threat database managed by the FortiGuard Threat Research team, used to identify and quickly neutralize known spam and botnet sources.
Reverse path verification, Sender Policy Framework (SPF) and DomainKeys Identified Mails (DKIM) support allows SPF validation to be enforced rather than just logged.
Dynamic Sender Reputation, Denial of Service and Directory Harvesting protection, identifies malicious third parties abusing your mail systems by guessing spam destinations and sending unsolicited bulk email.
Together with a whole range of spam content based detection methods such as FortiGuard spam object fuzzy checksums, dynamic heuristics and URL filtering to identify spam based on its content.
FortiMail can also help defend against the collateral damage associated with spoofing by employing Bounce Back verification which ensures than only bounce messages triggered by a mail originating from a real email from you domain is allowed back into the network.