preliminary SPF_PASS results #1
SPF_PASS with S/O ratio for the domain of less than 0.5: S/O count domain -- - 0.1283 491 lists.sourceforge.net 0.0197 254 incubator.apache.org 0.0148 203 securityfocus.com 0.0050 199 nl.linux.org 0. 194 humbolt.nl.linux.org 0. 186 matilda.caradhras.net 0. 156 taint.org 0. 114 jmason.org 0. 90 health.webmd.com 0.2359 89 hotmail.com 0. 71 httpd.apache.org 0. 68 redhat.com 0. 63 cbsig.com 0. 59 q.go.com 0. 45 hughes-family.org 0. 38 newsletters.online.com 0. 27 foolsubs.com 0. 25 newsletters.aetv.com 0. 25 habeas.com 0. 24 fedweek.sparklist.com 0. 23 ms3.lga2.nytimes.com 0. 22 samba.org 0. 20 sourceforge.net 0. 20 o2w.nl 0.1579 19 osdl.org 0. 18 foodfight.org 0. 17 match.com 0. 16 gate.acme.com 0. 16 amazon.co.uk 0. 15 ironport.com 0. 15 email.bn.com 0. 14 kalypso.caradhras.net 0.0909 11 bugzilla.spamassassin.org 0. 11 wellsfargomortgage.rsc03.com 0. 10 cs.columbia.edu 0. 9 paypal.com 0. 9 info.aa.com 0. 8 lafn.org 0. 8 in.m1e.net 0. 8 enews.buy.com 0. 7 universalstudios.m0.net 0. 7 mail.classmates.com 0. 7 aexp.com 0. 6 nfl.bounce.ed10.net 0. 6 b.discovery.chtah.com 0.2000 5 b.circuitcity.chtah.com 0. 5 sho.m0.net 0. 5 news.hickoryfarms.com 0. 5 news.fandango.com 0. 5 bounce.exacttarget.com 0. 4 zork.net 0. 4 wurtel.net 0. 4 spinnaker.de 0. 4 pathname.com 0. 4 netflix.com 0. 4 lorentz.leidenuniv.nl 0. 4 frost.yourmailinglistprovider.net 0. 4 fanfiction.com 0. 4 b.ng.chtah.com 0. 3 yackley.org 0. 3 v2.listbox.com 0. 3 special.polo.com 0. 3 shop.walmart.com 0. 3 membership.wgbh.org 0. 3 lordandtaylor.com 0. 3 ijs.si 0. 3 gap.m0.net 0. 3 freebsd.org 0. 3 filenes.com 0. 3 fdd.com 0. 3 convoglio.com 0. 3 b.m.sharperimage.com 0. 3 b.ems.chtah.com 0. 3 b.e.eddiebauer.com 0. 3 actionnetwork.org 0. 2 welcome.aexp.com 0. 2 vsd.m0.net 0. 2 transgaming.com 0. 2 tensilica.com 0. 2 talkmatch.com 0. 2 shocknetwork.com 0. 2 prolocation.net 0. 2 perl.org 0. 2 nova.sparklist.com 0. 2 news.crateandbarrel.com 0. 2 network-theory.co.uk 0. 2 lists.mlb.com 0. 2 kos.to 0. 2 kitenet.net 0. 2 imdb.com 0. 2 hensema.net 0. 2 gnu.org 0. 2 franz.wgbh.org 0. 2 email.payless.com 0. 2 email.kraftfoods.com 0. 2 digitalimpact.com 0. 2 dell.m0.net 0. 2 coe.montana.edu 0. 2 codepoet.org 0. 2 bounce3.rm04.net 0. 2 bounce.rm02.net 0. 2 bananarepublic.m0.net 0. 2 b.e.nordstrom.com 0. 2 b.e.llbean.com 0. 2 apr.apache.org 0. 2 anntaylor.bounce.ed10.net 0. 1 wincent.org 0. 1 wcg.org 0. 1 twobikes.ottawa.on.ca 0. 1 tjmaxx.bounce.ed10.net 0. 1 subversion.tigris.org 0. 1 student.utwente.nl 0. 1 speakeasy.net 0. 1 spamarrest.com 0. 1 softwaredesigner.com 0. 1 rungie.com 0. 1 rowman.com 0. 1 roe.ch 0. 1 radio.clarkhoward.com 0. 1 pulpe.fr 0. 1 pointshare.com 0. 1 ovm1.net 0. 1 news.krispykreme.com 0. 1 nai.com 0. 1 mx.gw.com 0. 1 msn.com 0. 1 montana.ymlpnet.com 0. 1 lga2.nytimes.com 0. 1 iscomp.com 0. 1 intrstar.net 0. 1 in.roving.com 0. 1 imladris.surriel.com 0. 1 ictlx034.civ.utwente.nl 0. 1 hornstra.com 0. 1 garmin.com 0. 1 ga3.org 0. 1 email.staples-deals.com 0. 1 email.lifetimetelevision.com 0. 1 email.brandsaver.com 0. 1 email.bose.com 0. 1 eloan.com 0. 1 ebewe.com 0. 1 ebay.com 0. 1 e.staples-deals.com 0. 1 decoy.wox.org 0. 1 csh.rit.edu 0. 1 compusa.emsg.net 0. 1 complete.org 0. 1 bounces.bluehornet.com 0. 1 bounces.amazon.com 0. 1 bender.home.hensema.net 0. 1 b.email.lowes.com 0. 1 b.elist.compusa.com 0.
preliminary SPF_PASS results #2
SPF_PASS with S/O ratio for the domain of more than 0.5: S/O count domain -- - 0.6381 16193 bounce2.pobox.com 0.9971 347 excite.com 1. 344 aol.com 1. 233 earthlink.net 1. 167 caleandb.us 1. 153 adverpagemail.com 1. 139 tom.com 1. 134 caelivit.biz 1. 98 beerisun.us 1. 98 adelphia.net 1. 97 telus.net 1. 89 zipmail.com.br 0.9630 81 amazon.com 0.9359 78 juno.com 1. 77 bounces.bsmads.net 1. 73 bounce.bsmads.net 1. 72 verizon.net 1. 67 dartmail.net 1. 62 asandox.com 1. 58 havagreatday.com 1. 58 brimshet.us 1. 56 mail.subscribe.ru 1. 48 blurbeke.us 1. 48 bevivek.com 1. 47 o2.pl 1. 47 mem02bsminc.com 1. 43 163.net 1. 41 bluecom.no 1. 38 lstmng-bsm02.com 1. 37 lstmng-bsm01.com 1. 36 netvigator.com 1. 36 microsoft.com 1. 36 img1host.com 0.9444 36 hushmail.com 1. 31 service.bsmads.net 1. 27 blueyonder.co.uk 0.9259 27 bellsouth.net 0.7037 27 gmx.net 0.7308 26 gmail.com 1. 25 terra.es 1. 24 mem01bsminc.com 1. 24 eastlink.ca 1. 23 hayndale.biz 1. 21 ny.host-bsminc02.com 1. 20 lstmng-bsm04.com 1. 20 aptimail.aptimusvaluenetwork.com 1. 19 express4800.com 1. 18 golfshore.com 0.9444 18 tiscali.it 1. 17 netzero.net 1. 16 ozu.es 1. 16 img2host.com 1. 16 abv.bg 1. 15 topmail.de 1. 15 pop.com.br 1. 15 megaherocredit.com 0.5000 15 kluge.net 1. 14 express6800.com 1. 13 gbg.bg 1. 13 flashmail.com 1. 13 daum.com 1. 13 cushingreen.com 1. 13 cal.host-bsminc02.com 1. 13 blue-mx04.net 1. 12 softhome.net 1. 12 scsxp.com 1. 12 osn.de 1. 12 brimuhet.us 1. 12 bol.com.br 1. 12 barbadoslily.com 0.9167 12 google.com 1. 11 gte.net 1. 11 bestdirectvalue.com 1. 10 poczta.onet.pl 1. 10 myway.com 1. 10 email.ro 1. 9 primposta.com 1. 9 postdirect.com 1. 9 pobox.sk 1. 9 interia.pl 1. 9 inbox.lv 1. 9 hush.com 1. 9 clientcampaign1.com 1. 9 blue-mx03.net 1. 9 blue-mx02.net 1. 9 blandfordia.com 1. 8 uol.com.br 1. 8 tspre.org 1. 8 pnetcs.com 1. 8 gyuvetch.bg 1. 8 caramail.com 1. 7 webtv.net 1. 7 tiscalinet.it 1. 7 openingdeals.com 1. 7 equifax-mail.com 1. 7 catholic.org 1. 7 bluefame.com 0.7143 7 gmx.de 1. 6 yandex.ru 1. 6 worldonline.de 1. 6 tvnet.lv 1. 6 srbxcp.com 1. 6 seznam.cz 1. 6 sbespx.com 1. 6 msg.newdayoffers.com 1. 6 hush.ai 1. 6 earth9.com 1. 6 directsavingsoffer.com 1. 6 bsmads.net 1. 6 arcada.fi 1. 6 all-great-now.biz 1. 5 zmail.sk 1. 5 urgentalert.biz 1. 5 sxpssbs.com 1. 5 sbrse.com 1. 5 pobox.com 1. 5 nameplanet.com 1. 5 maillist.ru 1. 5 mailbox2.every1.net 1. 5 lstmng-bsm03.com 1. 5 idamshep.us 1. 5 flowgo.com 1. 5 fastmail.ca 1. 5 directherocredit.com 1. 5 bsmads.com 1. 5 brimhetb.us 1. 5 bierwgul.us 1. 4 zinester.com 1. 4 worldkey.net 1. 4 tsvrdret.com 1. 4 spray.se 1. 4 shipchartering.org 1. 4 reportedblond.com 1. 4 quick.cz 1. 4 op.pl 1. 4 msg.buttoncactus.com 1. 4 lycos.co.uk 1. 4 i-infonews.com 1. 4 ewebmailer.com 1. 4 collegeclub.com 1. 4 bernd.de 1. 4 auto.at 1. 4 airtel.net 1. 4 access-one.com 1. 3 zip.netatlantic.com 1. 3 xraksicbr.gmncc.com 1. 3 world-foundation.org 1. 3 web-inetmail.com 1. 3 waylest.com 1. 3 wanadoo.es 1. 3 telusplanet.net 1. 3 strikeacknowledge.com 1. 3 sndr-bsminc01.com 1. 3 sify.com 1. 3 sfgate.com 1. 3 ptd.net 1. 3 personales.com 1. 3 ntlworld.com 1. 3 join-us-now.net 1. 3 isp.com 1. 3 info.gamanetwork.com 1. 3 gradu8.every1.net 1. 3 gmcc.ab.ca 1. 3 globalnet.co.uk 1. 3 gjtsqdepj.gmncc.com 1.
initial analysis of SPF_PASS results
First, large ISPs seem to be the origination point for a *lot* of spam. Second, here's my list of the domains we could potentially whitelist for SPF_PASS results (high count, good ratio, not biased towards open source folks). 0. 90 health.webmd.com 0. 27 foolsubs.com 0. 23 ms3.lga2.nytimes.com (list *.nytimes.com ?) 0. 17 match.com 0. 9 paypal.com For a different and even less biased approach, I took the listings with 0.01 or lower S/O ratio and ranked them by SenderBase volume (entries above 6.0 on the volume scale). Note that I just extracted registrar-level domain names from the SPF domain lists, so some of these are definitely not completely clean or are not immediately whitelistable. domain volume whitelist? -- -- ebay.com7.5 yeah amazon.com 6.7 yeah speakeasy.net 6.6 paypal.com 6.6 yeah msn.com 6.6 roving.com 6.5 nytimes.com 6.5 yeah m0.net 6.5 classmates.com 6.5 exacttarget.com 6.4 sparklist.com 6.2 sourceforge.net 6.1 securityfocus.com 6.1 spamarrest.com 6.0 rm04.net6.0 redhat.com 6.0 foolsubs.com6.0 yeah bluehornet.com 6.0 So, based on all that, I'm thinking we could experimentally add SPF_PASS whitelists for: ebay.com amazon.com paypal.com nytimes.com foolsubs.com webmd.com match.com I checked NANAE and the above domans seem to be pretty clean and this jives with my recollection. -- Daniel Quinlan http://www.pathname.com/~quinlan/
[Bug 4072] New: SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 Summary: SPF_PASS false match Product: Spamassassin Version: SVN Trunk (Latest Devel Version) Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P5 Component: Rules (Eval Tests) AssignedTo: dev@spamassassin.apache.org ReportedBy: [EMAIL PROTECTED] I can't see why this message generates an SPF_PASS result on current SVN trunk, but it does. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 18:50 --- Created an attachment (id=2595) -- (http://bugzilla.spamassassin.org/attachment.cgi?id=2595action=view) spam message --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
RE: RFC: New subproject, BlogSpamAssassin
Do we have a mailing list yet ;) or are we using large CC's for the near future. I just noticed http://wiki.apache.org/spamassassin/BlogSpamAssassin/ and thought a public mailing list might save Henry some time. = Harry Join team plico. http://www.hjackson.org/cgi-bin/folding/index.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Bug 4024] SPF and X-Envelope-From and sendmail
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024 --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 19:01 --- What I'm suggesting has nothing to do with SPF checks. It only has to do with determining when we can trust the X-Envelope-From, Envelope-Sender and/or Return Path found in a message, and when we can't. If these headers are found above the last trusted relay's received header, we can trust them. By modifying the current regexes, used to determine if we can use the 3 aforementioned headers, to include a token that appears in the last trusted relay's received header (and no sooner, but likely also later) we can determine whether or not we trust those 3 headers. I'll write a patch tonight if I can get some other work out of the way. Daryl --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 19:10 --- Subject: Re: SPF_PASS false match It should pass, AOL's spf records (v1 and 2) both end in ?all Well, at least it shouldn't fail. I can't remember how ?all is handled in the code. Daryl --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 19:16 --- Subject: Re: SPF_PASS false match Right, doh! Weird. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: rules needing work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Quinlan writes: Rules with the largest RANK drops from 3.0 to now. The body and Subject: ones probably need the most work. The rest are probably lost causes. I suggest we drop them, if their RANK is sufficiently low and nobody steps up to fix them; it's about time some rules (at least body rules that is) finally got deleted from the default ruleset ;) I don't have strong feelings about any apart from ALL_TRUSTED. - --j. broken! -0.17 ALL_TRUSTED work needed: -0.32 UNIVERSITY_DIPLOMAS -0.26 STOCK_PICK -0.18 STOCK_ALERT -0.15 SUBJECT_DRUG_GAP_S -0.14 STRONG_BUY -0.14 DEEP_DISC_MEDS -0.13 DRUGS_PAIN -0.11 REVERSE_AGING -0.11 BANG_OPRAH -0.1 NO_CREDIT_CHECK -0.1 WE_HONOR_ALL not sure: -0.34 HTML_NONELEMENT_50_60 -0.23 HELO_DYNAMIC_OOL -0.21 HTML_BADTAG_20_30 -0.2 MIME_HTML_ONLY_MULTI -0.2 HTML_NONELEMENT_40_50 -0.19 HTML_FONT_SIZE_NONE -0.19 HTML_FONT_SIZE_TINY -0.19 HTML_BADTAG_30_40 -0.18 HTML_BADTAG_90_100 -0.16 HDR_ORDER_TRIMRS -0.16 X_ORIG_IP_NOT_IPV4 -0.11 HTML_NONELEMENT_90_100 -0.11 HELO_DYNAMIC_ATTBI -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB4gH+MJF5cimLx9ARAqnmAJ4k187nq9W0n0BJW5+rD5ig69FUDgCgjD/z s1PNnWjFZWB1Q8+oD2rnKUk= =3jnH -END PGP SIGNATURE-
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 20:20 --- Subject: Re: SPF_PASS false match It's not the SPF plugin, it's Mail::SPF::Query returning: passPlease see http://spf.pobox.com/why.html?sender=efullerdrfc%40aol.comip=204.152.189.113receiver=my.domain.net: 113.189.152.204.wl.trusted-forwarder.org found --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: initial analysis of SPF_PASS results
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Quinlan writes: First, large ISPs seem to be the origination point for a *lot* of spam. Large ISPs' outbound relays, or direct from their dynamic pools? e.g. blueyonder.co.uk list their dyn pools in their SPF record, which is unfortunate but legal. Second, here's my list of the domains we could potentially whitelist for SPF_PASS results (high count, good ratio, not biased towards open source folks). 0. 90 health.webmd.com 0. 27 foolsubs.com 0. 23 ms3.lga2.nytimes.com (list *.nytimes.com ?) 0. 17 match.com 0. 9 paypal.com +1 -- I can go for that. (Worth noting that I *don't* think we should also apply the converse, treating mails from those doms that don't fix the SPF record as forged; we'd need to do separate analysis on that.) For a different and even less biased approach, I took the listings with 0.01 or lower S/O ratio and ranked them by SenderBase volume (entries above 6.0 on the volume scale). Note that I just extracted registrar-level domain names from the SPF domain lists, so some of these are definitely not completely clean or are not immediately whitelistable. domain volume whitelist? -- -- ebay.com7.5 yeah amazon.com 6.7 yeah speakeasy.net 6.6 paypal.com 6.6 yeah msn.com 6.6 roving.com 6.5 nytimes.com 6.5 yeah m0.net 6.5 classmates.com 6.5 exacttarget.com 6.4 sparklist.com 6.2 sourceforge.net 6.1 securityfocus.com 6.1 spamarrest.com 6.0 rm04.net6.0 redhat.com 6.0 foolsubs.com6.0 yeah bluehornet.com 6.0 So, based on all that, I'm thinking we could experimentally add SPF_PASS whitelists for: ebay.com amazon.com paypal.com nytimes.com foolsubs.com webmd.com match.com I checked NANAE and the above domans seem to be pretty clean and this jives with my recollection. +1. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB4gLNMJF5cimLx9ARAn3CAKC7V80ycFkJrP+8bE3oP2T85VQ4NwCgi5t6 GdGMdM89ze4fvC/9l/uDdJ0= =jXd3 -END PGP SIGNATURE-
Re: initial analysis of SPF_PASS results
Large ISPs' outbound relays, or direct from their dynamic pools? e.g. blueyonder.co.uk list their dyn pools in their SPF record, which is unfortunate but legal. I suspect some of that, plus a lot of whatever bug is causing that AOL SPF_PASS false match I reported. That was the first reputatable ISP I checked for SPF_PASS hits vs. their MAIL FROM in my spam folder, so I suspect there are a lot more problems that way. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/
[Bug 3998] Add support for Habeas v2
http://bugzilla.spamassassin.org/show_bug.cgi?id=3998 --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 21:30 --- H... okay, then, I revoke my -1. It might be clearer and cleaner to have a single entry point (eval test) for all of the Habeas rules. Can you please describe the automated testing a bit? I just want to know that we're not giving out bonus points for something easily forged. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3998] Add support for Habeas v2
http://bugzilla.spamassassin.org/show_bug.cgi?id=3998 --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 21:32 --- Carl, Can you submit an individual CLA so we can accept this patch? Note: we have received the corporate CLA for Habeas, so we just need CLAs for any individuals who will be contributing code. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 21:42 --- yeah. basically, it looks like we're passing trusted = 1 to Mail::SPF::Query, and according to the perldoc: The default mechanism for trusted=1 is include:spf.trusted-forwarder.org. [...] Set trusted=1 to turned on automatic trusted_forwarder process- ing. The mechanism include:spf.trusted-forwarder.org is used just before a -all or ?all. The precise circumstances are somewhat more complicated, but it does get the case of v=spf1 -all right -- i.e. spf.trusted-forwarder.org is not checked. [...] $query-trusted_forwarder() my ($result, $smtp_comment, $header_comment) = $query-best_guess(); It is possible that the message is coming through a known-good relay like acm.org or pobox.com. During the transitional period, many legitimate services may appear to forge a sender address: for example, a news website may have a send me this article in email link. The trusted-forwarder.org domain is a whitelist of known-good hosts that either forward mail or perform legitimate envelope sender forgery. include:spf.trusted-forwarder.org This will return either pass or neutral. So aol's ?all in their record causes the trusted-forwarder.org lookup, which apparently has kernel.org in it, either incorrectly, or kernel.org didn't actually check the mail actually came from aol... trusted-forwarder.org, btw, has this in their wl: *.189.152.204.wl.trusted-forwarder.org. 43200 IN A 127.0.0.2 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4052] SpamAssassin rules file: Chinese subject and body tests
http://bugzilla.spamassassin.org/show_bug.cgi?id=4052 [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]| --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 23:31 --- 1. In our experience, patterns which span 4 or more words, are often more effective at catching a small set of spam, but with very low false positive rates, than patterns which match only 1 or 2 words. Have you tried modifying the generator so that it generates longer patterns from the corpus? We have finished the experiments on this issue. The Chinese_rules.cf with different length of patterns are at the following links: (Note: A Chinese character is encoded by 2 bytes) 1. Subject and Body patterns are about 4 bytes: http://www.ccert.edu.cn/spam/sa/Chinese_rules.cf_4_4 2. Subject patterns are about 4 bytes; Body patterns are about 6 bytes: http://www.ccert.edu.cn/spam/sa/Chinese_rules.cf_4_6 3. Subject patterns are about 6 bytes; Body patterns are about 8 bytes: http://www.ccert.edu.cn/spam/sa/Chinese_rules.cf_6_8 4. Subject patterns are about 8 bytes; Body patterns are about 10 bytes: http://www.ccert.edu.cn/spam/sa/Chinese_rules.cf_8_10 And our experience is: Subject patterns span 4 or more bytes and body paterns span 6 or more bytes are a good choice. We have updated our generator (Thank Justin for the suggestion) and I think the comming versions of Chinese_rules.cf will reach the folowing recall/error rates: # Test against 20322 spam and 99689 ham # (using only the Chinese_rules.cf) # # Threshold Spam recall Ham error # 0.5 92.8% 1.2% # 1.0 90.6% 0.5% # 1.5 89.0% 0.3% # 2.0 86.7% 0.1% # 2.5 84.6% 0.1% # 3.0 82.3% 0.0% # 3.5 80.2% 0.0% # 4.0 78.3% 0.0% # 4.5 76.5% 0.0% # # It takes 0.03 seconds to scan an email with size 2013.54 bytes (P4-2.8G CPU) Best, Tran --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4052] SpamAssassin rules file: Chinese subject and body tests
http://bugzilla.spamassassin.org/show_bug.cgi?id=4052 --- Additional Comments From [EMAIL PROTECTED] 2005-01-09 23:39 --- Would it be possible for you to sign and fax an Apache CLA so that we can incorporate these (or at least test them)? We have faxed a signed CCLA (Duan Haixin signed) to the ASF. Please notify me when you received it. best, Tran --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4052] SpamAssassin rules file: Chinese subject and body tests
http://bugzilla.spamassassin.org/show_bug.cgi?id=4052 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 00:47 --- Subject: Re: SpamAssassin rules file: Chinese subject and body tests We have faxed a signed CCLA (Duan Haixin signed) to the ASF. Please notify me when you received it. Great! Can you please submit an Individual CLA as well? We need that too. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3968] [review] IP_IN_RESERVED_RANGE out of date
http://bugzilla.spamassassin.org/show_bug.cgi?id=3968 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 00:59 --- Just spent a couple of hours trying to understand why SA 3.0.0 was giving -2.8 to some spam from a 72/8 network (not being overly familiar with the inner workings), and realized it was the trusted/untrusted algorithm in Received.pm:parse_received_headers acting up. Why is SA trusting these reserved addresses anyway ? People should not be using random reserved blocks for NAT (which I assume is the reason for the auto-trust algorithm), they should be using the RFC 1918 blocks 10/8, 172.16/12, 192.168/16. We certainly should not be trusting mail from reserved blocks; rather the reverse I would think. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 3968] IP_IN_RESERVED_RANGE should go
http://bugzilla.spamassassin.org/show_bug.cgi?id=3968 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[review]|IP_IN_RESERVED_RANGE should |IP_IN_RESERVED_RANGE out of |go |date| Target Milestone|3.0.2 |3.1.0 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 02:03 --- reopening --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: RFC: New subproject, BlogSpamAssassin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Harry, I wanted to say thank you for starting this and a thank you to everyone who's interested. I'm just now catching up on all of my mailing list email back from around Christmas and Matt Mullenweg had forwarded the original announcement email to me. I help run a web hosting company that found itself at the center of this last round of comment spam problems. We're a somewhat unique place in that we were founded by developers: myself, Dean (developer of Textile and Textpattern), Brad Choate (who later left for sixapart), David Heinemeier Hansson (Ruby on rails and Instiki), Matt Mullenweg (Wordpress), Rickard Andersson (PunBB), Marten Veldthuis (Epilog) and Noel Jackson (Photostack). We were already using mod_security (and mod_dosevasive) for a number of things and started immediately applying those to comment and trackback spam, as well put together an mailing list for a lot of the developers to hash ideas, for us to initiate the development of some other apache modules, how to leverage our rsyncs of to discuss the results of log analyses and for everyone to discuss some trends they notice. Then before the holidays, I set up a server with a Trac installation, Subversion repositories, SVN::Notify hooks and several mailing lists at http://cspamhaus.com/ as a way to organize our own efforts. I'd be perfectly willing and happy to open up to everyone, it's there and ready to go. Thanks, J On Jan 9, 2005, at 5:11 PM, Harry wrote: Do we have a mailing list yet ;) or are we using large CC's for the near future. I just noticed http://wiki.apache.org/spamassassin/BlogSpamAssassin/ and thought a public mailing list might save Henry some time. = Harry Join team plico. http://www.hjackson.org/cgi-bin/folding/index.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQeJS+FUyB+ajXkCLEQIZLQCdEDBVPlRdQk7YgfnCY/tc/tQ7+ScAoJ6q XcWfnTQceI52FuGak1GHRpgE =DDI8 -END PGP SIGNATURE-
[Bug 3968] IP_IN_RESERVED_RANGE should go
http://bugzilla.spamassassin.org/show_bug.cgi?id=3968 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|REOPENED|NEW --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 02:04 --- working on this and testing patch Andrew, can you attach your bug (Create a New Attachment link on this page)? --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: RFC: New subproject, BlogSpamAssassin
--- Jason Hoffman [EMAIL PROTECTED] wrote: Hi Harry, I wanted to say thank you for starting this and a thank you to everyone who's interested. I believe that thanks belongs to Henry. Then before the holidays, I set up a server with a Trac installation, Subversion repositories, SVN::Notify hooks and several mailing lists at http://cspamhaus.com/ as a way to organize our own efforts. I'd be perfectly willing and happy to open up to everyone, it's there and ready to go. I am not sure what Henry's plans are. I believe we are awaiting Apache approval and then the project is on the move. Harry __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
[Bug 4055] ALL_TRUSTED on almost everything if server in internal network and trusted_networks not set
http://bugzilla.spamassassin.org/show_bug.cgi?id=4055 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 03:42 --- SpamAssassin trusts the first public IP as it assumes that it is your border gateway. Would it be possible then to get the server IP address not by resolving it's name but by enumerating it's interfaces? I don't know if it is possible to implement portably. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Target Milestone of Future is harmful
I would like to suggest that having a Target Milestone of Future for a bug is harmful. It was probably necessary when you were trying to get 3.0.0 out and you were not sure what the next verson number would be, but now it seems to be a way for a bug to fall into a black hole. It seems that if a bug is not grabbed by someone within a few hours of being submitted, it is lost. Tom schulz Applied Dynamics Intl. [EMAIL PROTECTED]
Re: RFC: New subproject, BlogSpamAssassin
On Mon, Jan 10, 2005 at 02:25:43AM -0800, Harry wrote: I am not sure what Henry's plans are. I believe we are awaiting Apache approval and then the project is on the move. I think that it is very important to NOT wait for approval to being the process of getting something working. In fact, I'm sure that any sort of approval will come much faster when there is a defined set of goals and people already working towards those goals (ie code or at least lots of forward thinking stuff on paper/wiki). An idea doesn't need a mailing list to take off. We already have a mailing list, the SA users list. This is where this idea should begin taking shape. When the amount of traffic about this topic becomes large enough then a new mailing list can be spun off. The last thing folks should be doing should be waiting on the SA PMC to approve this idea. If the idea truly has merit then it should spring forward and code should be produced and at some point approval will be an obvious next step. Michael pgpo2n7m2PKYn.pgp Description: PGP signature
Re: RFC: New subproject, BlogSpamAssassin
Michael Parker [EMAIL PROTECTED] writes: I think that it is very important to NOT wait for approval to being the process of getting something working. In fact, I'm sure that any sort of approval will come much faster when there is a defined set of goals and people already working towards those goals (ie code or at least lots of forward thinking stuff on paper/wiki). +1 (that's 100% agreement for the people new to Apache) An idea doesn't need a mailing list to take off. We already have a mailing list, the SA users list. This is where this idea should begin taking shape. When the amount of traffic about this topic becomes large enough then a new mailing list can be spun off. Also agreed. Using SA lists initially will open up the project to people already interested in the area. The last thing folks should be doing should be waiting on the SA PMC to approve this idea. If the idea truly has merit then it should spring forward and code should be produced and at some point approval will be an obvious next step. I think Henry has done a good job putting together a worthy proposal. What is needed now is critical mass. What I want to avoid is the PMC creating a subproject ... and being asked to destroy it in 12 months time due to inactivity. I don't want us to stall or anything, just have some reasonable confidence level. :-) Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/
Re: Target Milestone of Future is harmful
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Schulz writes: I would like to suggest that having a Target Milestone of Future for a bug is harmful. It was probably necessary when you were trying to get 3.0.0 out and you were not sure what the next verson number would be, but now it seems to be a way for a bug to fall into a black hole. It seems that if a bug is not grabbed by someone within a few hours of being submitted, it is lost. It's a manageability thing. We don't have someone who can sit there continually reprioritising bugs :( I suggest that if you have bugs with TM set to Future, and you think they're implementable sooner ;) -- feel free to post a comment and pipe up. In particular, getting a patch that implements the feature is a *lot* more likely to get a bug a solid milestone. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB4sycMJF5cimLx9ARAkTQAJ9rgwfZb2/vfyt9fjkNc5McdUdRCwCgifvP 0o8X6l0A6wBmqck+mU2Hh/E= =b1up -END PGP SIGNATURE-
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 10:43 --- trusted=1 was recommended usage, at one stage. I suggest we drop it, since that'll also save a DNS lookup. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4055] ALL_TRUSTED on almost everything if server in internal network and trusted_networks not set
http://bugzilla.spamassassin.org/show_bug.cgi?id=4055 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 10:45 --- 'Would it be possible then to get the server IP address not by resolving it's name but by enumerating it's interfaces? I don't know if it is possible to implement portably.' unfortunately it's *very* hard to do portably, and I'd prefer not to have code at such a key phase running differently on different platforms... --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 10:48 --- daryl -- I'm not sure your position is correct. it's entirely plausible that a *trusted* relay could forward the mail with a new envelope-sender address. my fetchmail setup, for exmaple, does this; also if the mail is resent via a Mailman/ezmlm mailing list, that will also do that. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4068] SpamAssassin doesn't follow RFCs 822, 2045, and 2046
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 11:36 ---
If this is really an issue (all places where I used SA till now converted the
CRLF to Unix LF first), we could look at the newline of the first header (most
probably a Return-Path or Received line added by some relatively trusted
server) and use that one for our own headers. Plus maybe an option a la
add_header_terminator { auto | crlf | lf | cr } (default: auto)
If this is really an issue -- any real-world examples?
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
Re: Target Milestone of Future is harmful
Justin Mason said: It's a manageability thing. Another way to look at is that the only person you can be certain has an interest in a new bug report is the one who submitted it. If the target milestone is still Future and you feel strongly about it, then it is up to you to evangelize the bug report until a developer is convinced to change the milestone. Submitting a patch is one of the most effective ways to do that. I think that a bug remaining with target Future is more symptom than cause. It allows bug reports that appear not to be important to address right now to not get lost while still being mostly ignored. Anyone who cares about a specific bug report should speak up and make their case for it. -- Sidney Markowitz http://www.sidney.com
[Bug 4068] SpamAssassin doesn't follow RFCs 822, 2045, and 2046
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 12:00 --- as Tony said -- it's not simply a matter of RFC-2822 compliance, as a lot of UNIX mail software will barf on input messages that contain CR-LFs instead of just LFs. IIRC, we use the platform default -- so LF on UNIX, and CRLF on windows -- and assume the caller will canonicalise the input message in the first place. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3968] IP_IN_RESERVED_RANGE should go
http://bugzilla.spamassassin.org/show_bug.cgi?id=3968 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 12:11 --- Done. IP_IS_IN_RESERVED is no longer used in trunk. A new variable, IP_PRIVATE describes address spaces that are not publicly routeable and is used in its place. I tested this out and the results are definitively better for all code that was previously using the IP_IS_IN_RESERVED. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 [EMAIL PROTECTED] changed: What|Removed |Added CC||dev@spamassassin.apache.org AssignedTo|dev@spamassassin.apache.org |[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 13:27 --- fixing --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 13:27 --- done, checked into trunk --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 13:40 --- Subject: Re: SPF_PASS false match On Mon, Jan 10, 2005 at 01:27:59PM -0800, [EMAIL PROTECTED] wrote: done, checked into trunk Do we want to fix this for 3.0.3, or just leaving it for 3.1? --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 4068] SpamAssassin doesn't follow RFCs 822, 2045, and 2046
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 13:43 --- SA should just use whatever the input used. No way this should be an option. -1 to a new option. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4024] SPF and X-Envelope-From and sendmail
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 13:53 --- Subject: Re: SPF and X-Envelope-From and sendmail I would say we should use the first envelope-sender header encountered above the last trusted received line. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [Bug 4068] SpamAssassin doesn't follow RFCs 822, 2045, and 2046
So something automatic like the following pseudo-code in the input routine?
if (!$self-crlf) {
$line =~ /(\012\015|\015|\012)$/
$self-crlf = $1
}
Yeah, but I'd only use the first line of the input, or maybe the last
line in the headers, for setting the parameter.
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: [Bug 4072] SPF_PASS false match
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Quinlan writes: Do we want to fix this for 3.0.3, or just leaving it for 3.1? I'm okay with backporting, but I think we're nearing the point at which we buckle down on 3.1 and focus on it. The tree is remarkably stable right now and there are a number of significant improvements, so I'm starting to think about actually sticking to the aggressive schedule that was proposed a few months ago. :-) +1. I think we should only do a 3.0.3 if something serious (security, data loss, etc.) comes up. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB4v/QMJF5cimLx9ARAgkkAJ0SuiBX6eOw2mWHKXZw6K3FR603ugCdE+kW ekq0zXOQGaGEGuYaMZo7adk= =YWNa -END PGP SIGNATURE-
[Bug 4072] SPF_PASS false match
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 14:21 --- Subject: Re: SPF_PASS false match -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Quinlan writes: Do we want to fix this for 3.0.3, or just leaving it for 3.1? I'm okay with backporting, but I think we're nearing the point at which we buckle down on 3.1 and focus on it. The tree is remarkably stable right now and there are a number of significant improvements, so I'm starting to think about actually sticking to the aggressive schedule that was proposed a few months ago. :-) +1. I think we should only do a 3.0.3 if something serious (security, data loss, etc.) comes up. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB4v/QMJF5cimLx9ARAgkkAJ0SuiBX6eOw2mWHKXZw6K3FR603ugCdE+kW ekq0zXOQGaGEGuYaMZo7adk= =YWNa -END PGP SIGNATURE- --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 4068] SpamAssassin doesn't follow RFCs 822, 2045, and 2046
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 14:21 ---
Subject: Re: SpamAssassin doesn't follow RFCs 822, 2045, and 2046
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Quinlan writes:
So something automatic like the following pseudo-code in the input routine?
if (!$self-crlf) {
$line =~ /(\012\015|\015|\012)$/
$self-crlf = $1
}
Yeah, but I'd only use the first line of the input, or maybe the last
line in the headers, for setting the parameter.
first line makes sense to me too.
- --j.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFB4v/lMJF5cimLx9ARAoo+AJ9CbBcm1IdSaPoEHpsI+QrxEipSvwCfY85a
fHonJY2Ky6G3VELjT6LksSM=
=20k9
-END PGP SIGNATURE-
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
[Bug 4068] SpamAssassin doesn't follow RFCs 822, 2045, and 2046
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 15:05 --- Subject: Re: SpamAssassin doesn't follow RFCs 822, 2045, and 2046 The reason I jumped in on this one is because Exim has gone through a lot of problems in this area, particularly because of software that uses CRLF in a situation where you would expect LF only (e.g. sendmail -t) or which uses LF only where you would expect CRLF (e.g. various kinds of SMTP). There have also been amusing problems with ClamAV which also has to cope with line endings being CRLF or LF depending on how the message is fed to it - some months ago I had to fix one of the new upstream virus signatures because it assumed CRLF but in my environment the message had been converted to LF only. The current Exim line ending DWIM rules are documented at http://www.exim.org/exim-html-4.40/doc/html/spec_44.html#SECT44.1 It's a perpetual problem area so this might not be the best solution. Tony. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3998] Add support for Habeas v2
http://bugzilla.spamassassin.org/show_bug.cgi?id=3998 --- Additional Comments From [EMAIL PROTECTED] 2005-01-10 15:51 --- H... okay, then, I revoke my -1. It might be clearer and cleaner to have a single entry point (eval test) for all of the Habeas rules. Agreed, but I coded it the way I did for four reasons. First, I was trying to make as few changes to the base code as possible. Second, I wanted to be able to write separate rules for the old Habeas style (Haiku + HUL) and the new (return path + ACCREDIT); the easiest way to do that without breaking the existing rules was to make separate entry points. Third, we'd like to open up the return path encoding to other accreditation authorities, not just Habeas. Finally, I wanted to make it obvious where to delete the old Haiku-based code when it comes to that, again without breaking other existing rules. I commented the code pretty carefully so newcomers would (I hoped!) understand what was going on. Can you please describe the automated testing a bit? I just want to know that we're not giving out bonus points for something easily forged. With SpamAssassin 3.0, all Habeas senders are verified by DNSWL lookup. There's no opportunity for forging anything, either in the envelope or header. The difference between the different Accreditation Levels is the nature of how senders are added or remove from our whitelist, not how we authenticate them. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
