Zenon Panoussis writes:
When courier encapsulates a message because of missing 8bit heders
etc and the message happens to be spam, the result is a message
that appears to have originated from the machine running courier
and is still spam. Spamcop and similar RBLs are not smart enough to
see the obvious, so they end up blacklisting the courier machine.
In fact, users of a courier system who report their spam to spamcop
end up getting their own MTA blacklisted. There is plenty of
misformatted spam floating around, so this is bound to happen pretty
often.
The proper solution to this would be smarter RBL scripts, but I doubt
anyone should hold his breath for them. As a workaround however,
courier could append the original Received: headers of corrupted
messages to its own. This would allow the RBL scripts to follow an
unbroken Received chain down to the original spam source and would
prevent courier from getting innocently blacklisted.
Sam, I'm aware that asking you do this is asking you to fix other
people's errors, but we don't live in a just world anyway. Is there
any chance you will?
Sounds reasonable - especially since this is a one-line change.
diff -U3 -r1.37 submit2.C
--- courier/submit2.C 11 Apr 2004 23:14:03 -0000 1.37
+++ courier/submit2.C 8 Jan 2005 00:20:42 -0000
@@ -676,7 +676,9 @@
strcasecmp(h.header, "date") == 0 ||
strcasecmp(h.header, "to") == 0 ||
strcasecmp(h.header, "cc") == 0 ||
- strcasecmp(h.header, "message-id") == 0))
+ strcasecmp(h.header, "message-id") == 0 ||
+ strcasecmp(h.header, "received") == 0))
+
{
const char *p=h.value ? h.value:"";
pgpZTKCxxdyOm.pgp
Description: PGP signature
