[SpamCop-List] Re: Can SpamCop be improved to handle non-English messages?

[Mike Easter]

Patto wrote:

> I am just a SpamCop user; I do not know what abuse departments do with
> SC complaints, i.e. if they look at the original spam messages, or
> even read them.
>
> Whatever they do, they will not be able to read anything if the
> original spam message is not in a Western character set.  Japanese
> (as this
> sample), Chinese, Russian texts are implicitly replaced with question
> marks.

> P.S. I just noticed that the original Japanese spam message also
> didn't have the charset encoding specified, so my sample is a bit
> flawed.

> Still, if there *is* a charset encoding specified in the spam, I think
> it would be beneficial if the outgoing report would have the same
> encoding (and multibyte characters not being replaced by question
> marks).

'Traditionally' the standard reporting form to abuse desks for 'manual'
reports has been something like what you see in the ng
news.admin.net-abuse.sightings, which is a copy of the contiguous
headers and spambody submitted inline in an email to the abuse desks
under whatever words you are saying to the desk about why you are
notifying them about this issue.

However, that reporting format is sub-optimal for a variety of reasons,
not the least is that typically the emailing process 'formats' the
headers with spurious EOLs which weren't there before, and also the
spambody is 'unrendered' and the unrendered condition is also 'chopped
up' with those same EOLs.

I was recently discussing abuse desk submissions in an EL newsgroup,
where EL has some of its own zany ideas about how it wants something
submitted, namely copying the complete headers and pasting them over a
rendered version of the spambody, which is also a very bad idea, and
requires opening the spam.

The other discussant generally does *not* submit items to abuse desks in
the 'standard' inline configuration, but instead he puts the headers
inline into the body of the item, and then he *attaches* the spam to the
mail -- that is, he is sending a forward as attachment spam to the abuse
desk, but he also has a 'separate' copy of the headers inline in the
body.

By attaching the spam, the original item is quite viewable by any desk
which wants to see it, and it is viewable in its original condition as
received.

All of that being said, there is another argument that I believe that
most abuse desk view very very few of the spam items which are sent to
them.  That is, whether a desk is black hat or white hat -- if black
hat, the desk isn't interested in the report in the first place.  If
white hat, the desk is likely to be familiar with an issue and in the
process of remedying it.

In any case, for a manual report, your issue would be solved by
forwarding the item as an attachment.  That method doesn't work for how
SC displays the 'original' spam by displaying it on a webpage in
unrendered form.


-- 
Mike Easter
kibitzer, not SC admin