Re: FuzzyOCR install issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Ok, I installed libjpeg-devel, libpng-devel, and libtiff-devel, then I DL and compiled netpbm-10.34 from source. it all went well, and now I have all 3 of those convertor executables on my system. i then ran some tests on your sample mails. the gif sample works great. - exactly like in your README file. the png sample gives me this error: /usr/local/netpbm/bin/pngtopnm: symbol lookup error: /usr/local/netpbm/bin/pngtopnm: undefined symbol: pnm_allocrow ERROR pnm.c L213: read and the jpeg sample gives me this error: jpegtopnm: WRITING PPM FILE /usr/local/netpbm/bin/jpegtopnm: symbol lookup error: /usr/local/netpbm/bin/jpegtopnm: undefined symbol: pnm_allocrow ERROR pnm.c L213: read any ideas? Thanks, Devin On Aug 15, 2006, at 4:03 PM, [EMAIL PROTECTED] wrote: Chris, I am in the process of installing and testing FuzzyOcr, but i am having some issues with netpbm. I installed netpbm via yum and have version netpbm-10.25-2.EL4.2 installed now. the problem is that giftopnm, jpegtopnm, and pngtopnm are nowhere to be found on the system. any suggestions? I'm on RHEL 4.1 Thanks, Devin You are probably missing more dependencies, like libpnm. The symbols missing here are in the pnm library :) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4tCvJQIKXnJyDxURAgJkAJ9ow3ghEKwua6+EASexASN/TPKQeQCgtrPi gTvtiwEo9saVolu1McOH8Zs= =W5YY -END PGP SIGNATURE-
SA 3.1.3 scores 0.0
Hi i just received a few emails with no body but subject Subject: tsg SAVE 82%: VIAGR*, AMBIE*, CIALI*, XANA*, RIVOTRI*, LEVITR*,CIPRO, MERIDI*, CELEBRE*, VALIU* thought X-Spam-Status: No, score=0.0 required=4.5 tests=none autolearn=failed version=3.1.3 any idea how to trap this sort of spam. Mark
Re: .GIF images without .gif in filename and empty messages
From: David B Funk [EMAIL PROTECTED]
On Tue, 15 Aug 2006, Craig Baird wrote:
[snip..]
The other type of spam I'm seeing are empty messages. They have a single word
for a subject, but nothing in the body. About a year ago, I was getting
flooded with these, and I solved the problem by using the SARE_HTML_NO_BODY
rule from 70_sare_html4.cf. However, this rule does not seem to hit on this
recent crop of empty messages. I have no idea why.
Is anyone else seeing these, and more importantly, does anyone have a rule for
them?
I've been seeing floods of these critters recently, I assume that it's
some ratware misfire.
Here's what works for me:
# must use 'rawbody' as 'body' also includes Subject: header text
# see if message rawbody contains at least -one- non-blank character
rawbody __MSG_RAW_EXISTS/\S/
# Nope, declare the message to be missing the body
meta L_MISSING_BODY ! __MSG_RAW_EXISTS
describe L_MISSING_BODY Message body empty
score L_MISSING_BODY0.5
# if they didn't give us a message body and are from a bad place, hit them
# hard.
#
meta L_MISSING_BODY2( L_MISSING_BODY ( RCVD_IN_MAPS_DUL || L_RCVD_IN_XBL ||
L_RCVD_IN_DBFBL || RCVD_IN_BL_SPAMCOP_NET || RCVD_IN_SORBS || RCVD_IN_NJABL ||
RCVD_IN_NJABL_DIALUP || L_RCVD_IN_CBL || NO_DNS_FOR_FROM ))
score L_MISSING_BODY2 3.0
Betcha zero text files encoded base64 start with R0lGODlh, the standard
GIF header.
{^_^}
Re: SPF and SORBS problems
Daryl C. W. O'Shea wrote: See the third heading on this wiki page that tells you how to resolve this specific issue: http://wiki.apache.org/spamassassin/DynablockIssues Daryl Thank you. That solved the problem. Upgrade to new SA and Postfix versions and everything plays nicely now, as postfix puts in a header for authentication, and SA can read it. I even get all_trust to fire on authenticated emails. Sadly I never found that page on my own, as it doesn't have any of the keywords I searched for. The phrase dynablock never came up in anything I was having trouble with. Thanks again, --James
Re: SPF and SORBS problems
Xepher writes: Daryl C. W. O'Shea wrote: See the third heading on this wiki page that tells you how to resolve this specific issue: http://wiki.apache.org/spamassassin/DynablockIssues Daryl Thank you. That solved the problem. Upgrade to new SA and Postfix versions and everything plays nicely now, as postfix puts in a header for authentication, and SA can read it. I even get all_trust to fire on authenticated emails. Sadly I never found that page on my own, as it doesn't have any of the keywords I searched for. The phrase dynablock never came up in anything I was having trouble with. feel free to add explanatory text so that it will in future ;) --j.
Yahoo Received header problem?
Hi, I just received an e-mail that had been incorrectly marked as hitting a block list (the SBL in this case, IIRC). The culprit for this seems to be the following first Received header, where a.b.c.d is the address on the BL: Received: from [a.b.c.d] by web55501.mail.re4.yahoo.com via HTTP; Tue, 15 Aug 2006 15:34:33 BST This seems wrong to me? However, my guess is that there is nothing wrong with SpamAssassin, just that Yahoo shouldn't be adding a Received header for a non-SMTP transaction (of course an X-Yahoo-HTTP-IP: a.b.c.d header would be fine). Obviously the sender wasn't abusing anything by sending a direct SMTP message rather than using their ISP; they were just using their webmail. Comments? Thanks, Matthew -- Matthew Newton [EMAIL PROTECTED] UNIX and e-mail Systems Administrator, Network Support Section, Computer Centre, University of Leicester, Leicester LE1 7RH, United Kingdom
Re: Rule for non-DK-signed mail from yahoo
Mark Martinec writes: Thank you all for the feedback. FWIW, I've seen a few mails that had multiple DK signatures, apparently as the result of going through a DK signed mailing list when the original message had also been signed. yeah, I think if the list re-signs the message, that's ok, because it then doesn't matter if the internal signature fails (there being no need to check that). That may be a DKIM interpretation btw. That should not be a problem - if the message is re-signed, and the resigner inserts his own Sender header field as it is supposed to do, outer DK and DKIM signatures will succeed and the rule will not fire thanks to !DK_VERIFIED. yeah -- in a perfect world, maybe ;) DK verification may fail if the mail goes through mailing lists. ah. Here's another one that just occurred to me -- (c): if you're keying off the From: header, watch out for mailing list traffic that appends a footer to the body. That will cause a verification failure, and fire the rule. Bear in mind the list/forwarding issue I also noted; most list installs don't re-sign mails, so an additional exemption for messages that contain List-Id might be worthwhile. mass-check should give a good idea, anyway. Some (most?) mailing lists are indeed problematic, so the rule should not fire if it looks like the message was passed through a mailing list. I'm glad that this ML seems to do pretty well in avoiding breaking of original signatures. (and the postfix-users ML for DKIM, but not for DK, because it appends a Sender:) This is what I have now: header __L_ML0Precedence=~ /\b(list|bulk)\b/i header __L_ML1exists:List-Id header __L_ML2exists:List-Post header __L_ML3exists:Mailing-List header __L_HAS_SENDER exists:Sender meta __L_VIA_ML __L_ML0 || __L_ML1 || __L_ML2 || __L_ML3 || __L_HAS_SENDER header __L_FROM_YAHOO From:addr =~ /@yahoo\.com$/i header __L_FROM_GMAIL From:addr =~ /@gmail\.com$/i meta UNVERIFIED_YAHOO __L_FROM_YAHOO !__L_VIA_ML !DK_VERIFIED priority UNVERIFIED_YAHOO 500 scoreUNVERIFIED_YAHOO 2.5 meta UNVERIFIED_GMAIL __L_FROM_GMAIL !__L_VIA_ML !DK_VERIFIED priority UNVERIFIED_GMAIL 500 scoreUNVERIFIED_GMAIL 2.5 Checking the last 12 hours of the log, I found two false positives, one was a yahoo user with a regular yahoo account, who posted directly through his home ISP's mailer (not through yahoo), but provided his yahoo From address. The other was a forwarding through a gmail account, which did not (re)sign the message. Seems pretty good - and 2.5 score points is not too bad for an otherwise healthy message. The former is pretty common, fwiw. OK -- someone who would know, tells me: Pretty much all user-generated mail From: yahoo-owned domains is [now] signed, but that's not intended as a statement of spam/non-spam. Certainly not, but either way, we can be certain that the massage came from the signing domain it claims to be, which makes it easier to apply other rules like blacklisting etc, if mail happens to be spam. Which is why I'd suggest something like: # give some incentive for people to start signing their mail: score DKIM_VERIFIED -1.5 score DK_VERIFIED -1.0 SpamAssassin has some merit and influence on the population, so it may just as well be setting some trends. If spamers start signing their mail, so much the better. I'd prefer not to do this without some kind of DKIM reputation service up and running, so that we don't give bonuses to spammers who sign their mails. In our experience, spammers will quickly exploit any SpamAssassin bonuses available, and this would be pretty easy. --j.
Re: SPF and SORBS problems
Justin Mason wrote: feel free to add explanatory text so that it will in future ;) Done. Would've done so sooner, but it listed the page as immutable. And I didn't realize that changed if I created a login. Hopefully that should let a few more people find that answer easier. --James
Recommended latest Perl version
I've been running SA on 5.6.1, but I'm building a new FreeBSD box and its prefered version is 5.8. I noticed that in the SA docs, it mentions performance problems with 5.8. FreeBSD has version 5.6.2 in ports, but I seem to recall that one shouldn't use perl versions that ended in even numbers, as they were considered development versions. What it the best, latest version of Perl that should be used with SA? I didn't see it in the FAQ. TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Spamd not able to drop root privileges at arbitrary times
Theo, Well, I can verify that the users exist on the server. I'm not sure why spamc would be called by root...it's invoked by a .procmailrc, and passed the -u flag and given the user name. And it arbitrarily won't work for a user that in almost all other instances it *does* work for. Before, I had a central box running the spamd daemon, and the three boxes that run in parallel would pass the message/username to that central box. I've since broken it out, running a spamd daemon on each of the three boxes, so that the call is made locally to that respective spamd daemon. (This is to help reduce load). Only now am I seeing these messages. And like I said, it only happens on one out of every maybe 400 messages for any given user. Truly odd... Any other thoughts? Thanks in advance, Best Regards, Ryan Theo Van Dinter wrote: On Tue, Aug 15, 2006 at 05:12:42PM -0400, Ryan Steele wrote: hitch. It seems that arbitrarily, spamd is unable to drop root privileges. Here's the relevant log message: spamd: still running as root: user not specified with -u, not found, or set to root, falling back to nobody at /usr/sbin/spamd line 1150, GEN1596 line 4. The message generally means that either the user calling spamd doesn't exist on the spamd server, or more likely spamc is being called by root and for security reasons spamd switches to nobody. -- Ryan Steele Systems Administrator [EMAIL PROTECTED] AgoraNet, Inc. (302) 224-2475 314 E. Main Street, Suite 1 (302) 224-2552 (fax) Newark, DE 19711http://www.agora-net.com
Images spams cropping up again
I used some recipes found with the help of this list that pretty much wiped out these images spams until this morning they are coming through again different, of course. Is the OCR solution what I need to do? If so, can someone point me to some info or suggest how to set this up? Thanks in advance! -- Robert
Re: Recommended latest Perl version
[EMAIL PROTECTED] writes: I've been running SA on 5.6.1, but I'm building a new FreeBSD box and its prefered version is 5.8. I noticed that in the SA docs, it mentions performance problems with 5.8. FreeBSD has version 5.6.2 in ports, but I seem to recall that one shouldn't use perl versions that ended in even numbers, as they were considered development versions. What it the best, latest version of Perl that should be used with SA? I didn't see it in the FAQ. Well, 5.6.x and 5.8.x (where x = 1 in both cases) should be fine. 5.8.x is a little better in terms of internationalization and UTF-8 use, so if you have rules to match non-English, non-latin-charset languages, that's probably more appropriate. However, last time I tested, 5.6.1 was faster -- probably because of less thorough support for 5.8 features like threading, multiplicity and UTF-8 in core. 5.6.2 should be fine. the 5.9.x line (note the odd 9) is the development line. --j.
Re: Images spams cropping up again
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Fitzpatrick wrote: I used some recipes found with the help of this list that pretty much wiped out these images spams until this morning they are coming through again different, of course. Is the OCR solution what I need to do? If so, can someone point me to some info or suggest how to set this up? Thanks in advance! For OCR, see http://wiki.apache.org/spamassassin/FuzzyOcrPlugin Another, non-OCR solution is the ImageInfo plugin (google spamassassin imageinfo) If you need help with the installation of FuzzyOcr, feel free to mail me back in private :) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4x0eJQIKXnJyDxURAjKmAJ9LK7wKS06YWZDM7iXqS3eRe+jedACeOgd6 URR7HklwgKxI8F37LA9/6Ww= =QXE4 -END PGP SIGNATURE-
FuzzyOCR and mailscaner/SA issues.
I installed fuzzyocr according to the installation manual at http://wiki.apache.org/spamassassin/FuzzyOcrPlugin I am running fc5 and had netpbm installed already but I had to get gocr and giffix by installing libungif-4.1.4. I also had to fix the path in fuzzyocr.cf file. now, when I ran those sample emails via spamassassin -t ocr-gif.eml, it detected it as spam and all works well but when I passed an image generated by text2gif it doesn't get filtered. I catch spam so I believe spamassassin is working just not doing anything with fuzzyocr? anyone? == /var/log/maillog section Aug 16 09:27:31 linux1 sendmail[8053]: k7GDROM5008053: from=[EMAIL PROTECTED], size=2029, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], proto=ESMTP, daemon=MTA, relay=bay0-omc3-s17.bay0.hotmail.com [65.54.246.217] Aug 16 09:27:52 linux1 MailScanner[689]: New Batch: Scanning 1 messages, 2607 bytes Aug 16 09:27:52 linux1 MailScanner[689]: MCP Checks completed at 2589284 bytes per second Aug 16 09:27:52 linux1 MailScanner[689]: Spam Checks: Starting Aug 16 09:28:07 linux1 MailScanner[689]: Spam Checks completed at 174 bytes per second Aug 16 09:28:07 linux1 MailScanner[689]: Virus and Content Scanning: Starting Aug 16 09:28:14 linux1 MailScanner[689]: Virus Scanning completed at 336 bytes per second Aug 16 09:28:14 linux1 MailScanner[689]: Uninfected: Delivered 1 messages Aug 16 09:28:14 linux1 MailScanner[689]: Virus Processing completed at 52515 bytes per second Aug 16 09:28:14 linux1 MailScanner[689]: Disinfection completed at 5581700 bytes per second Aug 16 09:28:14 linux1 MailScanner[689]: Batch completed at 114 bytes per second (2607 / 22) Aug 16 09:28:14 linux1 MailScanner[689]: Batch (1 message) processed in 22.73 seconds Aug 16 09:28:14 linux1 MailScanner[689]: MailScanner child dying of old age Aug 16 09:28:15 linux1 MailScanner[8074]: MailScanner E-Mail Virus Scanner version 4.54.6 starting... Aug 16 09:28:15 linux1 sendmail[8075]: k7GDROM5008053: to=[EMAIL PROTECTED], delay=00:00:45, xdelay=00:00:00, mailer=local, pri=122029, dsn=2.0.0, stat= == and the message = /tmp ] # cat msg X-Envelope-From: [EMAIL PROTECTED] Received: from bay0-omc3-s17.bay0.hotmail.com (bay0-omc3-s17.bay0.hotmail.com [65.54.246.217]) by DOMAIN.com (8.13.7/8.13.7) with ESMTP id k7GDROM5008053 for [EMAIL PROTECTED]; Wed, 16 Aug 2006 09:27:30 -0400 Received: from BAY101-W7 ([64.4.56.107]) by bay0-omc3-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 06:26:04 -0700 X-Originating-IP: [xxx.xxx.xxx.xxx] X-Originating-Email: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_2844eb73-fdd6-4571-b1ed-87827ce388f8_ From: Hotmail User [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: FW: test.gif file Date: Wed, 16 Aug 2006 09:26:03 -0400 X-OriginalArrivalTime: 16 Aug 2006 13:26:04.0176 (UTC) FILETIME=[85FA1900:01C6C137] X-DOMAIN-MailScanner-Information: Please contact the ISP for more information X-DOMAIN-MailScanner: Found to be clean X-DOMAIN-MailScanner-SpamCheck: not spam, SpamAssassin (score=2.269, required 5, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.48, DNS_FROM_RFC_POST 1.44, FWD2_MSG -0.40, SARE_GIF_ATTACH 0.75, SPF_PASS -0.00) X-DOMAIN-MailScanner-SpamScore: ss X-DOMAIN-MailScanner-From: [EMAIL PROTECTED] X-Spam-Status: No --_2844eb73-fdd6-4571-b1ed-87827ce388f8_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Aug 2006 13:32:17 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: test.gif file =20 =20 This is a test file _ Try Live.com - your fast, personalized homepage with all the things you car= e about in one place. http://www.live.com/getstarted= --_2844eb73-fdd6-4571-b1ed-87827ce388f8_ Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=test.gif R0lGODdhGAIIAIAAAP///ywAGAIIAAAC/4SPEWjKD9N6Ltpr1Twa831V3oiJEol2o4m2 DejGr8fKK5zi9j7zpw8E1Hy1YS7IK+qSS+TPGWpCW8bp0xqrlqTYLkPrhWpE4035oyqbxxLQWfjO sK+97XoOV+XJi44azaeX11bx9yIId3OXtnYY+LjYyIhI8RY36AgpFceJZzkB1qnn4Nd4SBgZNceX WFfp2ReICqjD+uUmadp6+9FrS4NbSfL7u1toUlw3RBzby+sMDE2a67uEbCoIJt3symzcZHRdPR6K Y5ut+z3u+pzImvx0XKs77Wy4C71Xug3hDY8arN0Wft0MsTjXqR89bq3u4YvC751BPPgQvtIiMZ8/ UK0YKYqboUSbvkzH2n18qK9KRpAcwWGzlo4kQ3gnCaJUxzKfyYB05NisqXMlzp3r3KUTObRkSYgF 7W1yeaqYt0FIpVLjhTSnMKwwaHJBo7VhvQiM2NnUSbLNrUgzcblNNVQhrGvaVh3VxA6hR7pw9Y6i dFHZHYAp19IKekmuWHRLUapM/Dfyvpu02JrFBKhyWrKxLAvkGtOR5sJhSps+jTq16tWnE7N+DXtt R9QFAAA7 --_2844eb73-fdd6-4571-b1ed-87827ce388f8_-- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: FuzzyOCR and mailscaner/SA issues.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Agent Smith wrote: I installed fuzzyocr according to the installation manual at http://wiki.apache.org/spamassassin/FuzzyOcrPlugin I am running fc5 and had netpbm installed already but I had to get gocr and giffix by installing libungif-4.1.4. I also had to fix the path in fuzzyocr.cf file. now, when I ran those sample emails via spamassassin -t ocr-gif.eml, it detected it as spam and all works well but when I passed an image generated by text2gif it doesn't get filtered. I catch spam so I believe spamassassin is working just not doing anything with fuzzyocr? anyone? If the samples get recognized correctly, then it is probably working, try to manually recognize your gif with gocr -i file.gif and see what it spits out :) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4yHGJQIKXnJyDxURAvnvAKCcO32ANFURfLC86wKfmnY7/gbY7gCfdZne YRwS0eR5UN2J61/CRfqzgks= =rowA -END PGP SIGNATURE-
Re: FuzzyOCR and mailscaner/SA issues.
# gocr -i test.gif # Warning: non-positive median line gap of 0 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ # is this the problem then? the image IS a gif file generated by text2gif, I can open it in pic viewer or whatever. maybe I need a diff. version of gocr --- decoder [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Agent Smith wrote: I installed fuzzyocr according to the installation manual at http://wiki.apache.org/spamassassin/FuzzyOcrPlugin I am running fc5 and had netpbm installed already but I had to get gocr and giffix by installing libungif-4.1.4. I also had to fix the path in fuzzyocr.cf file. now, when I ran those sample emails via spamassassin -t ocr-gif.eml, it detected it as spam and all works well but when I passed an image generated by text2gif it doesn't get filtered. I catch spam so I believe spamassassin is working just not doing anything with fuzzyocr? anyone? If the samples get recognized correctly, then it is probably working, try to manually recognize your gif with gocr -i file.gif and see what it spits out :) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4yHGJQIKXnJyDxURAvnvAKCcO32ANFURfLC86wKfmnY7/gbY7gCfdZne YRwS0eR5UN2J61/CRfqzgks= =rowA -END PGP SIGNATURE- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Rule for non-DK-signed mail from yahoo
Justin Mason wrote: I'd prefer not to do this without some kind of DKIM reputation service up and running, so that we don't give bonuses to spammers who sign their mails. In our experience, spammers will quickly exploit any SpamAssassin bonuses available, and this would be pretty easy. --j. So what is involved in establishing one?
Re: FuzzyOCR and mailscaner/SA issues. (interesting..)
huh, I downloaded an image mentioned in this group wget http://www.nabble.com/user-files/322/bell.gif and ran it thru gocr without any problems, when attached to a message, SA detects it and it works well. $ text2gif -t Trading company million trade service trade price buy thousand million money test.gif [EMAIL PROTECTED] ~]$ gocr -i test.gif # Warning: non-positive median line gap of 0 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ --- Agent Smith [EMAIL PROTECTED] wrote: # gocr -i test.gif # Warning: non-positive median line gap of 0 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ # is this the problem then? the image IS a gif file generated by text2gif, I can open it in pic viewer or whatever. maybe I need a diff. version of gocr --- decoder [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Agent Smith wrote: I installed fuzzyocr according to the installation manual at http://wiki.apache.org/spamassassin/FuzzyOcrPlugin I am running fc5 and had netpbm installed already but I had to get gocr and giffix by installing libungif-4.1.4. I also had to fix the path in fuzzyocr.cf file. now, when I ran those sample emails via spamassassin -t ocr-gif.eml, it detected it as spam and all works well but when I passed an image generated by text2gif it doesn't get filtered. I catch spam so I believe spamassassin is working just not doing anything with fuzzyocr? anyone? If the samples get recognized correctly, then it is probably working, try to manually recognize your gif with gocr -i file.gif and see what it spits out :) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4yHGJQIKXnJyDxURAvnvAKCcO32ANFURfLC86wKfmnY7/gbY7gCfdZne YRwS0eR5UN2J61/CRfqzgks= =rowA -END PGP SIGNATURE- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
ImageInfo Plugin
Just for posterities sake, after running the plugin for a week. I have the following results with not a single complaint of a false positive. Rule Total Ham % Spam% DC_GIF_UNO_LARGO 19,8391,057 5.3 18,782 94.7 DC_IMAGE_SPAM 13,71510 0.1 13,705 99.9 DC_PNG_UNO_LARGO 6,37721 0.3 6,356 99.7 DC_GIF_MULTI_LARGO 46618 3.9 448 96.1 That is from a total of 500k messages processed in the last 7 days. Very nice, it has made a big difference here. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: FuzzyOCR error on processing gif sample file
On Tue, 15 Aug 2006, Rob Mangiafico wrote: Downloaded and installed the latest FuzzyOCR 2.1c Ran the tests and the jpg and png ones worked fine, but for the gif sample I received: spamassassin -t ocr-gif.eml giftopnm: error reading magic number (null): EOF / read error reading magic number Broken pipe Your netpbm seems very old, I am using 10.34. This could be the cause, try the newest version, though I can't guarrantee that this is the cause. If that doesn't work, try saving the gif image from the ocr-gif.eml sample and run the commands manually over the file to see which step fails. Thanks. I removed the RHEL rpm for netpbm, installed 10.26 from source (10.34 did not like RHEL 3 OS it seems) but still have issues with the gif file. If anyone has a working system for RHEL 3 (centOS 3) and the new OCR plugin, please post how you got it working. Thanks, and thanks for a great plugin. FYI, I figured this problem out. I installed netpbm to /usr/local/netpbm/ and gocr was not able to find all the files easily. I reinstalled netpbm to just /usr/local, recompiled gocr, and it works for the gifs now without a problem. :) Rob
Re: Images spams cropping up again
Robert Fitzpatrick wrote: I used some recipes found with the help of this list that pretty much wiped out these images spams until this morning they are coming through again different, of course. Is the OCR solution what I need to do? If so, can someone point me to some info or suggest how to set this up? Here too, much more than other days during the last 24 hours. Most (the ~30k ones) were blocked by existing postfix rules, but some were different and got through. ImageInfo didn't hit on them, but SA scored them as SPAM anyway. I made two new postfix rules to block them (for now..). Hope OCR will catch them for you, might try that too if it gets worse. Regards Menno van Bennekom -- View this message in context: http://www.nabble.com/Images-spams-cropping-up-again-tf2115239.html#a5833480 Sent from the SpamAssassin - Users forum at Nabble.com.
Hashcash plugin to stamp outgoing mails (for postfix only)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello there, since SpamAssassin supports the hashcash signatures but support for MUAs is rare, I wrote a plugin which is able to stamp all outgoing emails of a postfix server. If anyone is interested in testing this alpha version of the content_filter, please mail me. Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4yw2JQIKXnJyDxURAhcuAKCVoxF/rZzB9lUSgdBtHz19vp/5MACfbZlk wVNyNmF4UF4wmHRGu+uWjTI= =OUoP -END PGP SIGNATURE-
Re: Images spams cropping up again
On Wed, 2006-08-16 at 07:28 -0700, MennovB wrote: Robert Fitzpatrick wrote: I used some recipes found with the help of this list that pretty much wiped out these images spams until this morning they are coming through again different, of course. Is the OCR solution what I need to do? If so, can someone point me to some info or suggest how to set this up? Here too, much more than other days during the last 24 hours. Most (the ~30k ones) were blocked by existing postfix rules, but some were different and got through. ImageInfo didn't hit on them, but SA scored them as SPAM anyway. I made two new postfix rules to block them (for now..). Hope OCR will catch them for you, might try that too if it gets worse. Would you be willing to share the postfix rules you are using to block these? -Bill
Re: breaking out: thinking abt the 'sa-update *VS* rdj' thread .. .
I was debating whether or not to get involved with this thread, and it looks like the original issue that Richard was concerned about has been addressed so that's good. However, my other issue with the thread so far comes from the misleading or otherwise incorrect information being presented which I'll try to respond to below. On Fri, Aug 11, 2006 at 12:26:08PM -0400, Chris Santerre wrote: Ok, no. SARE and the official SA are worlds apart. SARE has been setup to be QUICK and accurate. SA is accurate. SARE wants to get good rules out when they are needed. Now saupdate make the DELIVERY of that possible. But the creation of rules in the official method of SA is... please pardon me... a clusterfsck! Chris! I'm surprised to hear you spreading this misinformation. I don't really see how the project's rule development is a clusterfsck. People commit rules for testing, they get tested, if they're good they're put in an update. What's the problem? I also don't understand the quick and good rules out when they are needed statements. You're implying that the SA project doesn't have these goals, which is of course completely incorrect. If you think the system is broken please feel free to chip in and help improve it. If you just complain and that's it, the problems won't get solved. And the apache lic is like reading the fine print on a life insurance policy. I've looked into what it would take to make SARE a part of SA officialy. Yeah, I'll pass. Well, it's a software license so it's lawyery, as is the nature of such things. What's the issue? It's actually a pretty straightforward read compared to some other licenses out there. In Theo's terse IANAL mode: - anything licensed under the ASL can be used and redistributed by anybody - if redistributing (section 4): - the license text must be included - it must be made clear that modifications were made if there were any made - all attribution/copywrites/etc must stay in the source code - anything that was added or modified can be covered under any license/terms desired - any contributions to the project will be licensed under the ASL unless otherwise explicitly stated - trademarks (in our case SpamAssassin) may only be used as is specified in the SA TRADEMARK file - the work is provided as is with no warranties I haven't looked into what it would take to make the current SARE rules part of SA, it could be a lot, it could be a little, I wouldn't know the specifics. However, it's trivial to make new rules part of SA -- publish them under the ASL or even better imo via the SA project. Frankly, I don't understand the issue here anyway. Sometimes things worth doing require effort. If our goals are the same, which I believe is fighting spam which in itself is a difficult task, why shy away from it because it may be hard? RDJ allows you to get new rules, days maybe hours after a new spam sign is found. And these are TESTED! Not just thrown in. I'm not sure what you're implying, that SA rules are not tested and just thrown in updates randomly? FWIW, sa-update lets people get new rules, days maybe hours after a new spam sign is found. And these are TESTED! Not just thrown in. Being a closed group gives us some abilities that the SA project will never have. Such as? I think there some assumptions are being made that aren't necessarily true. So you have 2 completely seperate ideals of rules. The method of which you choose, and how you aquire is up to you. This doesn't really make a lot of sense Chris. The SA project wants to get good rules out fast. SARE, from what you've stated, wants to get good rules out fast. How are those completely separate ideals of rules? Andy Jezierski: The official SA rules are meant to be used by all users. SARE on the other hand is Here's the rules we have, go ahead and pick and choose what you'd like to use. If anything Sure, the current SA rules are meant to be used by all users. However, there's nothing saying that there can't be multiple rule sets made available, some more aggressive, or niche oriented (anti-porn, etc.) I think SARE can put out a new rule for a specific spam problem a lot faster than the SA project, so I'll have to disagree with you here. Wow, there's so much wrapped into this statement that it's hard to figure out what to address first. - put out implies distribution, which is more of a function of how often users check for updates than anything else since otherwise it's people putting files on a website. ie: It doesn't matter if rules are published every 5 minutes if people are only checking once a day. - put out also implies development, which SARE probably is faster on. The real question is: Why? My view is that it's manpower. There's a bunch of people in SARE (I don't know the actual number) focused on developing rules. SpamAssassin has (according to the CREDITS file) 13 people split between rules and code. However not all of
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
decoder wrote: Hello there, since SpamAssassin supports the hashcash signatures but support for MUAs is rare, I wrote a plugin which is able to stamp all outgoing emails of a postfix server. If anyone is interested in testing this alpha version of the content_filter, please mail me. Chris What exactly is this going to achieve? I'm not familiar with using HCS (hashcash signatures). I'm running Postfix on all my boxen, so I'll be happy to test it for you, either way. --Michel Vaillancourt Wolfstar Systems www.wolfstar.ca
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michel Vaillancourt wrote: decoder wrote: Hello there, since SpamAssassin supports the hashcash signatures but support for MUAs is rare, I wrote a plugin which is able to stamp all outgoing emails of a postfix server. If anyone is interested in testing this alpha version of the content_filter, please mail me. Chris What exactly is this going to achieve? I'm not familiar with using HCS (hashcash signatures). I'm running Postfix on all my boxen, so I'll be happy to test it for you, either way. --Michel Vaillancourt Wolfstar Systems www.wolfstar.ca Well, you can read about the hashcash system at hashcash.org, basically, it is a per recipient hash generation that assures that a specific amount of time was required to compute this hash per recipient. Spammers don't have this time, they send thousands of mails per minute. The problem I saw was, that hashcash isn't supported very well on the sending side, there are some plugins/ways to integrate it into mutt and some other MUAs, but many popular ones are missing. Also, I'd prefer a plugin on the MTA so my users don't get bothered with this stuff. My plugin does that for postfix, it puts a hashcash stamp in every outgoing mail header for every recipient. SpamAssassin supports verification of these hashes (this is enabled by default, you only need to configure the mail adresses you accept mails for in the local.cf (http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin_Plugin_Hashcash.html) I will send you the plugin this evening so you can try it out (as I am currently on a run:)) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4zhNJQIKXnJyDxURAtUVAKCS7AQixJGrtrqGSHlzRgFo7HCs6wCgtYfp V2WUw7wFIawo433miPYlsZ0= =VD4O -END PGP SIGNATURE-
Odd local.cf problem
I am running SpamAssassin 3.1.4 on a windows mail server, the local.cf file is in /perl/site/etc/mail/spamassassin This is what it looks like: # This is the right place to customize your installation of SpamAssassin. # # See 'perldoc Mail::SpamAssassin::Conf' for details of what can be # tweaked. # # Only a small subset of options are listed below # ### # Add *SPAM* to the Subject header of spam e-mails # rewrite_header Subject [SPAM] # Save spam messages as a message/rfc822 MIME attachment instead of # modifying the original message (0: off, 2: use text/plain instead) # report_safe 1 # Set which networks or hosts are considered 'trusted' by your mail # server (i.e. not spammers) # trusted_networks 205.158.155.180 trusted_networks 205.158.155.52 trusted_networks 205.158.154.52 trusted_networks 205.158.154.181 trusted_networks 205.158.154.180 #disable DNSBLs, can't control well enough skip_rbl_checks 1 # Set file-locking method (flock is not safe over NFS, but is faster) # # lock_method flock # Set the threshold at which a message is considered spam (default: 5.0) # required_score 5.0 # Use Bayesian classifier (default: 1) # # use_bayes 1 # Bayesian classifier auto-learning (default: 1) # # bayes_auto_learn 1 # Set headers which may provide inappropriate cues to the Bayesian # classifier # # bayes_ignore_header X-Bogosity # bayes_ignore_header X-Spam-Flag # bayes_ignore_header X-Spam-Status ## As you can see I have added about 6 mailservers as trusted and disabled rbl checking or so I thought. messages from those mail servers (the trusted ones) are still getting bounced for being on a black list. Since spamassassin is running as an exe and is envoked everytime mail is delivered it is loading the new config, I have confirmed that by changing the required_score and I see that change immediatly. For some reason Ican't whitelist or disable rbl checking. Am I forgetting something or doing some thing wrong?
Re: Images spams cropping up again
Bill Randle wrote: Would you be willing to share the postfix rules you are using to block these? I don't think that would be wise, I'm afraid they are a bit too risky and simple for general use.. In most of them I've put the mail on HOLD so I can still inspect for FP's, probably not workable on larger sites. I simply collect similar spam in a directory (copied from my amavisd archive dir) and with cat/lowercase/sort/awk utils find out what 'interesting' long string is at least once in all spam-files. Even the MIME-part is (mis-)used for this. I test that on a HAM-dir (and on other spam to maybe find a more general use or patterns) and then place it in body_checks.regexp. During last night 82 mails went on HOLD because of a month old rule, all spam (only looking at the weird sender-addresses says enough, also the file-sizes are comparable in spam-batches). Some rules get hit more than a year long and others last only a day (then it's a waste of time). It's time consuming and not a necessity (SA tags most of it) but I'm a little (too) fanatic to prevent SPAM from getting into the users mailboxes. BTW more spam here is blocked because of blocklists, blocked ip-ranges/domains (china/korea/..), checks on the helo etcetera than with postfix rules. Regards Menno -- View this message in context: http://www.nabble.com/Images-spams-cropping-up-again-tf2115239.html#a5835275 Sent from the SpamAssassin - Users forum at Nabble.com.
I could not download tetex-texmf-3.0.tar.gz while installing gocr
Hello I tried to install gocr so that I could go through some spam mails which have image files ( .gif , .jpg ) on FreeBSD6. But my server could not install it and gave an error as below; How can I download it ? Thanks # make === gocr-0.40_1 depends on executable: latex - not found ===Verifying install for latex in /usr/ports/print/teTeX === Installing for teTeX-3.0 === teTeX-3.0 depends on file: /usr/local/share/texmf-local/ls-R - found === teTeX-3.0 depends on file: /usr/local/share/texmf-dist/LICENSE.texmf - not found ===Verifying install for /usr/local/share/texmf-dist/LICENSE.texmf in /usr/ports/print/teTeX-texmf === Vulnerability check disabled, database not found === Extracting for teTeX-texmf-3.0_3 = MD5 Checksum mismatch for teTeX/tetex-texmf-3.0.tar.gz. = SHA256 Checksum mismatch for teTeX/tetex-texmf-3.0.tar.gz. = MD5 Checksum OK for teTeX/dvipsk-jpatch-p1.6a1.tar.gz. = SHA256 Checksum OK for teTeX/dvipsk-jpatch-p1.6a1.tar.gz. === Refetch for 1 more times files: teTeX/tetex-texmf-3.0.tar.gz teTeX/tetex-texmf-3.0.tar.gz === Vulnerability check disabled, database not found = tetex-texmf-3.0.tar.gz doesn't seem to exist in /usr/ports/distfiles/teTeX. = Attempting to fetch from ftp://ftp.funet.fi/pub/TeX/CTAN/systems/unix/teTeX/3.0/distrib/. fetch: ftp://ftp.funet.fi/pub/TeX/CTAN/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from ftp://ctan.unsw.edu.au/tex-archive/systems/unix/teTeX/3.0/distrib/. fetch: ftp://ctan.unsw.edu.au/tex-archive/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from ftp://ftp.tex.ac.uk/tex-archive/systems/unix/teTeX/3.0/distrib/. fetch: ftp://ftp.tex.ac.uk/tex-archive/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from ftp://ftp.kddlabs.co.jp/CTAN/systems/unix/teTeX/3.0/distrib/. fetch: ftp://ftp.kddlabs.co.jp/CTAN/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from ftp://ctan.tug.org/tex-archive/systems/unix/teTeX/3.0/distrib/. fetch: ftp://ctan.tug.org/tex-archive/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from ftp://ftp.dante.de/tex-archive/systems/unix/teTeX/3.0/distrib/. fetch: ftp://ftp.dante.de/tex-archive/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from http://ring.sakura.ad.jp/archives/text/CTAN/systems/unix/teTeX/3.0/distrib/. fetch: http://ring.sakura.ad.jp/archives/text/CTAN/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from http://ring.riken.jp/archives/text/CTAN/systems/unix/teTeX/3.0/distrib/. fetch: http://ring.riken.jp/archives/text/CTAN/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from http://ring.ip-kyoto.ad.jp/archives/text/CTAN/systems/unix/teTeX/3.0/distrib/. fetch: http://ring.ip-kyoto.ad.jp/archives/text/CTAN/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from ftp://ftp.chg.ru/pub/TeX/CTAN/systems/unix/teTeX/3.0/distrib/. fetch: ftp://ftp.chg.ru/pub/TeX/CTAN/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/teTeX/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/teTeX/tetex-texmf-3.0.tar.gz: size mismatch: expected 91762123, actual 91402377 = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/teTeX and try again. *** Error code 1 Stop in /usr/ports/print/teTeX-texmf. *** Error code 1 Stop in /usr/ports/print/teTeX-texmf. *** Error code 1 Stop in /usr/ports/print/teTeX. *** Error code 1 Stop in /usr/ports/graphics/gocr.
Re: Yahoo Received header problem?
On Wed, 16 Aug 2006, Matthew Newton wrote: I just received an e-mail that had been incorrectly marked as hitting a block list (the SBL in this case, IIRC). The culprit for this seems to be the following first Received header, where a.b.c.d is the address on the BL: Received: from [a.b.c.d] by web55501.mail.re4.yahoo.com via HTTP; Tue, 15 Aug 2006 15:34:33 BST This seems wrong to me? However, my guess is that there is nothing wrong with SpamAssassin, just that Yahoo shouldn't be adding a Received header for a non-SMTP transaction (of course an X-Yahoo-HTTP-IP: a.b.c.d header would be fine). Obviously the sender wasn't abusing anything by sending a direct SMTP message rather than using their ISP; they were just using their webmail. At one time Yahoo offered a paid account where you could get POP3 access to your @yahoo.co mailbox. If they still offer this, they could be allowing authenticated SMTP (or POP before SMTP) from paying customers. I obviously don't really know whether they are doing that, but it seems like one possible explanation. - Logan
Re: I could not download tetex-texmf-3.0.tar.gz while installing gocr
On Wed, 16 Aug 2006, Halid Faith wrote: I tried to install gocr so that I could go through some spam mails which have image files ( .gif , .jpg ) on FreeBSD6. But my server could not install it and gave an error as below; How can I download it ? Thanks # make === gocr-0.40_1 depends on executable: latex - not found ===Verifying install for latex in /usr/ports/print/teTeX === Installing for teTeX-3.0 === teTeX-3.0 depends on file: /usr/local/share/texmf-local/ls-R - found === teTeX-3.0 depends on file: /usr/local/share/texmf-dist/LICENSE.texmf - not found ===Verifying install for /usr/local/share/texmf-dist/LICENSE.texmf in /usr/ports/print/teTeX-texmf === Vulnerability check disabled, database not found === Extracting for teTeX-texmf-3.0_3 = MD5 Checksum mismatch for teTeX/tetex-texmf-3.0.tar.gz. = SHA256 Checksum mismatch for teTeX/tetex-texmf-3.0.tar.gz. This looks like it's got to be a FreeBSD ports issue. Try installing teTeX using FreeBSD ports and see if you can succeed at that. My guess is that subtask (of the task of getting gocr working) will fail. If so, it's not really related to spamassassin. - Logan
Re: Spamd not able to drop root privileges at arbitrary times
On Wed, Aug 16, 2006 at 09:02:11AM -0400, Ryan Steele wrote: Well, I can verify that the users exist on the server. I'm not sure why spamc would be called by root...it's invoked by a .procmailrc, and passed the -u flag and given the user name. And it arbitrarily won't How is that username determined? Does root's mail get processed via procmail? -- Randomly Generated Tagline: Phenomenal Cosmic Powers, Itty Little Living Space. - Aladdin pgpwvYS5050QC.pgp Description: PGP signature
fetchmail and HELO_DYNAMIC_IPADDR when sender is local
I am using fetchmail to retrieve messages from my work account. However, messages sent to my work account from coworkers are being tagged with various dynamic IP rules. My setup is something like this: CoWorker (dialup) -- mail server (office) -- fetchmail (home) -- spamassassin When a message of this sort is retrieved, I get these rule hits: 4.2 HELO_DYNAMIC_IPADDRRelay HELO'd using suspicious hostname (IP addr 1) 1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) [SPF failed: Please see http://spf.pobox.com/why.html?sender=blahblahblah] -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.] 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [24.245.33.51 listed in dnsbl.sorbs.net] 1.9 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [24.245.33.51 listed in combined.njabl.org] -0.1 AWLAWL: From: address is in the auto white-list From reading this thread: http://thread.gmane.org/gmane.mail.spam.spamassassin.general/83423/focus=83423 it looks like there isn't a simple workable solution. It seems like the sender is in the right by sending mail through my work's SMTP server (the problem would go away if they sent through a relay first, but I can't dictate how people send messages TO me). As Raimar tried in the thread above, I added my work server to trusted_networks, and internal_networks but that's not the right way to handle this, apparently. Is there a workable solution that doesn't require me to whitelist all my coworker's IP ranges? Chris
RE: breaking out: thinking abt the 'sa-update *VS* rdj' thread .. .
Title: RE: breaking out: thinking abt the 'sa-update *VS* rdj' thread .. . I got nothing but love for you, so here goes ;) .. These are MY OPINIONS, and may or may not represent the opinions of SARE as a whole. -Original Message- From: Theo Van Dinter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 16, 2006 11:04 AM To: Spamassassin Users List Subject: Re: breaking out: thinking abt the 'sa-update *VS* rdj' thread .. . I was debating whether or not to get involved with this thread, and it looks like the original issue that Richard was concerned about has been addressed so that's good. However, my other issue with the thread so far comes from the misleading or otherwise incorrect information being presented which I'll try to respond to below. Never debate getting into a discussion with me. Its all good. On Fri, Aug 11, 2006 at 12:26:08PM -0400, Chris Santerre wrote: Ok, no. SARE and the official SA are worlds apart. SARE has been setup to be QUICK and accurate. SA is accurate. SARE wants to get good rules out when they are needed. Now saupdate make the DELIVERY of that possible. But the creation of rules in the official method of SA is... please pardon me... a clusterfsck! Chris! I'm surprised to hear you spreading this misinformation. I don't really see how the project's rule development is a clusterfsck. People commit rules for testing, they get tested, if they're good they're put in an update. What's the problem? 1) Manpower. You just don't have enough people devoted to rules. Not your fault. And solving this, would not help. Beacuse of #2... 2) Open community. By nature the SA project has to be open. That means public corpus, public discussion lists, and public test results. SARE woould not be as good if we had spammers watching our every move. MAJOR things we do MUST remain private. Our good results, the rules, are made public. And we offer them to anyone. 3) Delivery. You fixed this. I'm very happy about that. EXTREMELY! But the public still thinks SARE should be part of SA, and it was implied that SARE should be doing more to support saupdate. Thats not our baby. We give you our rules. I also don't understand the quick and good rules out when they are needed statements. You're implying that the SA project doesn't have these goals, which is of course completely incorrect. That wasn't meant to be a jab at SA. It does sound like it after I reread it. Sorry. But since SARE's inception, you can't honestly tell me that SA has kept up with SARE's output. Be it quantity or quality. If you think the system is broken please feel free to chip in and help improve it. If you just complain and that's it, the problems won't get solved. I thought I had. But there is only so far I can go. See #2 above again. SARE has people that work closely with you devs, to keep ME away from you :) So that things try to remain as smooth as possible. We do our thing, give you our best rules, you test, and add to official release. But we can't do what we do if we have to abide by a public open source group rules. I'm not easy to work with. Ask Jeff Chan :) (And he is a super nice guy!) * SNIP lic talk* I haven't looked into what it would take to make the current SARE rules part of SA, it could be a lot, it could be a little, I wouldn't know the specifics. However, it's trivial to make new rules part of SA -- publish them under the ASL or even better imo via the SA project. But for what end? SARE gives you our best rules to be added. So what would we gain by becoming part of SA. Seems we would lose more having to be more open about what we do. Frankly, I don't understand the issue here anyway. Sometimes things worth doing require effort. If our goals are the same, which I believe is fighting spam which in itself is a difficult task, why shy away from it because it may be hard? We have the same goals. SARE gives you are best. Why must it be more? We have active members that work with you all the time. RDJ allows you to get new rules, days maybe hours after a new spam sign is found. And these are TESTED! Not just thrown in. I'm not sure what you're implying, that SA rules are not tested and just thrown in updates randomly? LOL after rereading that it does sound like I meant that. I assure you I did not. I meant that OUR rules are tested even though they are quickly released. It was not meant to reflect on SA's testing abilities at all. FWIW, sa-update lets people get new rules, days maybe hours after a new spam sign is found. And these are TESTED! Not just thrown in. Point taken ;) Being a closed group gives us some abilities that the SA project will never have. Such as? I think there some assumptions are being made that aren't necessarily true. open corpus vs closed. Live feed testing vs overnight GA runs. No public eyes in our discussion lists. Incredibly easy rule
RE: breaking out: thinking abt the 'sa-update *VS* rdj' thread .. .
Title: RE: breaking out: thinking abt the 'sa-update *VS* rdj' thread .. . *sigh* I fear my last reply may either 1) Drive a wedge between SA and SARE 2) Make ppl think SARE vs SA is the norm. I assure everyone that SA and SARE have helped eachother a TON. Many of our requests for help and info to the devs comes back with incredible info and fast. The devs are a great group. And they truely are part of SARE wether they know it or not. So I'm kind of against all this of discussion about SARE and SA. IMHO, leaving them seperate and friendly is the best for everyone. --Chris
RE: Odd local.cf problem
Munroe wrote: I am running SpamAssassin 3.1.4 on a windows mail server, the local.cf file is in /perl/site/etc/mail/spamassassin This is what it looks like: [ comments removed ] rewrite_header Subject [SPAM] report_safe 1 trusted_networks 205.158.155.180 trusted_networks 205.158.155.52 trusted_networks 205.158.154.52 trusted_networks 205.158.154.181 trusted_networks 205.158.154.180 skip_rbl_checks 1 required_score 5.0 As you can see I have added about 6 mailservers as trusted and disabled rbl checking or so I thought. messages from those mail servers (the trusted ones) are still getting bounced for being on a black list. Since spamassassin is running as an exe and is envoked everytime mail is delivered it is loading the new config, I have confirmed that by changing the required_score and I see that change immediatly. For some reason Ican't whitelist or disable rbl checking. Am I forgetting something or doing some thing wrong? You need to show us the headers of an email with the problem. Unless we can see the problem, we are just guessing at solutions. -- Bowie
Re: Spamd not able to drop root privileges at arbitrary times
Theo, In the user's .procmailrc file, there is this stanza: :0fw: spamassassin.lock | /usr/bin/spamc -u username -s 128000 But, I have had this problem occur arbitrarily when no -u username is specified. I think by the time Exim4 gets to the .procmailrc, it has already dropped privileges, so spamc would get called as that user from the user's .procmailrc file. But regardless, sometimes spamd can drop privileges, and sometimes it can't... a ratio of about 1:400 for can't/can. So, I'm not sure if that indicates some sort of problem external to spamd or not? I've seen other reports of this around, but no solutions. Hope this extra information helps, let me know if you need any additional info! Thanks, Ryan Theo Van Dinter wrote: On Wed, Aug 16, 2006 at 09:02:11AM -0400, Ryan Steele wrote: Well, I can verify that the users exist on the server. I'm not sure why spamc would be called by root...it's invoked by a .procmailrc, and passed the -u flag and given the user name. And it arbitrarily won't How is that username determined? Does root's mail get processed via procmail? -- Ryan Steele Systems Administrator [EMAIL PROTECTED] AgoraNet, Inc. (302) 224-2475 314 E. Main Street, Suite 1 (302) 224-2552 (fax) Newark, DE 19711http://www.agora-net.com
Re: Spamd not able to drop root privileges at arbitrary times
On Wed, Aug 16, 2006 at 12:48:14PM -0400, Ryan Steele wrote: But, I have had this problem occur arbitrarily when no -u username is specified. I think by the time Exim4 gets to the .procmailrc, it has already dropped privileges, so spamc would get called as that user from the user's .procmailrc file. But regardless, sometimes spamd can drop Well, if the mail is destined for a user, sure. What if the mail is destined for [EMAIL PROTECTED] ? -- Randomly Generated Tagline: Communist revolutionaries taking over the server room and demanding all the computers in the building or they shoot the sysadmin. - Today's BOFH Excuse pgpz2Os12dHRo.pgp Description: PGP signature
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
decoder wrote: basically, it is a per recipient hash generation that assures that a specific amount of time was required to compute this hash per recipient. Spammers don't have this time, they send thousands of mails per minute. A great solution... for 2002. These days, when most spam is sent through zombies, the spammer isn't using their own CPU time, they're using some random person's home CPU. They can send the same amount of spam in the same amount of time *and* add the hashcash signatures just by using a bigger botnet. -- Kelson Vibber SpeedGate Communications www.speed.net
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kelson wrote: decoder wrote: basically, it is a per recipient hash generation that assures that a specific amount of time was required to compute this hash per recipient. Spammers don't have this time, they send thousands of mails per minute. A great solution... for 2002. These days, when most spam is sent through zombies, the spammer isn't using their own CPU time, they're using some random person's home CPU. They can send the same amount of spam in the same amount of time *and* add the hashcash signatures just by using a bigger botnet. - From the hashcash FAQ: /But won't spammers steal CPU time?/ Spammers already compromise security on many users machines to make so-called Zombie armies to send spam from. However currently the rate at which spammers can send mail on a zombie machine is limited purely by the speed of those machine's internet links. A typical DSL user might be able to send 25 unique messages per second each of size 1KB (assumes 256kbit uplink). Or many more messages per second if the messages are delivered to multiple users at once (using multiple Cc or Bcc recipients). Even a 20-bit stamp takes 1/2 second per recipient on the highest end pc hardware at time of writing. This would slow spammers down by a factor of 10-100 or more per compromised machine (depending on whether the messages sent are sent individually or to many users at once). Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE418RJQIKXnJyDxURAvMsAKCyydpUE6Nc6xhYeJQ7a8muIGb/LACgnsQ7 l6oV6FjcyLD4Nwld0QOJRdw= =syy5 -END PGP SIGNATURE-
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
On Wed, 2006-08-16 at 17:22 +0200, decoder wrote: Well, you can read about the hashcash system at hashcash.org, basically, it is a per recipient hash generation that assures that a specific amount of time was required to compute this hash per recipient. Spammers don't have this time, they send thousands of mails per minute. I think with the rise of botnets hashcash is an out of date solution. These days spammers do have the time, more time than any other bulk sender. List servers on the other hand don't have the time. Derek
Re: breaking out: thinking abt the 'sa-update *VS* rdj' thread .. .
Theo Van Dinter [EMAIL PROTECTED] wrote on 08/16/2006 10:04:19 AM: I was debating whether or not to get involved with this thread, and it looks like the original issue that Richard was concerned about has been addressed so that's good. However, my other issue with the thread so far comes from the misleading or otherwise incorrect information being presented which I'll try to respond to below. Andy Jezierski: I think SARE can put out a new rule for a specific spam problem a lot faster than the SA project, so I'll have to disagree with you here. Wow, there's so much wrapped into this statement that it's hard to figure out what to address first. - put out implies distribution, which is more of a function of how often users check for updates than anything else since otherwise it's people putting files on a website. ie: It doesn't matter if rules are published every 5 minutes if people are only checking once a day. Poor choice of words on my part I suppose, I meant develop new rules and have them available for distribution. - put out also implies development, which SARE probably is faster on. The real question is: Why? My view is that it's manpower. There's a bunch of people in SARE (I don't know the actual number) focused on developing rules. Agreed. That's all they do is rules. Who knows how many ninja's are out there. SpamAssassin has (according to the CREDITS file) 13 people split between rules and code. However not all of those people are active. Also, there tends to be more focus on the code as opposed to the rules. For example, there were 45 commits between 7/1 and today for rules (rulesrc/trunk) from 3 people. There were 135 commits between 7/1 and today for code (trunk) from 7 people. I've always viewed the SA team as being more concerned with the coding and trying to give SA new spam fighting features and not as much with the rules, since in the past there were no rule updates between releases. I suppose I have to change my thinking now with the advent of sa-update. I didn't mean to knock anyone. I think SA is a fantastic product, kudo's to all the developers. And SARE is a great addon to SA, kudo's to the ninja's as well. With the help of both teams, the end users have a fighting chance. Andy
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
decoder wrote: SpamAssassin supports verification of these hashes (this is enabled by default, you only need to configure the mail adresses you accept mails for in the local.cf (http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin_Plugin_Hashcash.html) I read: hashcash_accept [EMAIL PROTECTED] ... Used to specify addresses that we accept HashCash tokens for. You should set it to match all the addresses that you may receive mail at. thus, if I accept traffic for wolfstar.ca, foo.bar.info, and yeahright.com then I would have: hashcash_accept [EMAIL PROTECTED], *.wolfstar.ca, [EMAIL PROTECTED], [EMAIL PROTECTED] ... traffic coming IN to these domains/addresses with an HCS is deemed safer than unmarked traffic and thus will be scored lower. I will send you the plugin this evening so you can try it out (as I am currently on a run:)) Chris Sounds good. I look forward to getting it. -- --Michel Vaillancourt Wolfstar Systems www.wolfstar.ca
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
decoder wrote: This would slow spammers down by a factor of 10-100 or more per compromised machine (depending on whether the messages sent are sent individually or to many users at once). So they get a bigger botnet. There's no shortage of compromised machines out there. -- Kelson Vibber SpeedGate Communications www.speed.net
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
On Wed, August 16, 2006 18:16, Chris Thielen wrote: CoWorker (dialup) -- mail server (office) -- fetchmail (home) -- you can make fetchmail so it does not add the its own recieved headers 1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) [SPF failed: Please see http://spf.pobox.com/why.html?sender=blahblahblah] update Mail::SPF::Query domain is not pobox but openspf -- Benny
Re: Yahoo Received header problem?
At 03:05 16-08-2006, Matthew Newton wrote: I just received an e-mail that had been incorrectly marked as hitting a block list (the SBL in this case, IIRC). The culprit for this seems to be the following first Received header, where a.b.c.d is the address on the BL: Received: from [a.b.c.d] by web55501.mail.re4.yahoo.com via HTTP; Tue, 15 Aug 2006 15:34:33 BST This seems wrong to me? However, my guess is that there is nothing wrong with SpamAssassin, just that Yahoo shouldn't be adding a Received header for a non-SMTP transaction (of course an Section 3.8.2 (Received Lines in Gatewaying) mentions adding a Received header as trace fields for messages originating from non-SMTP environments. The above Yahoo.com Received line is correct. Regards, -sm
Any rules for URLs like this?
An obfuscated URL like that should be fairly easy to detect - are there any rules (e.g. SARE) for these? X-Spam-Report: * 2.0 BAYES_80 BODY: Bayesian spam probability is 80 to 95% * [score: 0.9334] * 3.0 URIBL_SBLXBL Contains a URL listed in the SBL/XBL blocklist * [URIs: heretodayloantomorrow.com] * 1.6 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: heretodayloantomorrow.com] www.]vesselschamplainsharpshootmshouldnth].heretodayloantomorrow.com= -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Apparently the Bush/Rove idea of being a fiscal conservative is to spend money like there's no tomorrow, run up huge deficits, and pray the Rapture happens before the bills come due. -- atul666 in Y! SCOX forum ---
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
Kelson schrieb: decoder wrote: This would slow spammers down by a factor of 10-100 or more per compromised machine (depending on whether the messages sent are sent individually or to many users at once). So they get a bigger botnet. There's no shortage of compromised machines out there. Maybe so. But it sure will be more expensive for most spammers to rent 10 times as many machines. decoder, I'd like a test your code as well. Count me in Dirk
RE: Hashcash plugin to stamp outgoing mails (for postfix only)
Dirk Bonengel wrote: Kelson schrieb: So they get a bigger botnet. There's no shortage of compromised machines out there. Maybe so. But it sure will be more expensive for most spammers to rent 10 times as many machines. Only barely so. And at the same time, it will be much more expensive for legitimate mailing list hosts to keep up with the requirements. At the end of the day, you're punishing list operators/hosts, and merely inconveniencing spammers. Is the collateral damage worth it?
MEDIA: AOL to look for buried tresure!
Title: MEDIA: AOL to look for buried tresure! How the hell did I miss this story yesterday! http://www.thestar.com/NASApp/cs/ContentServer?pagename=thestar/Layout/Article_Type1=Article=1155678611255_pageid=968350072197=969048863851 AOL gets court order to dig for buried bullion Aug. 16, 2006. 01:00 AM TED BRIDIS ASSOCIATED PRESS WASHINGTON-AOL is preparing to dig for buried gold and platinum on property in Massachusetts owned by the parents of a man it sued for sending millions of unwanted spam emails to its customers. AOL said yesterday it intends to search for gold and platinum bars the company believes are hidden near the home of Davis Wolfgang Hawke's parents in Medfield, Mass. The family said it will fight in court to oppose AOL's plans. AOL won a $12.8 million (U.S.) judgment last year in U.S. District Court in Virginia against Hawke but has been unable to contact him to collect any of the money he was ordered to pay in the lawsuit. I don't care if they dig up the entire yard. They're just going to make fools of themselves, said Peggy Greenbaum, Hawke's mother. AOL defended its efforts. This exercise isn't something out of ... Treasure Island, AOL spokesman Nicholas Graham said. This is a court-directed, judge-approved legal process that is simply aimed at responsibly recovering hidden assets.'' To win a judge's permission for the search, AOL submitted receipts reflecting large purchases by Hawke of gold and platinum bars, Graham said. The company indicated it believes Hawke buried the loot on his parents' property using a shovel. Thanks, Chris Santerre SysAdmin and Spamfighter www.rulesemporium.com www.uribl.com
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Coffey, Neal wrote: Dirk Bonengel wrote: Kelson schrieb: So they get a bigger botnet. There's no shortage of compromised machines out there. Maybe so. But it sure will be more expensive for most spammers to rent 10 times as many machines. Only barely so. And at the same time, it will be much more expensive for legitimate mailing list hosts to keep up with the requirements. At the end of the day, you're punishing list operators/hosts, and merely inconveniencing spammers. Is the collateral damage worth it? Mailing lists dont stamp anything. Read the hashcash FAQ part about mailing lists. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE43eqJQIKXnJyDxURAmLbAKCsuxaBXxHerpXTnUP47n6Km1zvqACgvPRd 0k8MreCV7nsjmhFrCfni3iI= =3JY3 -END PGP SIGNATURE-
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
Thanks for the response. Benny Pedersen wrote: 1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) [SPF failed: Please see http://spf.pobox.com/why.html?sender=blahblahblah] update Mail::SPF::Query domain is not pobox but openspf duly noted... I am using debian sarge which has version 1.997-2, so unless there are other major problems I'll just live with an older version right now. On Wed, August 16, 2006 18:16, Chris Thielen wrote: CoWorker (dialup) -- mail server (office) -- fetchmail (home) -- you can make fetchmail so it does not add the its own recieved headers I tried this just now and found that removing the fetchmail headers doesn't change the received header parsing. The fetchmail headers are being ignored because they are found outside the trusted area. [2866] dbg: received-header: found fetchmail marker outside trusted area, ignored [2866] dbg: received-header: parsed as [ ip=24.245.33.51 rdns=c-24-245-33-51.hsd1.mn.comcast.net helo=c-24-245-33-51.hsd1.mn.comcast .net by=mywork.com ident= envfrom= intl=0 id= auth= ] I am going to work around the problem for now with a procmail recipe. I am going to munge the received headers and replace the with SMTP to a false authenticated header. That isn't a pretty solution, nor reliable, but it will serve my purposes for now. Thanks for listening
FuzzyOcr configuration
I seem to be missing something on the configuration of FuzzyOcr, or perhaps my knowledge of how to install plugins is lacking. I initially put this line in /etc/mail/spamassassin/init.pre: loadplugin FuzzyOcr /etc/mail/spamassassin/plugins/FuzzyOcr.pm and spamassassin complains: smtp.cs.utexas.edu$ spamassassin --lint [8948] warn: plugin: failed to load plugin /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm: No such file or directory smtp.cs.utexas.edu$ Huh? I don't understand why it is looking there for FuzzyOcr.pm, but ok, I'll rename it (and edit the path in init.pre): smtp.cs.utexas.edu$ mv /etc/mail/spamassassin/plugins/FuzzyOcr.pm \ /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm smtp.cs.utexas.edu$ spamassassin --lint [9334] warn: Subroutine new redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 56. [9334] warn: Subroutine parse_config redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 66. [9334] warn: Subroutine dummy_check redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 101. [9334] warn: Subroutine wrong_ctype redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 105. [9334] warn: Subroutine corrupt_img redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 119. [9334] warn: Subroutine check_fuzzy_ocr redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 133. smtp.cs.utexas.edu$ Does anyone know why perl is generating these warnings? The plugin seems to work otherwise, i.e. it correctly identifies the images in the sample tar file. Thanks Fletcher
Re: breaking out: thinking abt the 'sa-update *VS* rdj' thread .. .
- Original Message - From: Andy Jezierski There's a bunch of people in SARE (I don't know the actual number) focused on developing rules. Agreed. That's all they do is rules. Who knows how many ninja's are out there. Well, from what I recall, from when my kids were much younger, there were four Teenage Mutant Ninja Turtles: Michaelangelo, Raphael, Leonardo, and Donatello They are all grown up now and are official rule writers for SARE (Chris was a late bloomer and joined the Ninja Turtles later in life). So now there are five: Michaelangelo, Raphael, Leonardo, Donatello and Chris :-p Bill PS, Andy, can you make your font any smaller, it's just not quite magnifing glass size yet...
Re: FuzzyOcr configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fletcher Mattox wrote: I seem to be missing something on the configuration of FuzzyOcr, or perhaps my knowledge of how to install plugins is lacking. I initially put this line in /etc/mail/spamassassin/init.pre: loadplugin FuzzyOcr /etc/mail/spamassassin/plugins/FuzzyOcr.pm and spamassassin complains: smtp.cs.utexas.edu$ spamassassin --lint [8948] warn: plugin: failed to load plugin /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm: No such file or directory smtp.cs.utexas.edu$ Huh? I don't understand why it is looking there for FuzzyOcr.pm, but ok, I'll rename it (and edit the path in init.pre): smtp.cs.utexas.edu$ mv /etc/mail/spamassassin/plugins/FuzzyOcr.pm \ /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm smtp.cs.utexas.edu$ spamassassin --lint [9334] warn: Subroutine new redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 56. [9334] warn: Subroutine parse_config redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 66. [9334] warn: Subroutine dummy_check redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 101. [9334] warn: Subroutine wrong_ctype redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 105. [9334] warn: Subroutine corrupt_img redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 119. [9334] warn: Subroutine check_fuzzy_ocr redefined at /lusr/perl5.8/etc/mail/spamassassin/FuzzyOcr.pm line 133. smtp.cs.utexas.edu$ Does anyone know why perl is generating these warnings? The plugin seems to work otherwise, i.e. it correctly identifies the images in the sample tar file. Thanks Fletcher You should simply extract the tar.gz file into /etc/mail/spamassassin/, there is no need to put anything in pre files, everything is done in the cf file that is shipped :) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE430bJQIKXnJyDxURAhN2AJ0cKn6qKSQnsRECRdyDeEFAVf8IFACeOVPJ llzR3xOPOQrkAias4xr9X10= =Uz8v -END PGP SIGNATURE-
RE: Hashcash plugin to stamp outgoing mails (for postfix only)
decoder wrote: Mailing lists dont stamp anything. Read the hashcash FAQ part about mailing lists. Ok; you're right. Apologies for not reading up on it better. Reading through the whole FAQ, though, it still leaves me with the impression of being far less than ideal. Which is not to say that any solution is perfect. But it seems to have little utility in stopping spam from getting to my inbox. It might stem the tide, but it doesn't help detection any, since it's entirely possible for spam to have a valid hashcash header. In fact, if a valid hashcash header is used to fast-track mail around the more rigorous tests (as the FAQ seems to suggest it should[1]) that actually sounds like a win for spammers to me. Sure, the volume they can send is lower, but now the mails they send are trusted that much *more*. On top of that, it adds another client-side step to signing up for a mailing list, one that's going to be different for every mail client, and I personally have no fondness for a solution that requires the recipient to do anything like that. There are users who barely understand folders in their inbox, let alone rules and filters. Is my understanding wrong? I hope there's just something else I'm not understanding. [1] Your mail has a form of postage on it -- the hashcash stamp -- and sails through anti-spam check-points.
Re: breaking out: thinking abt the 'sa-update *VS* rdj' thread .. .
Bill Landry wrote: - Original Message - From: Andy Jezierski There's a bunch of people in SARE (I don't know the actual number) focused on developing rules. Agreed. That's all they do is rules. Who knows how many ninja's are out there. Well, from what I recall, from when my kids were much younger, there were four Teenage Mutant Ninja Turtles: Michaelangelo, Raphael, Leonardo, and Donatello They are all grown up now and are official rule writers for SARE (Chris was a late bloomer and joined the Ninja Turtles later in life). So now there are five: Michaelangelo, Raphael, Leonardo, Donatello and Chris :-p Bill PS, Andy, can you make your font any smaller, it's just not quite magnifing glass size yet... Sort of reminds me of the Seven Vertically-Challenged small people. HAR! -- -Doc SA/SARE -- Ninja SARE HQ http://www.rulesemporium.com/
Re: Hashcash plugin to stamp outgoing mails (for postfix only)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Coffey, Neal wrote: decoder wrote: Mailing lists dont stamp anything. Read the hashcash FAQ part about mailing lists. Ok; you're right. Apologies for not reading up on it better. Reading through the whole FAQ, though, it still leaves me with the impression of being far less than ideal. Which is not to say that any solution is perfect. But it seems to have little utility in stopping spam from getting to my inbox. It might stem the tide, but it doesn't help detection any, since it's entirely possible for spam to have a valid hashcash header. You are missing the point, hashcash is not a way to detect spam. Hashcash will not increase the score of a spam mail. Hashcash is only a way to decrease a possible score of ham (or letting it through completely, as one wishes) to ensure that a mail arrives even if false positives from, for example, an rbl, strike. The whole system is thus not meant for spam detection but only as a measure to increase the probability that valid mail reaches its destination. In fact, if a valid hashcash header is used to fast-track mail around the more rigorous tests (as the FAQ seems to suggest it should[1]) that actually sounds like a win for spammers to me. Sure, the volume they can send is lower, but now the mails they send are trusted that much *more*. You don't need to autotrust these headers, for example the default spamassassin config only scores about -0.7 for a 20 bit stamp. And if you increase the bits, the score increases. On top of that, it adds another client-side step to signing up for a mailing list, one that's going to be different for every mail client, and I personally have no fondness for a solution that requires the recipient to do anything like that. There are users who barely understand folders in their inbox, let alone rules and filters. That is what I was saying, trying to do this on a per client basis is not a good idea. That's why I wrote this plugin for MTA level stamping. No user interaction required there anymore Is my understanding wrong? I hope there's just something else I'm not understanding. [1] Your mail has a form of postage on it -- the hashcash stamp -- and sails through anti-spam check-points. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE44ETJQIKXnJyDxURAj9PAJ9x0u3nCSFvFXBzJFkY+8M5mpl8kQCfRC6x lWPUVY/TukUOkaauQagYgtU= =jduV -END PGP SIGNATURE-
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
From: Chris Thielen [EMAIL PROTECTED]
I am using fetchmail to retrieve messages from my work account.
However, messages sent to my work account from coworkers are being
tagged with various dynamic IP rules. My setup is something like this:
CoWorker (dialup) -- mail server (office) -- fetchmail (home) --
spamassassin
When a message of this sort is retrieved, I get these rule hits:
4.2 HELO_DYNAMIC_IPADDRRelay HELO'd using suspicious hostname (IP addr
1)
1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
[SPF failed: Please see http://spf.pobox.com/why.html?sender=blahblahblah]
-2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
[score: 0.]
2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[24.245.33.51 listed in dnsbl.sorbs.net]
1.9 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
[24.245.33.51 listed in combined.njabl.org]
-0.1 AWLAWL: From: address is in the auto white-list
From reading this thread:
http://thread.gmane.org/gmane.mail.spam.spamassassin.general/83423/focus=83423
it looks like there isn't a simple workable solution. It seems like the
sender is in the right by sending mail through my work's SMTP server
(the problem would go away if they sent through a relay first, but I
can't dictate how people send messages TO me). As Raimar tried in the
thread above, I added my work server to trusted_networks, and
internal_networks but that's not the right way to handle this, apparently.
Is there a workable solution that doesn't require me to whitelist all my
coworker's IP ranges?
For brute force solutions you could use whitelist_from_rcvd. But even that
is awkward. Is your office server on your trusted list?
{^_^}
Re: Spamd not able to drop root privileges at arbitrary times
How is your procmail invoking spamc? The set of lines defining that
rule might help. It ALMOST sounds like you are missing a lock there.
{^_^}
- Original Message -
From: Ryan Steele [EMAIL PROTECTED]
Theo,
Well, I can verify that the users exist on the server. I'm not sure why
spamc would be called by root...it's invoked by a .procmailrc, and
passed the -u flag and given the user name. And it arbitrarily won't
work for a user that in almost all other instances it *does* work for.
Before, I had a central box running the spamd daemon, and the three
boxes that run in parallel would pass the message/username to that
central box. I've since broken it out, running a spamd daemon on each
of the three boxes, so that the call is made locally to that respective
spamd daemon. (This is to help reduce load). Only now am I seeing
these messages. And like I said, it only happens on one out of every
maybe 400 messages for any given user. Truly odd... Any other thoughts?
Thanks in advance,
Best Regards,
Ryan
Theo Van Dinter wrote:
On Tue, Aug 15, 2006 at 05:12:42PM -0400, Ryan Steele wrote:
hitch. It seems that arbitrarily, spamd is unable to drop root
privileges. Here's the relevant log message:
spamd: still running as root: user not specified with -u, not found, or
set to root, falling back to nobody at /usr/sbin/spamd line 1150,
GEN1596 line 4.
The message generally means that either the user calling spamd doesn't
exist on the spamd server, or more likely spamc is being called by root
and for security reasons spamd switches to nobody.
Re: Spamd not able to drop root privileges at arbitrary times
This should work and would be more generic. I presume you have
DROPPRIVS=yes up near the top of the file. (And once privs are
dropped you don't get them back.) I see that a missing lock is not
the problem, though.
:0fw: spamassassin.lock
| /usr/bin/spamc -u $LOGNAME -s 128000
{^_^}
- Original Message -
From: Ryan Steele [EMAIL PROTECTED]
Theo,
In the user's .procmailrc file, there is this stanza:
:0fw: spamassassin.lock
| /usr/bin/spamc -u username -s 128000
But, I have had this problem occur arbitrarily when no -u username is
specified. I think by the time Exim4 gets to the .procmailrc, it has
already dropped privileges, so spamc would get called as that user from
the user's .procmailrc file. But regardless, sometimes spamd can drop
privileges, and sometimes it can't... a ratio of about 1:400 for
can't/can. So, I'm not sure if that indicates some sort of problem
external to spamd or not? I've seen other reports of this around, but
no solutions. Hope this extra information helps, let me know if you
need any additional info!
Thanks,
Ryan
Theo Van Dinter wrote:
On Wed, Aug 16, 2006 at 09:02:11AM -0400, Ryan Steele wrote:
Well, I can verify that the users exist on the server. I'm not sure why
spamc would be called by root...it's invoked by a .procmailrc, and
passed the -u flag and given the user name. And it arbitrarily won't
How is that username determined? Does root's mail get processed via
procmail?
Re: Recommended latest Perl version
I've been running SA on 5.6.1, but I'm building a new FreeBSD box and its prefered version is 5.8. I noticed that in the SA docs, it mentions performance problems with 5.8. FreeBSD has version 5.6.2 in ports, but I seem to recall that one shouldn't use perl versions that ended in even numbers, 6 is not an even number. 5.6.2 should probably be usable, if you don't have any specific requirements (like the need for some newer or more unusual modules, or Encoder), although the collective memory of its problems is fading, so you'd probably get a better support in case of any problem if you stick to the lang/perl5. Why bother with 5.6.2, when you can have 5.8.8 - it is the best we have for now. Plenty of bugs fixes (including of course some introduced with 5.8.0 :) Mark
Re: Recommended latest Perl version
6 is not an even number. Well... :)
Re: Increase in targeted spams
I asked a well-know spam fighter for an opinion. Here it is: Original Message Subject:Re: [EMAIL PROTECTED]: RE: SPAM: Increase in targeted spams] Date: Wed, 16 Aug 2006 14:05:06 -0700 From: Bill Carton [EMAIL PROTECTED] To: Bill [EMAIL PROTECTED] Here's my list: http://spews.org/html/S3123.html Note only level 1 and 2 are currently bad. 0 level registrars had problems in the past. Directi, for instance, has totally cleaned up its act and now mines NANAS postings for domains to nuke. BC
Re: Registrar RBL: nomination and scoring
On Sun, Aug 13, 2006 at 06:26:18PM -0700, jdow wrote: drily I wonder what the reputation of homelinux.org is these days. (I just posted a couple rules to the FC mailing list about them. A spam was relayed through them to the list followed by two shills who copied the entire message and complained at the bottom pro forma. This is not the first time this has happened.) self-defensively Homelinux.org is owned by dyndns.org, and the company gives out domain names like timesucker.homelinux.org to anyone who applies. In other words, dyndns.org is in business to provide dsl and cable subscribers with routable domains that are automagically updated on the rare occasions when the cable/dsl companies renumber their IP subnets. Each domain under homelinux.org is a separate individual/company/whatever, so please keep that in mind when deciding on the reputation of homelinux.org: you might as well ask the reputation of com or net. Bill (Disclaimer: I'm one of dyndns.org's customers, but I have no stock or other interest in the firm.)
Re: Spamd not able to drop root privileges at arbitrary times
Ryan Steele wrote: Theo, In the user's .procmailrc file, there is this stanza: :0fw: spamassassin.lock | /usr/bin/spamc -u username -s 128000 But, I have had this problem occur arbitrarily when no -u username is specified. I think by the time Exim4 gets to the .procmailrc, it has already dropped privileges, so spamc would get called as that user from the user's .procmailrc file. But regardless, sometimes spamd can drop privileges, and sometimes it can't... a ratio of about 1:400 for can't/can. So, I'm not sure if that indicates some sort of problem external to spamd or not? I've seen other reports of this around, but no solutions. Hope this extra information helps, let me know if you need any additional info! A failure of your system's auth backend could cause this. Are you using something other than flat file /etc/passwd and /etc/group? Daryl
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
Chris Thielen wrote: Thanks for the response. Benny Pedersen wrote: 1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) [SPF failed: Please see http://spf.pobox.com/why.html?sender=blahblahblah] update Mail::SPF::Query domain is not pobox but openspf duly noted... I am using debian sarge which has version 1.997-2, so unless there are other major problems I'll just live with an older version right now. This version of Mail::SPF::Query has no bearing on the configuration problem. On Wed, August 16, 2006 18:16, Chris Thielen wrote: CoWorker (dialup) -- mail server (office) -- fetchmail (home) -- you can make fetchmail so it does not add the its own recieved headers I tried this just now and found that removing the fetchmail headers doesn't change the received header parsing. The fetchmail headers are being ignored because they are found outside the trusted area. [2866] dbg: received-header: found fetchmail marker outside trusted area, ignored [2866] dbg: received-header: parsed as [ ip=24.245.33.51 rdns=c-24-245-33-51.hsd1.mn.comcast.net helo=c-24-245-33-51.hsd1.mn.comcast .net by=mywork.com ident= envfrom= intl=0 id= auth= ] If the fetchmail headers are being ignored then your trust path isn't configured right, even to that relay, so you've got no chance at fixing anything beyond that until you get that taken care of. You need to trust the following (don't bother even setting internal networks): - you server (private and public IPs are good) - your MXes if any - you office mail server After that, hopefully your coworker's submission relay is leaving auth tokens that will further extend your trust path. If it's not (which looks like is the case) then, iff your office mail server is only a submission server and not an incoming MX you can use this patch [1] and configure that server IP using msa_networks. [1] http://people.apache.org/~dos/sa-patches/msa_networks.3.1 Daryl
Re: Yahoo Received header problem?
SM wrote: At 03:05 16-08-2006, Matthew Newton wrote: I just received an e-mail that had been incorrectly marked as hitting a block list (the SBL in this case, IIRC). The culprit for this seems to be the following first Received header, where a.b.c.d is the address on the BL: Received: from [a.b.c.d] by web55501.mail.re4.yahoo.com via HTTP; Tue, 15 Aug 2006 15:34:33 BST This seems wrong to me? However, my guess is that there is nothing wrong with SpamAssassin, just that Yahoo shouldn't be adding a Received header for a non-SMTP transaction (of course an Section 3.8.2 (Received Lines in Gatewaying) mentions adding a Received header as trace fields for messages originating from non-SMTP environments. The above Yahoo.com Received line is correct. Regards, -sm Yes, the received headers for webmail are much preferred over any other X-whatever headers. I can't remember, or have time to look, what IPs in the received line are checked for SBL. We might check all of them for SBL. Usually I wouldn't want to receive any mail from someone in SBL. Of course dynablocks being listed in SBL throws that out the window. Daryl
sa-learn dump output
Hi All, Running sa-learn --dump magic, I get the following: 0.000 0 3 0 non-token data: bayes db version0.000 0 2550 0 non-token data: nspam0.000 0 953 0 non-token data: nham0.000 0 136341 0 non-token data: ntokens0.000 0 1152517342 0 non-token data: oldest atime0.000 0 1155768845 0 non-token data: newest atime0.000 0 1155769625 0 non-token data: last journal sync atime0.000 0 1155301653 0 non-token data: last expiry atime0.000 0 2764800 0 non-token data: last expire atime delta0.000 0 22790 0 non-token data: last expire reduction count Can somebody clarify the meaning of the output for me? Does this indicate that sa-learn has been fed 953 hams and 2550 spams? Or is it just the number of tokens learnt, not necessarily related to the number of mails actually fed to it? Since I only train on false negatives these days, I find it hard to beleive they could have gotten so far out of balance, as they were fairly close the last time I checked. On that note, should I be feeding it more ham at the moment? Regards, Leigh Leigh SharpeNetwork Systems EngineerPacific WirelessPh +61 3 9584 8966Mob 0408 009 502email [EMAIL PROTECTED]web www.pacificwireless.com.au
Re: Registrar RBL: nomination and scoring
From: Bill Horne [EMAIL PROTECTED]
On Sun, Aug 13, 2006 at 06:26:18PM -0700, jdow wrote:
drily I wonder what the reputation of homelinux.org is these days.
(I just posted a couple rules to the FC mailing list about them.
A spam was relayed through them to the list followed by two shills
who copied the entire message and complained at the bottom pro
forma. This is not the first time this has happened.)
self-defensively
Homelinux.org is owned by dyndns.org, and the company gives out domain
names like timesucker.homelinux.org to anyone who applies. In other
words, dyndns.org is in business to provide dsl and cable subscribers
with routable domains that are automagically updated on the rare
occasions when the cable/dsl companies renumber their IP subnets.
Each domain under homelinux.org is a separate individual/company/whatever,
so please keep that in mind when deciding on the reputation of
homelinux.org: you might as well ask the reputation of com or net.
Bill
(Disclaimer: I'm one of dyndns.org's customers, but I have no stock or other
interest in the firm.)
I use dyndns, privately, myself. (I do not publish and use that address
publicly.) I've not seen problems with spoo.dyndns.net or any of the
others. But I have seen more than one with homelinux.org. Maybe they
do not have that one under control yet.
{^_^}
