SpamCop FAQ

SpamCop Parsing and Reporting Service

Parsing and reporting spam with SpamCop - decisions, problems

If your mail is received at a server which (sometimes) only reports the hostname of the sending server, you should not use that information to track spam. You should not use SpamCop if there is no IP address listed by your server for the source of the spam.

Some mail servers, noteably Groupwise and McAfee's SMTP proxy, do not record the source IP address of the sending server on all messages. Instead, they check the reverse DNS of the sending IP and if present, report that. However, reverse dns is unreliable. It can be set any way the remote site wants. For example, an IP in china could be configured to report a hostname of 'hotmail.com', even if the site has no connection to hotmail.

Only by checking the reverse dns against the forward dns can it be relied upon. For example, if the name 'hotmail.com' is checked, it is found to be different than the chinese host claiming to be 'hotmail.com'. Unfortunately, most mailservers which report only the hostname skip this critical check.

A perfect example of this type of problem is given by the chronically misconfigured telesp.net.br IPs:

$ host 200.148.201.44
44.201.148.200.in-addr.arpa domain name pointer 200-148-201-44.customer.telesp.net.br.
$ host 200-148-201-44.customer.telesp.net.br Host 200-148-201-44.customer.telesp.net.br not found: 3(NXDOMAIN)

Note that the reverse DNS of this host "looks" good, but when we try to figure out the actual IP of that name, we come up empty. Yet, groupwise does not detect this problem, and still reports the hostname instead of the IP (this is a real sample from a real spam):

Received: from 200-148-201-44.customer.telesp.net.br
by smtp; Sat, 22 Mar 2003 23:09:38 -0500

Here we see groupwise reporting a supposedly-verified hostname as the source, even though we've just seen that this hostname is not valid and has no IP address associated with it. Groupwise also does not report it's own version or it's hostname, but that's another issue (and yet another way in which groupwise is broken).

Even asside from these issues, it should be remembered that DNS information can be easily changed. Even if a server does all the required checks, and determines that the IP claiming to be 'server.example.com' really is authorized by 'example.com' to represent it, the IP address of that hostname can be changed at the drop of a hat. So spam received from 'server.example.com' may come from one IP address on day 1, and another on day 2 (or hour 1 and hour 2, or minute..). So reporting by hostname is prone to failure in any case, even if both forward and reverse dns checks are performed. Spammers have not yet started to exploit this last vulnerability, but you can be sure it is only a matter of time before they do.

In practice, servers reporting only by hostname do not do even the minimal forward/reverse checks. They should be replaced, upgraded or reconfigured so that the numeric IP address of the sending server is always included.

Update: We have been told that Groupwise-IA 6.5 and 6.0 with service pack 3 will always report a numeric IP address. Please upgrade if you want to use groupwise headers with SpamCop.
[Append to This Answer]