Re: Spamcop failing to detect true originating IP

On Tue, 12 Jul 2005 13:45:13 -0400, wskrispy wrote:

> Mike Easter wrote:
>> wskrispy wrote:
>> 
>>>Why is SC suddenly unable, or
>>>suddenly unwilling, to see them?
>> 
>> 
>> We can't see the spam or the parsing unless you post the tracking url.
>> 
>> Put a spam like you are describing into the parser and copy and paste
>> the tracking url from the top of the page here.
>> 
>> Here is your TRACKING URL - it may be saved for future reference:
>> http://www.spamcop.net/sc?id=z784681180z3e1208e47d5955be1126a5a1f83d78e9z
>> 
>> 
> 
> Thanks for the responses guys. It looks like the Spamcop parser was 
> choking on headers crammed into the email by our SpamAssassin. I don't 
> know why Spamcop wasn't previously choking on these... I don't think 
> they've changed. I also don't think any ISP-related stuff has changed.
> 
> In any case, when I trim the source down to the bare minimum with just 
> the originating headers Spamcop is now accepting it (I could have sworn 
> I tried this a few days ago and it choked). Ah well, it would be 
> interesting to get into it more but other duties call.

That is interesting. One of my mail providers uses SpamAssassin, and made a
change in the manner of SA's operation which broke the headers; I believe
by adding an unexpected, and non-RFC-compliant space. When it wrapped in my
MTA, the result was a blank line, denoting the end of the headers, and my
MTA added its two cents worth before putting the email in the mailbox. The
result was "headers in the body", or something like that.

If you control the configuration of SA, make sure that your changes aren't
breaking things. Otherwise, bring the problem to the attention of your mail
administrator.

-- 
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.