Re: Better phish detection
Dave Funk wrote: As an admin on a site that regularly gets hit with phish attacks, I can answer that. The forms are most often a web-page, which are: 1) forms hosted on Google-Docs or legit servey sites.[0] 2) sites hidden behind URL-shorteners would you want to submit details to a site with a redirected url? Probably SA is not the right tool here, because it would have to mark detected mail as caution 3) forms hidden in pages hosted on compromised legit sites.[1] 4) forms attached to mail messages, the attachments obfuscated by being MIME-typed as application/octet-stream but the file names ending in .htm so SA won't try looking inside but mail-clients -will- automagically just do the right thing(tm) [2] sounds like a potential improvement on any filter: try to identify attachments by their first 512 bytes rather than by filename or mime type 5) URIs that are obfuscated by being buried inside javascript that dynamically generates them at message open time.[3] If there was a caution rather than just potential spam mark, it should certainly mark javascript [3] Damn people who insist that HTML should be acceptable everwhere. I tried creating rules that blacklist email containing javascript but there's legit sites (purchase confirmations, reservation notices, etc) that insist on doing that crap. My own way of life: a) messages that do not list me in either To or Cc (that is most mailing lists) must come from whitelisted senders, otherwise they do not even make it to SA b) I read mails on a text interface with a nice read this one message in browser pushbutton c) the actual sending email address should not be completely obscured in the mail reader, in favor of a display name I have implemented b) at the company where I work. For more than 50 % of mails handled by average staff, the same pushbutton means open in application. When this project started a decade ago, I could not find a way to associate that particular class of mails (identified by sender, subject line, and mime-type) with an application in either Netscape or Outlook. So the incentive is: have better workflow for the majority of messages, in exchange for a need to hit view in browser for some messages
Re: Automatic rule generation Re: Better phish detection
On Sun, 11 Mar 2012, dar...@chaosreigns.com wrote: The software used to generate the sought rules, or perhaps an old version of it, is in the spamassassin source tree. You can feed it a folder of known non-spams, and a folder of known spams, and it'll auto-generate rules that hit the spams but not the non-spams. I've been collecting phish spams for quite a while looking to do something for phishing similar to the ADVANCE_FEE GA-evolved rules, I've just never gotten the round tuits. If you do start doing sought_phish I'd be more than happy to contribute my corpus and continue to keep it fresh. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Failure to plan ahead on someone else's part does not constitute an emergency on my part. -- David W. Barts in a.s.r --- Today: Daylight Saving Time begins in U.S. - Spring Forward
someone hijacked spamassassin.org whois record?
hacked dns servers records? Domain ID:D81255450-LROR Domain Name:SPAMASSASSIN.ORG Created On:17-Dec-2001 02:01:49 UTC Last Updated On:11-Mar-2012 12:32:35 UTC Expiration Date:17-Dec-2012 02:01:49 UTC Sponsoring Registrar:Dotster, Inc. (R34-LROR) Status:CLIENT DELETE PROHIBITED Status:CLIENT TRANSFER PROHIBITED Status:CLIENT UPDATE PROHIBITED Registrant ID:DOT-2MZ7O47A2BT8 Registrant Name:Host Master Registrant Organization:Apache Software Foundation Registrant Street1:1901 Munsey Drive Registrant Street2: Registrant Street3: Registrant City:Forest Hill Registrant State/Province:MD Registrant Postal Code:21050-2747 Registrant Country:US Registrant Phone:+1.14104200140 Registrant Phone Ext.: Registrant FAX: Registrant FAX Ext.: Registrant Email:hostmaster-2005-al...@apache.org Admin ID:DOT-BYQQQJZSKSZD Admin Name:Host Master Admin Organization:Apache Software Foundation Admin Street1:1901 Munsey Drive Admin Street2: Admin Street3: Admin City:Forest Hill Admin State/Province:MD Admin Postal Code:21050-2747 Admin Country:US Admin Phone:+1.14104200140 Admin Phone Ext.: Admin FAX: Admin FAX Ext.: Admin Email:hostmaster-2005-al...@apache.org Tech ID:DOT-WQUT26ZZD3R7 Tech Name:Host Master Tech Organization:Apache Software Foundation Tech Street1:1901 Munsey Drive Tech Street2: Tech Street3: Tech City:Forest Hill Tech State/Province:MD Tech Postal Code:21050-2747 Tech Country:US Tech Phone:+1.14104200140 Tech Phone Ext.: Tech FAX: Tech FAX Ext.: Tech Email:hostmaster-2005-al...@apache.org Name Server:NS2.SURFNET.NL Name Server:NS3.NO-IP.COM Name Server:NS2.NO-IP.COM Name Server:NS1.NO-IP.COM Name Server:NS4.NO-IP.COM -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 *| *SECNAP Network Security Corporation * Best Mobile Solutions Product of 2011 * Best Intrusion Prevention Product * Hot Company Finalist 2011 * Best Email Security Product * Certified SNORT Integrator __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.spammertrap.com/ __
Re: someone hijacked spamassassin.org whois record?
- Original Message - From: Michael Scheidell michael.scheid...@secnap.com To: SpamAssassin Users List users@spamassassin.apache.org Sent: Sunday, March 11, 2012 6:25:52 PM Subject: someone hijacked spamassassin.org whois record? hacked dns servers records? Not likely. It does look like someone screwed up something. This seams to be related: https://svn.apache.org/repos/infra/infrastructure/trunk/dns/zones/spamassassin.org https://issues.apache.org/jira/browse/INFRA-2507 (check bottom/latest of the thread) Domain ID:D81255450-LROR Domain Name:SPAMASSASSIN.ORG Created On:17-Dec-2001 02:01:49 UTC Last Updated On:11-Mar-2012 12:32:35 UTC Expiration Date:17-Dec-2012 02:01:49 UTC Sponsoring Registrar:Dotster, Inc. (R34-LROR) Status:CLIENT DELETE PROHIBITED Status:CLIENT TRANSFER PROHIBITED Status:CLIENT UPDATE PROHIBITED Registrant ID:DOT-2MZ7O47A2BT8 Registrant Name:Host Master Registrant Organization:Apache Software Foundation Registrant Street1:1901 Munsey Drive Registrant Street2: Registrant Street3: Registrant City:Forest Hill Registrant State/Province:MD Registrant Postal Code:21050-2747 Registrant Country:US Registrant Phone:+1.14104200140 Registrant Phone Ext.: Registrant FAX: Registrant FAX Ext.: Registrant Email:hostmaster-2005-al...@apache.org Admin ID:DOT-BYQQQJZSKSZD Admin Name:Host Master Admin Organization:Apache Software Foundation Admin Street1:1901 Munsey Drive Admin Street2: Admin Street3: Admin City:Forest Hill Admin State/Province:MD Admin Postal Code:21050-2747 Admin Country:US Admin Phone:+1.14104200140 Admin Phone Ext.: Admin FAX: Admin FAX Ext.: Admin Email:hostmaster-2005-al...@apache.org Tech ID:DOT-WQUT26ZZD3R7 Tech Name:Host Master Tech Organization:Apache Software Foundation Tech Street1:1901 Munsey Drive Tech Street2: Tech Street3: Tech City:Forest Hill Tech State/Province:MD Tech Postal Code:21050-2747 Tech Country:US Tech Phone:+1.14104200140 Tech Phone Ext.: Tech FAX: Tech FAX Ext.: Tech Email:hostmaster-2005-al...@apache.org Name Server:NS2.SURFNET.NL Name Server:NS3.NO-IP.COM Name Server:NS2.NO-IP.COM Name Server:NS1.NO-IP.COM Name Server:NS4.NO-IP.COM -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 *| *SECNAP Network Security Corporation * Best Mobile Solutions Product of 2011 * Best Intrusion Prevention Product * Hot Company Finalist 2011 * Best Email Security Product * Certified SNORT Integrator __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.spammertrap.com/ __ -- Joao Gouveia AnubisNetworks Tel. : +351 21 7252110 Mobile : +351 91 9512960 Fax : +351 21 7252119 http://www.anubisnetworks.com
More on learning from imap folders
I built the following script:
#/bin/bash
VROOT=/usr/local/virtual/;
for i in `ls -d ${VROOT}*@*` ; do
echo `date`
echo Processing ${i}
J_PATH=${i}/.Junk
H_PATH=${i}/NotJunk
if test -d ${J_PATH}; then
/usr/local/bin/sa-learn --spam -u vpopmail $J_PATH/{new,cur}
else
echo No $J_PATH
fi
if test -d ${H_PATH}; then
/usr/local/bin/sa-learn --ham -u vpopmail $H_PATH
mv $H_PATH/{cur,new}/* ${VROOT}${i}/cur
else
echo No $H_PATH
fi
echo
done
And it appears to work fine, except that it takes 20 seconds to process an
entirely empty folder
---OUTPUT
Sun Mar 11 13:17:24 MDT 2012
Processing /usr/local/virtual/ben@…
Learned tokens from 0 message(s) (0 message(s) examined)
Sun Mar 11 13:17:44 MDT 2012
---END
# ls -lsR /usr/local/virtual/ben\@…/.Junk/
total 6
2 drwx-- 2 root vpopmail 512 Mar 8 04:21 cur
2 drwx-- 2 root vpopmail 512 Mar 8 04:21 new
2 drwx-- 2 root vpopmail 512 Mar 8 04:21 tmp
/usr/local/virtual/b...@xanmax.com/.Junk/cur:
total 0
/usr/local/virtual/b...@xanmax.com/.Junk/new:
total 0
/usr/local/virtual/b...@xanmax.com/.Junk/tmp:
total 0
This seems like a lot of time for sa-learn to process 0 files. Long enough that
I probably need to add some logic to check for actual files before passing the
directory to sa-learn. Is this sort of delay normal?
As for the logic, I was thinking of something like this:
ISSPAM=`find $J_PATH/{cur,new} -type f`
if [ ! $ISSPAM ]; then
/usr/local/bin/sa-learn --spam -u vpopmail $J_PATH/{new,cur}
fi
--
I can't die, I haven't seen The Jolson Story
Re: Allowing IMAP users to train spam/ham
On 09 Mar 2012, at 17:07 , RW wrote: It's been demonstrated on Bogofilter that train-on-everything outperforms train-on-error on the same corpora. They both end-up with similar accuracy, but train-on-everything gets there very much faster. But training is exceedingly slow. Under normal load, sa-learn putters along at 2.5-4 mesg/sec, and under load it can drop to under 1. Now, sure, perhaps I should throw a quad core i7 at it, but REALLY? -- I NO LONGER WANT MY MTV Bart chalkboard Ep. 3G02
Re: someone hijacked spamassassin.org whois record?
On 3/11/12 2:52 PM, João Gouveia wrote: - Original Message - From: Michael Scheidellmichael.scheid...@secnap.com To: SpamAssassin Users Listusers@spamassassin.apache.org Sent: Sunday, March 11, 2012 6:25:52 PM Subject: someone hijacked spamassassin.org whois record? hacked dns servers records? Not likely. It does look like someone screwed up something. This seams to be related: https://svn.apache.org/repos/infra/infrastructure/trunk/dns/zones/spamassassin.org https://issues.apache.org/jira/browse/INFRA-2507 (check bottom/latest of the thread) yeh, right: Global Redundancy. No-IP deploys nameservers across the globe to ensure 100% DNS uptime. No one DNS server is at the same data center or utilizes the same Internet connectivity. With 5 nameservers in addition to your nameserver DNS will ALWAYS resolve! -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 *| *SECNAP Network Security Corporation * Best Mobile Solutions Product of 2011 * Best Intrusion Prevention Product * Hot Company Finalist 2011 * Best Email Security Product * Certified SNORT Integrator __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.spammertrap.com/ __
Re: Allowing IMAP users to train spam/ham
On Sun, 11 Mar 2012 13:56:52 -0600 LuKreme wrote: On 09 Mar 2012, at 17:07 , RW wrote: It's been demonstrated on Bogofilter that train-on-everything outperforms train-on-error on the same corpora. They both end-up with similar accuracy, but train-on-everything gets there very much faster. But training is exceedingly slow. Under normal load, sa-learn putters along at 2.5-4 mesg/sec, and under load it can drop to under 1. Now, sure, perhaps I should throw a quad core i7 at it, but REALLY? You missing the point. What I'm saying is that train-on-error is not more accurate that train-on-everything, and that training on Spamassassin errors is going to be worse, not the optimal method as was claimed. If you want to trade accuracy for cost that's fine as long as you're clear about it, but it shouldn't be dressed-up as a better way to learn. I'm not saying everything needs to learned. In general training on spam that doesn't hit BAYES_99 and ham that doesn't hit BAYES_00 is a reasonable compromise. The big problem with only training on full spamassassin errors is that failure to properly classify ham will rarely be corrected.
