Re: Allowing IMAP users to train spam/ham
Hi,
do you have per virtual user Bayes training? or sitewide virtual user?
Because I have a setup like yours and everything goes fine ! In my
setup users move by hand to spam folder FNs and retrieve from spam
folder to inbox FPs ! When they make that movements a script copies
those spam/ham to a sitewide spam or ham folder in each case. Then a
nightly script learn from those spam and ham sitewide folders. Then
deleted from system spam/ham folders but not users folders. They can
do what they want with those mails (delete or not).
Webmail plugins are available to do that work ! they can also make the
copies by IMAP protocol instead of filesystem level access.
Cheers
2012/3/4 LuKreme krem...@kreme.com:
I sued to have a setup where IMAP users could put mail into either SPAM or
Junk mailboxes to have it auto trained and then I had a script that stepped
through and did the training, and it also processed non-new mail in the inbox
as ham.
USERROOT=$HOME;
MAILP=Maildir;
J_PATH=$USERROOT/${MAILP}/.Junk;
S_PATH=$USERROOT/${MAILP}/.SPAM;
H_PATH=$USERROOT/${MAILP}/cur;
if [ `test -d $J_PATH` ]; then
/usr/local/bin/sa-learn --spam --progress $i $J_PATH/{new,cur}
fi
if [ `test -d $S_PATH` ]; then
/usr/local/bin/sa-learn --spam --progress $i $S_PATH/{new,cur}
fi
if [ `test -d $H_PATH` ]; then
/usr/local/bin/sa-learn --ham $H_PATH
fi
This all worked fine, but it was very resource intensive, and it only worked
with the very few shell users. I tried to run it (manually) a few times with
the virtual users, but I ended up with a process that ground the computer to
a halt and generated a bayes database that was massively large (GBs).
So, other than throwing more iron at the problem, is there something I can do
to make this process a little smarter? Make it work with the virtual users
without generating a massive db file?
--
'What can I do? I'm only human,' he said aloud. Someone said, Not all
of you. --Pyramids
Re: Some rules I created for suspicious Javascript practices
Hi, Were these rules, or an improved variant, added to the rules? Regards, Simon. On 16/02/12 01:43, neon_overload wrote: Hello, I have created some rules which I have found to be very effective so far at identifying a certain type of spam that spamassassin otherwises cannot detect. Here are the rules: # highly suspicious practices rawbody LOCAL_UNNECESSARY_UNESCAPE /[+=]\s*unescape\s*\(\s*[']%(6[1-9A-F]|7[0-9A])/ score LOCAL_UNNECESSARY_UNESCAPE 1.7 rawbody LOCAL_UNNECESSARY_STRCONCAT /[+=]\s*[a-zA-Z0-9]+\+[a-zA-Z0-9]+/ score LOCAL_UNNECESSARY_STRCONCAT 0.5 rawbody LOCAL_HIDE_FROMCHARCODE /=\s*String\.fromCharCode\b/ score LOCAL_HIDE_FROMCHARCODE 0.7 rawbody LOCAL_HIDE_URL /h\+tt\+p:\+\// score LOCAL_HIDE_URL 0.7 I have noticed a common trend of spam which has base64-encoded HTML attachments, highly obfuscated with Javascript generating and concatenating links. The above four rules detect patterns which should only be present in Javascript whose intention is to hide its true function (obfuscate itself). The first rule checks for use of unescape() on constants where the characters are just lowercase letters which wouldn't need escaping anyway. The second checks for unnecessary string concatenation with constant strings consisting entirely of letters. It would match =asdf+jkl or +asdf+jkl. The third test checks for substituting another name for the function String.fromCharCode, which would be common when trying to obfuscate strings in Javascript. The fourth test was just a specific pattern I saw in a lot of spam, but is less generic. It looks for the string h+tt+p:+/. This would probably need more alteration to be useful in a more general context. These are unlikely to hit non-spam, even if it contains Javascript, and even if it contains minified Javascript. It is plausible, however, that it may generate hits on discussions that are specifically about how to get through spam filters, such as a discussion between spammers, or makers of spam filters - since these patterns will occur in the context of how to get through spam filters. Use these as you wish! I hereby license them under the WTFPL which is GPL and Apache license compatible. Thomas Rutter -- PGP is optional: 4BA78604 simon @ klunky . org simon @ klunky . co.uk I won't accept your confidentiality agreement, and your Emails are kept. ~Ö¿Ö~
Re: dccifd error
On Mar 4, 2012, at 21:34, xTrade Assessory xtr...@matik.com.br wrote: you can disable the plugin or setup use_dcc 0 in local.cf The plugin *was* disabled in v310, but the errors still showed up in the maillog, which is what started this. As far as I can see, dcc was never running though there was a very old install of it in /var/dcc.
Re: dccifd error
LuKreme wrote: On Mar 4, 2012, at 21:34, xTrade Assessory xtr...@matik.com.br wrote: you can disable the plugin or setup use_dcc 0 in local.cf The plugin *was* disabled in v310, but the errors still showed up in the maillog, which is what started this. As far as I can see, dcc was never running though there was a very old install of it in /var/dcc. use_dcc loadplugin are two different settings use_dcc 0 make sense if the plugin is loaded from somewhere loadplugin ...::DCC you can find in one or more of your *.pre files if the plugin is not loaded you should not get any err msg so you might have loaded it from some other .pre file if it is not loaded you probable should then comment use_dcc Hans -- XTrade Assessory International Facilitator BR - US - CA - DE - GB - RU - UK +55 (11) 4249. http://xtrade.matik.com.br
