procmail
[Top] [All Lists]

Re: iso-8859-1 in subject field

2003-10-20 16:45:16
At 16:01 2003-10-20 -0700, Carl B. Constantine wrote:
True enough, but you then either have to run it through further spam
checks to find out if it's truely spam (most likely) or just relegate it
to /dev/null whenever you see a message like this since it's most likely
spam. Right?

Well, if the subject is encoded, the body probably is as well - and if not, you've got to wonder WHY NOT?

I realize you posed your "which do you use" question at another lister (though that lister only just now was informed _how_ to decode the string, so they probably don't have a methodology in place for dealing with these messages, nor a firm idea as to how effective that really is compared with any alternative method of doing the same), however, I'll provide some insight from my own experience:

I myself flag messages based on a number of characteristics - a base64 only body is one of those characteristics. So is a subject (or From:) header specifying a foreign-to-me encoding, but that's just because I don't interract on foreign-to-me language lists, and therefore have no reason to expect legitimate messages with such encodings.

I _do_not_ flag a message as spam based on any one characteristic - I used to, but too much snuck through because certain characteristics couldn't be relied upon as a 100% match. By using a "spammishness" score - built up by the various contributory bits, I develop a much more positive feel about the message being spam. This has proven *EXTREMELY* successful for me, and results in very few false pozzies (and those usually still look like spam - lots of "look I'm an idiot and use excessive punctuation!" and the like).

I don't presently use any of the recipes which I provided for addressing the current request, but as I said, I've thought about decoding and replacing the Subject: with the decoded string (shifting the original encoded subject to Old-Subject, as per the invocation of formail that I provided). This means that the message would SUBSEQUENTLY be handled by my spam filters exactly as it is already (well, with the exception that I current extract the SUBJECT, FROM, TO, etc headers to variables at the top of my procmailrc, and presently, the SUBJECT is whatever the original format of it would be -- I should have ORIGINAL-SUBJECT and SUBJECT variables to allow for recipes that might care for the difference).

---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>