[SpamCop-List] Re: Trouble with Help Page

[Mike Easter]

Flwrite wrote:
<my cite>
>> ...it takes a lot more 'talent' and configuration security and
>> 'mindset' security and attitude to /properly/ examine the content of
>> a spam for some purpose than it does to report it 'properly' or
>> carefully without 'opening' it - per se.

>    b) my email program has to open the email to forward it

I consider that condition to be unacceptable.  I would handle my spam
with some other application if I had to 'open' it to forward it, where
open might imply the possibility that my mailuser agent would so some
type of rendering of html.  The classic example of a popular
relationship between a mailuser agent and html rendering is that of
Outlook Express OE and the Internet Explorer IE rendering engine.  Up
until OE6, the most secure an opener of a spam or a virm could be was to
open the item in a very restricted configuration and offline.

> In the original email, the virus was in an attachment.  When I tried
> to forward the email, my anti-virus software caught it an erased it.
> It has given me a sense of security.

Your AV software is not 100% reliable for a variety of reasons.  You
shouldn't be doing anything with a virm which depends upon your AV ware
recognizing. it to protect you.

> Now I recognize virus emails because:

>     b) they run a few tens of kilobytes, vs. spam which is only a few
> kB.

The size of virms is a very useful trait which can be used as part of a
strategy of defense.

> I don't send virus emails to SC anymore.  I've learned to delete the
> attachment before forwarding the headers and body to the offending
> ISP.

Good.  The attachment can also be 'handled' so as to allow you to
characterize the virus contained so as to advise the propagator's
provider.

> On the other hand, "Saving" the virus attachment is interesting.  By
> putting it in a separate file in Windoze Explorer, it's an
> opportunity to run your anti-virus software on it, to confirm it's a
> virus, and get a report on the "name" of the virus.  When you're
> forwarding the other information to abuse at ISP.com, it can be helpful
> if you can also name which virus was attached.

The problem with opening a mail containing a virus in order to save the
attachment is that there have been exploits in which the viral
attachment can be executed without your having to click on it.  Opening
virmails or virms [emails propagating viruses or worms] is very
dangerous, with or without an AV agent.

> Other problems I'm aware of regarding opening mal-email is the
> spyware-graphics.  Possibly one-pixel graphics.  However, SpyBlocker
> does a good job of blocking that spyware from contacting its "home
> base."

Multiple layers of security are valuable;  not opening spam or virms is
a very important layer.  While it is possible to give up that layer and
rely on other layers, such as SpyBlocker or AV agents or restricted
configurations, the more layers you are able to have operational, the
better.

>> I would ideally like to see everyone's spam already identified and
>> sorted for them so that it is in a Junk folder and not the Inbox
>> before they even 'approach' it.
>
> _Almost_ every other email I get is routed to a subfolder by filters
> I have set up.  Anything that doesn't get filtered or identified as
> Junk stays in the InBox, where I scrutinize it as a possible invader.
>
> I've been flagging all mal-ware as Junk - spam, virus emails,
> bouncebacks, etc.  It's still up to me confirm an email is of the
> "Spam" variety before forwarding it to SpamCop.

In a very common scenario, a user does not have to open a spam to submit
it to the parser.  OE allows copying and pasting the item into the
online parser without opening it.  If the item is a 'known' spam
suspect, say by SpamPal's analysis or someother, it is highly likely
that the item is going to have spamlike characteristics in the header
and body.  It is also possible to 'see' the unrendered raw message
source spam and its headers at the time of pasting into the parser [or
an email, for that matter.]

Continuing with the common scenario, it is also common that the spamcop
reporter is a free reporter.  That means that the reporter has limited
options upon being presented the result of the spamcop parse;  that of
approving the report or cancelling it;  and that of unchecking various
notifies.  There is no option to add.

Therefore, there is generally no need for that free reporter who is not
going to be manually notifying alternatively to spamcop to be 'opening'
the spam.  Sufficient evidence for the report is available by looking at
the headers and the unrendered characteristics of the body to approve or
cancel, and generally to leave checked or unchecked the notifieds.  In
recent days we have been discussing issues in which the reporter might
have to open a spam securely in order to notify better, but then we go
back up to my first paragraph on this theme, namely;

>> ...it takes a lot more 'talent' and configuration security and
>> 'mindset' security and attitude to /properly/ examine the content of
>> a spam for some purpose than it does to report it 'properly' or
>> carefully without 'opening' it - per se.


-- 
Mike Easter
kibitzer, not SC admin