Proper way to handle misidentifiedspamsite-wide?

Rose, Bobby brose at MED.WAYNE.EDU
Thu Jun 27 18:38:12 IST 2002

Add this to your file and it will create a single message
file containing the full message and the SA headers.  Then you can "cat
* > ~/mail/spam" and check it with pine.  You can then use to also
report to razor/dcc in bulk.

> #Bobby added $mID for saving report
<     = SAForkAndTest($SAspamtest, $spammail);
>     = SAForkAndTest($SAspamtest, $spammail, $mID);
<   my($Test, $Mail) = @_;
> #Bobby added $mID for saving report
>   my($Test, $Mail, $mID) = @_;
> #Bobby's added code
>     my $SAScore  = $spamness->get_hits();
>     my $SAReqHits =  $spamness->get_required_hits();
>     #Log::InfoLog("SpamAssassin score $SAScore of $SAReqHits");
>     if ($SAScore >= $SAReqHits) {
>       $spamness->rewrite_mail ();
>       my $SARewrite = $spamness->get_full_message_as_text();
>       local(*DOUT);
>       open(DOUT, ">>/var/spam/queue/spr$mID") or Log::DieLog("Failed
to create copy of spam message spr$mID");
>       print DOUT $SARewrite;
>       close DOUT;
>    }

-----Original Message-----
From: John Goggan [mailto:jgoggan at DCG.COM] 
Sent: Thursday, June 27, 2002 1:06 PM
Subject: Re: Proper way to handle misidentifiedspamsite-wide?

Julian Field wrote:
> You get the qf and df "mqueue" files so you can drop them straight 
> back into the queue if you actually want them to be delivered.

Yes, but then looking through them to detect non-spam mistakes is then
difficult, yes?  I've suddenly got a few hundred qf files to go checking
subjects in -- there must be a better way?

> Under European law you ain't supposed to be manually editing other 
> people's mail, its an infringement of the Data Protection Act.

Well, it's pretty much MY mail.  Most of what I'm sending using "store"
is mail to various catch-all accounts plus some admin accounts.
Basically, it is all "mine" -- or at least the company's and I have full
rights to go looking through it...

> You can find most non-spam by just reading the subject lines, which 
> are contained in the qf files.

This just seems odd to me.  It basically seems that doing any action
other than "deliver" is just a problem.  If you do "delete", then you're
going to lose some non-spams.  If you do "store" because you want to
look through it for mistakes later, it seems that just trying to wade
through the hundreds of qf files is such a pain as to not be worth it.

Again, I'm surprised that people are doing this...  Hmmm...

> Again however, this is almost certainly a breach of the DPA.

Nope.  Not in this instance.

> Writing code in the full knowledge that it would break laws if used is

> rather shaky ground, and I don't really want to go there if I can 
> avoid it.

Assuming that certain options, if used, must be illegal just seems
incorrect to me.  There are certainly many legal uses for what I was
planning to do. But, I understand your concern...

> I appreciate that many/most of you live outside the scope of these 
> laws, but I don't and I'm the one producing the "package".

Agreed.  It is indeed your project and I therefore respect that.  I just
see legitimate uses for such features.  Especially when the process
involved as it is now seems almost worthless.  I feel like "deliver" is
the only usable spam option unless people are doing a lot of custom work
with things that are "stored."

Of course, making it "easier" would then go against your concerns for
the DPA.  Even though what I was doing would certainly not be against it
-- even if I lived where it applied.  :)

Ok -- well -- I guess I'll stick with "deliver" for now and wade through
it that way.  :(

Thanks for your time and responses!

 - John...

More information about the MailScanner mailing list