Help | Site Map
| Text size: - +
(Answer) (Category) SpamCop FAQ : (Category) SpamCop Parsing and Reporting Service : (Category) Parsing and reporting spam with SpamCop - decisions, problems :
Why does submitting to SpamCop results in an error/timeout?

Users are able to reach the SpamCop site and parse/report small emails, but when trying to submit a large spam through the website form they get a time-out error after clicking the "parse" button.

This is a problem experienced by users with firewalls. It may be a personal hardware/software firewall you have employed or, there may be a firewall on your ISP's network "protecting" you that you are not necessarily aware of. To see if you are being affected by this problem, you can submit SpamCop's form with only a few characters filled in. If this works, but submitting actual spam does not, you are probably experiencing this problem.

Simple explanation: Your firewall is misbehaving. Your computer and the internet gateways between your computer and SpamCop are trying to negotiate an efficient way of transmitting data. Your firewall is discarding critical information necessary to this negotiation. Your computer could recover from this problem, but it is giving up instead. This problem does not appear with other sites because you don't normally transmit large chunks of data to other sites, as you do with SpamCop.

Solution 1: Manually set your MTU in your network preferences to something lower. Here is a good article with instructions for various systems. Note the article talks about destination sites which are broken. In SpamCop's case, you encounter the problem if your traffic goes through a particular router on the Accretive network. SpamCop does not limit packet size or ICMP. You can also read Microsoft's Knowledge Base article Q120642 on this subject.

Note that the above article has some incorrect information. The article states that the default MTU for Windows is 1400. The default MTU for Windows is actually 1500. The router in question accepts packets with a maximum MTU of 1496, so setting your MTU below 1496 should correct the problem.

Solution 2: Allow ICMP unreachable packets (type 3), or if you cannot do that, allow all ICMP packets. This will partially compromise your firewall protection (you will no longer be "invisible", but it will not open up any actual security holes.

Technical explanation: When submitting spam to SpamCop, your computer attempts to discover the maximum transmit unit (MTU) by sending large packets with the DF (do not fragment) field set.

Some routers drop the large packet and generate a return ICMP-unreachable (type 3), fragmentation needed (subtype 4) packet.

So far, this is perfectly normal behavior. Your computer should receive the ICMP packet, note the correct MTU and re-send the same packet in smaller chunks. However, that doesn't happen if a firewall is blocking these return packets.

Instead, your firewall blocks the ICMP-unreachable packet, and your computer assumes (perhaps after many retries) that the network connection cannot be established. Theoretically, your computer could assume that the missing packet indicates a problem and fall back to a fail-safe mode. But this dosn't happen either.

ICMP packet types, are documented in RFC 792. Unreachable (fragmentation needed) packets are discussed on page 3. This RFC was published in 1981, before anyone even considered the need for "firewalls". Since this type of network communication has been well documented for over 20 years, there is no excuse for the broken behavior of these firewalls.

Some users may be experiencing this problem for the first time because of recent operating system upgrades which implement this MTU discovery process. Or because of new firewall products. However, the firewall is really the cause of the problem, regardless of when/why if first cropped up.
[Append to This Answer]