These types have become an increasing menace to our system also. It does
fail some of our Declude tests but it does not get scanned by Spamchk
which would have put them over the hold limit.
Has anyone come up with an alternative test for this? We've just
recently switched over to the Pro version of Declude so I'm not familiar
with filters yet.
On a side note, we subject tag all messages over the hold level with
their spam score. When using Spam Review, there are a bunch of messages
that were held but the subject is listed as one of the header fields.
Usually the ones that are from Yahoo or Hotmail and have
"To:MIME-Version..." or "To:In-Reply-To:MIME-Version..." in the Spam
Review Subject column are legitimate message (false positives) while the
ones that have "X-complaints-To::Content-Transfer-Encoding;" are all spam.
All other Spam Review columns are correct. Anyone have a test/remedy for
this?
John Olden
Systems Administrator
Champaign Park District
Michael Thomas - Mathbox wrote:
Hi,
You might want to look at the entire typical file, in Notepad or Dump it
contents as hex values. I have noticed a similar percentage of spam that has
no carriage returns. Which means that the Declude headers get added to the
end of the file, rather than after the headers. If you also happen to run
invURIBL, you will note that the currently available version does not parse
the message, apparently because at most there is only one "line" in the
message. Don't know if this is your issue, but thought I would point it out
as a possiblity. If that is the case, it was fairly simple to write a test
for it.
Mike
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.