Fig 3: Viewing the e-mail headers
In this example, you can see that the message actually originated from a computer named XDREAM and was sent from the mail.augustmail.com SMTP server.
Unfortunately, even the headers don’t always tell you the truth about where the message came from. Spammers and other spoofers often use open relays to send their bogus or malicious messages. An open relay is an SMTP server that is not correctly configured and so allows third-parties to send e-mail through it that is not sent from nor to a local user. In that case, the “Received from” field in the header only points you to the SMTP server that was victimized.
Note: For more information about open relays, see this page.
There Ought to be a Law
In fact, several U.S. states do have laws against e-mail spoofing. Many state anti-spam laws, such as those of Washington, Maryland and Illinois, specifically prohibit using third party mail servers or a third party’s domain name without the permission of the third party. The federal CAN SPAM Act also makes it illegal to send unsolicited e-mail with false or misleading headers or deceptive subject lines.
The problem with such legislation is that by its very nature, spoofing conceals the identity of the sender and thus makes it difficult to sue or prosecute. Nonetheless, it’s a good idea to report deceptive e-mail to the Federal Trade Commission, which has a special e-mail account set up for that purpose at firstname.lastname@example.org. You can also go to the Commission’s Web site and click the “File a Complaint” link.
Although legislation may help to deter some spoofing, most agree that it is a technological problem that requires a technological solution. One way to control spoofing is to use a mechanism that will authenticate or verify the origins of each e-mail message.
The Sender Policy Framework (SPF) is an emerging standard by which the owners of domains identify their outgoing mail servers in DNS, and then SMTP servers can check the addresses in the mail headers against that information to determine whether a message contains a spoofed address.
The downside is that mail system administrators have to take specific action to publish SPF records for their domains. Users need to implement Simple Authentication and Security Layer (SASL) SMTP for sending mail. Once this is accomplished, administrators can set their domains so that unauthenticated mail sent from them will fail, and the domain’s name can’t be forged.
Note: For more information about SPF, see this page. The specifications for SASL are available in RFC 2222.
Microsoft and others in the industry are working on the Sender ID Framework, which is based on SPF and is under review by the Internet Engineering Task Force (IETF). The technology has been the source of some controversy. AOL recently withdrew its support for Sender ID and went back to SPF, and the Apache Software Foundation announced in September that they were rejecting Sender ID. Most of the controversy is due to patent and licensing issues, but there are some technical differences in the two mechanisms: Sender ID uses RFC 2822 specifications for checking header information in e-mail messages, while SPF uses those of RFC 2821 (“mailfrom” verification).
Note: You can read more about the Sender ID Framework here.