Re: Bad pattern in HELO_DYNAMIC_IPADDR check?
El 28/10/10 15:03, John Hardin escribió: On Thu, 28 Oct 2010, Angel L. Mateo wrote: Is there any reason for this pattern being so general? Or this is a bug? IPv4 addresses are numbers (uint4 to be precise), dotted quad notation is just the most-human-readable way to represent them. It is valid to represent an IPv4 address as a 32-bit hex value. I know this, but is '72d07e260c444a7' an IP address? Not for me, but for HELO_DYNAMIC_IPADDR it is. -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica_(___V Tfo: 868887590 Fax: 86337
Re: Sought False Positives
On 21/08/10 21:51, Ned Slider wrote: I'm still seeing FP hits against these rules despite a few sought rule updates. It seems there's a few rules hitting on Facebook: # grep Facebook /var/lib/spamassassin/3.003001/sought_rules_yerp_org/20_sought.cf body __SEEK_YDK7NN / to unsubscribe\. Facebook, Inc/ body __SEEK_GYJ_MA / If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe\. http:\/\/www\.facebook\.com\/ Facebook, Inc\. P\.O\. Box 10005, Palo Alto, CA 94303 / body __SEEK_Z4K_72 / sent you a message on Facebook/ body __SEEK_A5_EMW /Find people from your Gmail address book on Facebook\!/ body __SEEK_TKDQL_ /Sign in to Facebook and start connecting/ body __SEEK_X4HOA8 /Didn\'t sign up for Facebook\? Please let us know\. If you do not wish to receive this type of email from Facebook in the future, please click here to unsubscribe\.Facebook, Inc\. P\.O\. Box 10005, Palo Alto, CA 94303/ Apologies for bumping an old thread... I caught another FP yesterday for facebook: /var/lib/spamassassin/3.003001/sought_rules_yerp_org/20_sought.cf:body __SEEK_FMJXND /\. If you do not wish to receive this type of email from Facebook in the future, please click here to unsubscribe\. Facebook, Inc\. P\.O\. Box 10005, Palo Alto, CA 94303 / But it's since been fixed (removed) in the latest update - good work on the quick fix!
Re: Bad pattern in HELO_DYNAMIC_IPADDR check?
On Thu, 28 Oct 2010, Angel L. Mateo wrote: Is there any reason for this pattern being so general? Or this is a bug? El 28/10/10 15:03, John Hardin escribió: IPv4 addresses are numbers (uint4 to be precise), dotted quad notation is just the most-human-readable way to represent them. It is valid to represent an IPv4 address as a 32-bit hex value. On 08.11.10 11:51, Angel L. Mateo wrote: I know this, but is '72d07e260c444a7' an IP address? Not for me, but for HELO_DYNAMIC_IPADDR it is. Are you sure it's the one header that matches it? Aren't there more Received: headers? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 2B|!2B, that's a question!
Re: Bad pattern in HELO_DYNAMIC_IPADDR check?
On Mon, 8 Nov 2010, Angel L. Mateo wrote: El 28/10/10 15:03, John Hardin escribió: On Thu, 28 Oct 2010, Angel L. Mateo wrote: Is there any reason for this pattern being so general? Or this is a bug? IPv4 addresses are numbers (uint4 to be precise), dotted quad notation is just the most-human-readable way to represent them. It is valid to represent an IPv4 address as a 32-bit hex value. I know this, but is '72d07e260c444a7' an IP address? Not for me, but for HELO_DYNAMIC_IPADDR it is. ...good point. A valid IPv4 would only be 8 hex digits. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- You do not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harms it would cause if improperly administered. -- Lyndon B. Johnson --- 3 days until Veterans Day
Re: Sought False Positives
- Ned Slider n...@unixmail.co.uk wrote: On 21/08/10 21:51, Ned Slider wrote: I'm still seeing FP hits against these rules despite a few sought rule updates. It seems there's a few rules hitting on Facebook: # grep Facebook /var/lib/spamassassin/3.003001/sought_rules_yerp_org/20_sought.cf body __SEEK_YDK7NN / to unsubscribe\. Facebook, Inc/ body __SEEK_GYJ_MA / If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe\. http:\/\/www\.facebook\.com\/ Facebook, Inc\. P\.O\. Box 10005, Palo Alto, CA 94303 / body __SEEK_Z4K_72 / sent you a message on Facebook/ body __SEEK_A5_EMW /Find people from your Gmail address book on Facebook\!/ body __SEEK_TKDQL_ /Sign in to Facebook and start connecting/ body __SEEK_X4HOA8 /Didn\'t sign up for Facebook\? Please let us know\. If you do not wish to receive this type of email from Facebook in the future, please click here to unsubscribe\.Facebook, Inc\. P\.O\. Box 10005, Palo Alto, CA 94303/ Apologies for bumping an old thread... I caught another FP yesterday for facebook: /var/lib/spamassassin/3.003001/sought_rules_yerp_org/20_sought.cf:body __SEEK_FMJXND /\. If you do not wish to receive this type of email from Facebook in the future, please click here to unsubscribe\. Facebook, Inc\. P\.O\. Box 10005, Palo Alto, CA 94303 / I'd guess this is caused by the spam wave that has been going on for some time now, which basically contains the same content as the Facebook mails but with spammy URIs instead. Because of the South rules nature, I'd say that this kind of FPs are likely to happen on such scenarios. But it's since been fixed (removed) in the latest update - good work on the quick fix! -- João Gouveia AnubisNetworks
Re: Sought False Positives
On 08/11/10 15:24, João Gouveia wrote: - Ned Slidern...@unixmail.co.uk wrote: __SEEK_FMJXND /\. If you do not wish to receive this type of email from Facebook in the future, please click here to unsubscribe\. Facebook, Inc\. P\.O\. Box 10005, Palo Alto, CA 94303 / I'd guess this is caused by the spam wave that has been going on for some time now, which basically contains the same content as the Facebook mails but with spammy URIs instead. Because of the South rules nature, I'd say that this kind of FPs are likely to happen on such scenarios. Fair enough - fortunately I've not seen any of those here so assumed a genuine facebook mail had maybe slipped through into the corpus by mistake. Either way, it was fixed by the time I'd spotted it.
Re: SA 3.3.1 and NetAddr::IP 4.034
On 11/2/10 8:14 PM, Mark Martinec wrote: Btw, this could be more gracefully handled: $ perl -e 'use Socket6; use Net::Patricia' Prototype mismatch: sub main::AF_INET6: none vs () at /usr/local/lib/perl5/5.12.2/Exporter.pm line 64. Mark That's someone else's bug: https://rt.cpan.org/Public/Bug/Display.html?id=32362 and represents a defect in Socket6. The work-around is to include Socket before Socket6. -Philip
Re: SA 3.3.1 and NetAddr::IP 4.034
Philip, Try the following patch. If it works for you, I'll rerelease as 1.19: my ($self, $ip, $bits, $data) = @_; - $data ||= $bits ? $ip/$bits : $ip; + $data ||= defined $bits ? $ip/$bits : $ip; my $packed = inet_pton(AF_INET6, $ip) || croak(invalid key); Hmm. What I had in mind was a: $data = $bits ? $ip/$bits : $ip if !defined $data; $ perl -e 'use Socket6; use Net::Patricia' Prototype mismatch: sub main::AF_INET6: none vs () at /usr/local/lib/perl5/5.12.2/Exporter.pm line 64. That's someone else's bug: https://rt.cpan.org/Public/Bug/Display.html?id=32362 and represents a defect in Socket6. The work-around is to include Socket before Socket6. Thanks for the reference. I can live with that. The Net::Patricia use (optional) is now in the SpamAssassin svn trunk (on its way to become 3.4), see: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6508 Thanks for pointing out its existence and for writing/maintaining it. Btw, one more suggestion: it would be nice to be able to AVOID loading the Net::CIDR::Lite module into memory (even when it is available) if one does not need add_cidr() and remove_cidr() routines. For services running in many instances (like child processes in spamd) saving any memory is beneficial. Mark
Re: Sought False Positives
Le 20/08/2010 17:12, Jan P. Kessler a écrit : Hi, we use spamassassin with the sought ruleset since several years at our company. After the upgrade to from 3.2.5 to 3.3.1 we notice tons of false-positives hitting on the rules JM_SOUGHT_1 and JM_SOUGHT_2. Unfortunaley I can not give examples as these messages contain confidental customer data (assurance company). We had more than 100 false-positives with these rules in the last 2 days. I have drastically lowered the score from 4.0 to 1.0 for both rules and wanted to ask if anybody else noticed that? Cheers, Jan below is an FP which is a public mail. I'm going to zero the corresponding rules (I prefer false negatives, which help improving local rule, over false positives, exceptionally when I can't explain why). = FP sample Return-Path: websecurity-return-7218-mouss=ml.netoyen@webappsec.org Delivered-To: mouss+s...@ml.netoyen.net Received: from imlil.netoyen.net (localhost [127.0.0.1]) by imlil.netoyen.net (Postfix) with ESMTP id A2E97E54898 for mouss+s...@ml.netoyen.net; Mon, 8 Nov 2010 18:42:45 +0100 (CET) X-Relay-Countries: US X-Virus-Scanned: amavisd-new at netoyen.net X-Spam-Flag: YES X-Spam-Score: 5.284 X-Spam-Level: * X-Spam-Status: Yes, score=5.284 required=5 tests=[COUNTRY_US=0.01, JM_SOUGHT_3=4, RDNS_NONE=1.274] autolearn=no Received: from cgisecurity.net (unknown [199.125.85.46]) by mx.netoyen.net (Postfix) with SMTP id A8EA4E54829 for mo...@ml.netoyen.net; Mon, 8 Nov 2010 18:42:43 +0100 (CET) Received: (qmail 18910 invoked by uid 1017); 8 Nov 2010 18:36:41 - Mailing-List: contact websecurity-h...@webappsec.org; run by ezmlm Precedence: bulk List-Post: mailto:websecur...@webappsec.org List-Help: mailto:websecurity-h...@webappsec.org List-Unsubscribe: mailto:websecurity-unsubscr...@webappsec.org List-Subscribe: mailto:websecurity-subscr...@webappsec.org Delivered-To: mailing list websecur...@webappsec.org Delivered-To: moderator for websecur...@webappsec.org Received: (qmail 37779 invoked from network); 7 Nov 2010 18:51:51 - MIME-Version: 1.0 In-Reply-To: 005301cb7ad5$b2875f30$c103f...@ml References: 002301cb7944$a7619b80$c103f...@ml aanlktimabfxcsrqdul=qvawxoqursqnt7nzefj2p7...@mail.gmail.com 005301cb7ad5$b2875f30$c103f...@ml From: YGN Ethical Hacker Group li...@yehg.net Date: Mon, 8 Nov 2010 01:57:16 +0800 Message-ID: aanlktimtbamufvwexpwqbcdl4bb55ai31hxwpcd6r...@mail.gmail.com To: MustLive mustl...@websecurity.com.ua Cc: websecur...@webappsec.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [WEB SECURITY] [New Tool Announcement] inspath - Path Disclosure Finder Hi MustLive Thanks for your suggestion. Searching for Google Cache might be a good feature to add in inpathx but I'm afraid this realm should/can be done with other tools like SiteDigger (http://www.foundstone.com/us/resources/proddesc/sitedigger.htm). - Best regards, YGN Ethical Hacker Group Yangon, Myanmar http://yehg.net Our Lab | http://yehg.net/lab Our Directory | http://yehg.net/hwd Join us on IRC: irc.freenode.net #webappsec Have a question? Search The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/archive/ Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed] To unsubscribe email websecurity-unsubscr...@webappsec.org and reply to the confirmation email Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA WASC on Twitter http://twitter.com/wascupdates
Re: Sought False Positives
On 08/11/2010 12:06 PM, Ned Slider wrote: Fair enough - fortunately I've not seen any of those here so assumed a genuine facebook mail had maybe slipped through into the corpus by mistake. Either way, it was fixed by the time I'd spotted it. I've seen it as well, and disabled the Sought rules. They were causing too many FPs and not hitting enough spam to be worthwhile.
Re: SA 3.3.1 and NetAddr::IP 4.034
Philip, Thanks for your off-list reply. Unfortunately I cannot reply, as your mailer is refusing connections: $ host -t mx redfish-solutions.com redfish-solutions.com mail is handled by 10 mail.redfish-solutions.com. $ telnet -s mail4.ijs.si mail.redfish-solutions.com 25 Trying 66.232.79.143... Connected to mail.redfish-solutions.com. 554 mail.redfish-solutions.com ESMTP not accepting messages (the message is now sitting in our queue, retrying periodically) Mark
Re: SA 3.3.1 and NetAddr::IP 4.034
On 11/8/10 5:58 PM, Mark Martinec wrote: Philip, Thanks for your off-list reply. Unfortunately I cannot reply, as your mailer is refusing connections: $ host -t mx redfish-solutions.com redfish-solutions.com mail is handled by 10 mail.redfish-solutions.com. $ telnet -s mail4.ijs.si mail.redfish-solutions.com 25 Trying 66.232.79.143... Connected to mail.redfish-solutions.com. 554 mail.redfish-solutions.com ESMTP not accepting messages (the message is now sitting in our queue, retrying periodically) Mark Oh, sorry. Fixed.
