On Thu, Dec 25, 2008 at 1:33 AM, James Hess <mysidia@gmail.com> wrote:
RFC1918 addresses should also never be found in mail headers of any messages being exchanged over the internet.. RFC1918 says on page 4:
James, If you want to be dogmatic about it, the must and must nots in RFC2821, 3.8.2 supersede the "should" in RFC 1918. The lines with the 1918 addresses must remain. Pragmatically speaking, when you want to trace a spam, you have to ignore both irrelevant information and intentionally false information. For example, I've seen spams which contain Received lines alleging receipt from a completely innocent network. You have to pay close attention because the only clue that it's a lie is that the Received line doesn't connect with any later ones. The system which allegedly accepted the message doesn't appear in another received line as having sent it to the next server in the chain. As for the incident spam, there's probably an abusable web form on www.iispp.com that some remote spammer has discovered and is using to relay spam. When you see a message which appears to have originated from a generic web server, that's often what's going on. This one has that feel to it. Were it properly programmed, the form would have appended a Received line of its own indicating the source of the http request. Then again, if it was properly programmed it wouldn't be useful for relaying spam in the first place. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004