SpamCop FAQ

SpamCop Parsing and Reporting Service

Rules - everybody read!

SpamCop does what it does and doesn't do for a reason. Do not make any material changes to spam before submitting or parsing which may cause SpamCop to find a link, address or URL it normally would not, by design, find.

SpamCop does not generate reports for From: or Reply To: addresses. Do not add these within the body of the spam to cause a report for these to be generated.

SpamCop does not decode javascript because it does not have its own javascript interpreter. Unless you can properly decode the javascript, even what you see may not be correct. Do not make any changes to the spam to cause SpamCop to report addresses, links or URLs that are contained within the javascript, decoded or not.

It is okay to munge your personal email address contained within links in the body of the spam, if SpamCop does not find and munge them, with one exception. If a report is going to an abuse desk that does not accept munged reports, you must not make even these minor changes to the spam.

Base64 Encoded Spam - Many spammers are sending messages with Base64 encoded bodies. While SpamCop normally decodes and parses Base64 fine, it is possible for spammers to hide your address or other identifiable information within the encoded body.

For this reason, SpamCop has made an exception to the normal alteration rule for those who know what they are doing:

1. Use a Base64 decoding tool like http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/
2. Remove the encoded Base64 body and replace it with the decoded text
3. A disclaimer must be added to the top of the spam body. (Remember to leave a blank line between the last header line and your disclaimer):

"I have decoded the original Base64 spam body and munged personal details that were in that body. The original body has been replaced with this decoded text. I understand that you may consider this to be altered and not acceptable as evidence"