[SC-Help] Re: OT side comment Re: Opera won't play with Spamcop, hashes headers

[Mike Easter]

Pop wrote:

<my cite>
>> ..., the newsagent introduces linewraps into it
>> which have to be removed before putting it into the
>> parser.  That is one
>> of many reasons I would rather work with trackers
>> than newsgroup posted
>> spam.

> I know you didn't have me in mind, but ... finally, I
> have an understandable description of when to (or not)
> post a full spam over in .spam.  I've often wondered,
> even looked for the info without success.

The introduction of the wraps by the newsagent is especially bad in
trying to communicate things about a spam and especially of spamcop's
parsing of it because the 'experimenter' like me has to manually remove
the wraps.  The problem, besides the 'minor' inconvenience of having to
do that by hand, is that you/I can't tell the difference between some
'spurious' or confounding linewraps which were in the original spam as
received and can cause parsing trouble somewhere, and the 'known'
spurious and confounding linewraps which were introduced by the
linewrapping newsagent.  Was this particular linewrap in there before?
or was it added by the newsagent?

Linewraps in the body of the spam in the html might cause problems with
resolving something.  They definitely cause problems when they wrap b64
or uuencoded graphics lines;  eg if a person wanted to look at a .gif to
sleuth out something about a spam contained in the graphic.  The removal
of some/many extra added linewraps is a huge pain.  Most of the time the
presumption is that the only thing that matters is the impact on the
wrapping of the Received tracelines, but the problem often goes far
beyond that.

That's one of the reasons some of us were experimenting with using .eml
and .txt attachments in .spam, so as to be able to post a spam in that
newsgroup without causing any wrapping or introduction of new linewraps
which weren't present in the original.  The problem we ran into was that
the performance of the various newsagents was different, especially when
we were crossing operating system lines.  If one were going to post an
'advisory' on posting spams into .spam by attachment, it would have to
have several different 'branches' -- just like the advisories on getting
full headers or submitting things to the webparser vs email with
different agents.

The simplest rule is to 'always' use a tracker, even when it seems like
you can't easily do it.  In the case of this issue we're talking about,
a very useful strategy would have been to parser submit the 'reply' that
the spamcop responder gave when it couldn't parse the item which was
redirected and then to cancel the report.  That way 'we' would be able
to see what the responder received that it responded to which didn't
provide a tracker because the received item is returned 'inside' the
response which doesn't have a tracker.


-- 
Mike Easter
kibitzer, not SC admin