"It's all in the details"
Getting tired of fighting spam? Dumb question, I know. I don't get much spam anymore because I took some simple steps to eliminate it. Still, a new breed of annoying spam crops up and on occasion, needs to be dealt with.
I received an email that was not addressed to me and it was confusing. It was addressed "to:" an address I have blocked. The address I have blocked is, for example, "bugme" and my website mailbox name is, for example, "mydomain.com". If you sent me an email to bugme@mydomain.com it would be blocked at the server and I would never see it. Now, the email that I received was addressed "to:" bugme@host.myhostdomainname.com which I should have never got in the first place because my website mailbox name is "mydomain.com", not "host.myhostdomainname.com" (see header below). So, I wanted to figure out what was going on. I needed to dig in and learn how to understand email headers. After weeks studying the subject I made two important conclusions.
Conclusion one: When reading email headers the quickest and easiest way to confirm legitimacy, is by reading the name and IP values in the first block of the header.
Look at the values in the spam email I "should not have" received, as I said before, sent "to:" bugme@host.myhostdomainname.com.
Received: from xx.xxx.xxx.xx ([200.242.164.2])
by host. myhostdomainname.com (8.12.10/8.12.10) with SMTP id i89SsuYs027676
for < bugme@mydomain.com>; Thu, 9 Sep 2004 11:54:40 -0400
Focus on the specific string: xx.xxx.xxx.xx ([200.242.164.2])
xx.xxx.xxx.xx should give the name or IP number of my website. In this case, it did give my proper IP number (for this example I have used xx.xxx.xxx.xx). The second part of the string, ([200.242.164.2]), refers to the website IP number for the first part of the string. So, although redundant, the string "could" list two IP numbers, but they would have to be the same if the email was legit. In this case of spam, the first part of the string contained the correct IP number and the second part of the string contained the wrong IP number. This confirms that the spammer has manipulated the headers in order to get around or bypass server protocols. Also note "what I saw" in the "to:" field while using my email client: bugme@host.hostdomainame.com. That is not my address but note my address is correct in the header section: bugme@mydomain.com. This suggests that my website hosts' address is being "spoofed". In other words, the spammer is using my hosts' name to send out spam. This can also happen if a virus picked up my hosts' name and is passing it along with the infection.
If it were a legit email address it would look like this:
Received: from mydomain.com ([xx.xxx.xxx.xx])
by host. myhostdomainname.com (8.12.10/8.12.10) with SMTP id ju894llsks89
for < bugme@mydomain.com>; Thu, 9 Sep 2004 11:54:40 -0400
Where, correctly, mydomain.com has the IP number xx.xxx.xxx.xx and host.myhostdomainname.com is the name of my hosts' mail server.
When you understand this information you can apply it to other header sections. The header sections sit on top of each other and the original, where the email started, is at the bottom of the list and the final, where the email ended up, is at the top of the list. Knowing this will give you the details you need if you want to act out against Spammers that have invaded your mailbox. If you want to stop even more junk mail form arriving, which was important to me, you can send this information to the person/ISP/administrator or whomever handles the mail-server and they can change settings so that less spam comes through the server instead of more.
Conclusion two: The most practical way to stop more spam from getting through at the server level is to verify the IP numbers used in the headers.
There are countless ways of doing this and although I do not pretend to fully understand any of them because I am not a systems administrator or a web host, I do think one particular approach makes the most sense. In general, dealing with spam at the ISP level is difficult. Below are two emails submitted to a security mailing list that I receive on a daily bases. The first email reflects what "seems" to be normal procedure. The second email reflects what "seems" to be a good answer toward the elimination of more spam and ties in with the spam email I received.
[From John Doe]
I have never encountered an ISP who imposed this restriction, which is neither easy to implement, nor necessary for the ends the ISP is trying to accomplish.
What the ISPs I've dealt with implement is blocking their non-static ADDRESS SPACE from sending out SMTP directly to outside destinations without relaying through the ISP's SMTP server. This is sufficient to block/prevent:
1. Email viruses/worms that contain their own SMTP engine.
2. Spam sources that contain their own SMTP engine.
3. Compromised/open relays.
4. Servers set up in violation of ToS.
5. Faked headers claiming that a spam/virus/etc originated in their non-static address space, since they can demonstrate that that's not possible.
All without looking at any domain information, either domain name space OR rDNS!
All that checking rDNS tells you is that the sender has valid rDNS information. It doesn't tell you anything about whether the source is or is not doing any of the above five things, especially if, as the ISP, you've set up basic rDNS for your address space (or at least your server) in order to routinely pass such checks implemented on destination servers.
John Doe
-------------------------------
[From Jack Smith]The best way to combat these sorts of spam mailers as far as I am concerned is to setup your email server to do PTR lookups. If the sending domain IP doesn't match the IP where it comes from then don't accept it and send an error back.=20
For example
PTR record. <80.1.119.55> has a PTR record, but does not match HELO
string <hey.com.hk>, Ptrs =3D spr1-walt1-6-0 cust55.asfd.broadband.ntl.comThe message was sent from 80.1.119.55 which resolves to spr1-walt1-6-0-cust55.asfd.broadband.ntl.com but the mail says its coming from hey.com.hk.
Most servers will do this by default anyway, you just need to enable the option to not accept the message.
A company I support is under a spam attack and we have dropped/blocked 147,000 emails in the last 8 days....and they are one of 67 companies I do the network security for. I hope they don't start hitting more of them.
Regards
Jack
-----------------------------------
My final thoughts:
Reading your email headers to diagnose a specific problem is not all that difficult once you take the time to understand it. Like almost everything else, the key word is taking time to do it. If you do, you'll learn more, help others and possibly eliminate more junk mail. Also, if you control mail servers and have the option, it would help lots of folks by using/enabling PTRs.
Read more:
Basic DNS: PTR records and why you care
PTR Record
Still, more to think about...
Ok, due some confusion about who administers what email and what options are available for a specific individual to control what they get, let's look at how email works.
In general, email (electronic messaging) is passed from one computer to another via a modem over a cable/telephone line. Messages are read and composed using a "program" commonly referred to as a MUA or Message User Agent (e.g. MS Outlook Express). It is then passed to a MTA or Message Transfer Agent, a "program" responsible for delivering it to a local network or to another MTA often on another host computer. (On a Unix system "Sendmail" acts as the MTA). MTA's communicate using SMTP (Simple Mail Transfer Protocol), a server to server protocol by which they communicate bit by byte such information as transmission and error detection and correction, data formatting, message syntax, terminal to computer dialogue, character sets and sequencing of messages, etc, etc.
Eventually the message makes it to the recipients mailbox.
The person who uses the MUA controls spam filtering and personal settings and is only limited by the efficacy of the program they are using. This would be true if the MUA is on a PC or web based.
The person who manages (usually a host to the person using the MUA) the MTA controls spam filtering at a global level on the server by selecting/changing inherent protocol options or by manipulating the source code (Sendmail is used 75% of the time- current version is 8.9)
So, considering what's been said so far you can see that there are at least two layers of junk mail control, one at the MUA and one at the MTA. You could also have a third when you have both a web and a PC based MUA. For example, I use Outlook Express and also have OpenWebMail on my website that's provided by my host and MTA. I can filter junk mail on my PC and also use the filters on OpenWebMail. And my host also provides additional software called SpamVault that adds still more junk mail filtering or blockage. Now, add the control/filtering that my MTA has and I'd be surprised if I ever had any email arrive at my mailbox, that I did not want. But, I do.