[Scspamcop] Re: Spammer trick to avoid reporting

[Giampaolo Tomassoni]

"Bar0" <nobody at spamcop.net> ha scritto nel messaggio 
news:ga6f67$3g1$1 at news.spamcop.net...
>
> "Giampaolo Tomassoni" <nobody at devnull.spamcop.net> wrote in message 
> news:ga6eqr$26d$1 at news.spamcop.net...
>>I found some spam reported to SC doesn't parse well, sometime even 
>>impeding reporting to the mail source by SC.
>>
>> Here is an example:
>>
>>
>> http://www.spamcop.net/sc?id=z2232090009z22a228d65bcd0740402813c6f95a199az
>>
>> (lines #7 and #8 are separated by CR, not by the CRLF sequence.
>>
>> It seems to me that the effect of this trick is no report at all with QR, 
>> and report to only the mail source with manual reporting.
>>
>> This seems to me a case common enough to be handed by the SC parser. I 
>> guess the SC parser parses header lines according to the (\n|\r\n?) regex 
>> sequence instead of only the Rfc-822 -defined one (\r\n), in order to 
>> cope with most submitting clients. But probably the SC parser should 
>> detect the message's overall delimiter sequence and then use only that 
>> one. This would void the effectiveness of this trick unless someone is 
>> manually submitting from an old Mac OS-9...
>>
>> Giampaolo
>>
>> -- 
>> NEVER send an e-mail to:
>> rainbowl at tomassoni.eu
>>
>
> unless the second received line is under the spammers control, rather than 
> their MTA, it's more likely a "glitch" at the MTA. If the second Received 
> line is made by the spammers  own machinery, nothing in it can be trusted 
> in any case, so the spam source should be chosen from the first Received 
> line.

The problems are:

- QRs with mail like that seem to get totally refused by the parser;
- with manual reports, the parser doesn't parse any URL in the body.

Giampaolo