Re: SA method for identifying animated GIFs?
On Wed, 18 Oct 2006 13:17:04 -0400, you wrote: I was hoping for a simple way to detect if the image property frames 1 Will the updated SARE ruleset be able to do this? It won't need to. It just useses other flags to determine whats going on. I went about it as the gif didn't matter. Old school style ;) --Chris All GIF files contain a header with it's properties, like width, height, resolution and frame count. Image::Info has a function to retrieve these values. If I was more proficient in perl, I would write a spamassassin .pm to detect if frame count 1 ;) -Russ
SA method for identifying animated GIFs?
Hi, Has anyone come up with a SA method for identifying animated GIFs? Like some way of getting the properties of the file and checking if the frame count 1? I've looked at mime signatures, but I'm not sure if that will work and I don't have enough samples to test. thanks, -Russ
Re: SA method for identifying animated GIFs?
On Wed, 18 Oct 2006 11:50:03 -0400, you wrote: Before anyone else slams you. YES. And a 60 second search of the archives would have pulled it up. You can use FuzzyOCR, or the SARE stock ruleset will be updated soon with a less CPU intense solution. --Chris Sorry, I should have been more clear. I am using the SARE rulesets. I'm not ready to try out fuzzyocr. I was hoping for a simple way to detect if the image property frames 1 Will the updated SARE ruleset be able to do this?
gocr v.41 and segfault patch
Has gocr .41 fixed the segfault problem patched in .40 by http://antispam.imp.ch/patches/patch-gocr-segfault ? If not is there an updated patch for .41? thanks, Russ
Re: false positive in RCVD_IN_SORBS_DUL test
On Thu, 8 Dec 2005 23:16:13 -0800, you wrote: Even with TRUSTED_NETWORKS set, the RCVD_IN_SORBS_DUL rule is triggered. I don't see how this is correct, when the IP address that triggered it was not the last hop. This rule should only be triggered when sent directly from dynamic IP address If someone hasn't suggested it already, post your trusted_* config lines along with the headers for a message that you think hit wrong, and we can probably help you figure out what is going wrong. The first guess would be that you don't have trusted_networks set quite *right*, even though you have it set to *something*. Loren TRUSTED_NETWORKS 10.0.0/24 198.135.234.36 lookup from MX: #host mail.avtcorp.com mail.avtcorp.com has address 10.0.0.5 header that trip RCVD_IN_SORBS_DUL Received: from smtp109.sbc.mail.mud.yahoo.com (68.142.198.208) by mail.avtcorp.com with SMTP; 7 Dec 2005 21:03:26 - Received: (qmail 42892 invoked from network); 7 Dec 2005 21:03:25 - Received: from unknown (HELO proxyplus.universe) ([EMAIL PROTECTED]@209.30.176.199 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 7 Dec 2005 21:03:25 - Received: from cindy [156.56.61.27] by Proxy+; Wed, 07 Dec 2005 15:17:34 -0600 for [EMAIL PROTECTED] From: cindy darling [EMAIL PROTECTED] To: Judy Grecco [EMAIL PROTECTED] This does look kind of fishy. I think I see why the rule was tripped. 209.30.176.199 is listed in SORBS DUL Looks like they are running proxy+ on a PPoX pool computer and relaying through it, so I guess it makes sense to trip the rule, or does it? -Russ
Re: false positive in RCVD_IN_SORBS_DUL test
On Thu, 8 Dec 2005 03:34:44 -0800, you wrote: score ALL_TRUSTED 0 This is simply masking the problem, not setting trusted_networks correctly. And it is only masking the obvious problem - there are inobvious problems that will still score incorrectly. If you remove that line and start seeing ALL_TRUSTED hits where you don't think they should be, then you need to set trusted_networks correctly. If you remove that line and only see TRUSTED_NETWORKS hit where they should, you are better off. :-) Loren Even with TRUSTED_NETWORKS set, the RCVD_IN_SORBS_DUL rule is triggered. I don't see how this is correct, when the IP address that triggered it was not the last hop. This rule should only be triggered when sent directly from dynamic IP address
Re: false positive in RCVD_IN_SORBS_DUL test
On Thu, 08 Dec 2005 15:24:29 -0500, you wrote: On 08/12/2005 12:01 AM, Russ Ringer wrote: I have: internal_networks 10.0.0 As long as your trusted_networks are the same (or blank as internal_networks will be copied if I remember correctly), that setting is fine as long as, on the machine running SpamAssassin, mail.avtcorp.com resolves to 10.0.0.x and NOT 198.135.234.36. mail.avtcorp.com does resolve to a 10.0.0.x ip and score ALL_TRUSTED 0 What prompted you to zero the score for ALL_TRUSTED? If you are seeing external mail with this rule hitting something IS wrong. You should only see this in mail from your trusted_networks. I think I did this a long time ago when I got scores lowered from ALL_TRUSTED. Nothing is trusted, it only gets mail from outside. I took it out and will see what happens. whitelist_from_rcvd does seem to be working. A good sign, but not an entirely positive indicator of a correct trust path. Again, if ALL_TRUSTED is hitting correctly I'd say you're alright. The server receives mail static NATed from the outside I like to put both the server's internal NATed address and the external public address in the trusted_networks configuration just in case changes are made to your DNS topology and for clarity. If your setup is as my first paragraph describes though, it's not necessary (but nice). I've been using dul.dnsbl.sorbs.net with rblsmtpd to block at the front door with good results. I'm trying to move all processing inside and I'd like to get the same behavior.
Re: false positive in RCVD_IN_SORBS_DUL test
OK, thanks for the clarification. I'm not sure if I trust myself, but my mailserver now trusts itself :) -Russ
false positive in RCVD_IN_SORBS_DUL test
Why did this message trigger these rules? The email was not sent directly from a dial-up IP. RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [209.30.176.199 listed in combined.njabl.org] RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [209.30.176.199 listed in dnsbl.sorbs.net] Received: from smtp109.sbc.mail.mud.yahoo.com (68.142.198.208) by mail.avtcorp.com with SMTP; 7 Dec 2005 21:03:26 - Received: (qmail 42892 invoked from network); 7 Dec 2005 21:03:25 - Received: from unknown (HELO proxyplus.universe) ([EMAIL PROTECTED]@209.30.176.199 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 7 Dec 2005 21:03:25 - Received: from cindy [156.56.61.27] by Proxy+; Wed, 07 Dec 2005 15:17:34 -0600 for [EMAIL PROTECTED] From: cindy darling [EMAIL PROTECTED] To: Judy Grecco [EMAIL PROTECTED] Subject: RE: Request for quote using SA 3.03 Do I need to upgrade? Thanks, -Russ
Re: false positive in RCVD_IN_SORBS_DUL test
On Thu, 08 Dec 2005 03:31:21 +0100, you wrote: 2. next check if that IP delivered directly to you (= your mail server) or not. If yes, then this hit is legitimate. It's not your IP and it delivered directly to you. That's exactly the kind of IP you want to check if it is on a blacklist. I think this is the key. If it's from the first hop it should score, otherwise, not.
Re: false positive in RCVD_IN_SORBS_DUL test
Is your trusted_networks set correctly? Note: if you have a NATed mailserver you MUST set this manually, otherwise SA will mis-detect external mailservers as being a part of your network and this rule will misfire. Other common signs of incorrect trusted_networks are ALL_TRUSTED matching spam, and whitelist_from_rcvd not working. I have: internal_networks 10.0.0 and score ALL_TRUSTED 0 whitelist_from_rcvd does seem to be working. The server receives mail static NATed from the outside
whitelisting by rcpt to:
Hi, Is it possible to whitelist by rcpt to: when there is nothing in the header to indicate the recipient? i.e. no To:, bcc:, cc:, etc. -Russ
Re: whitelisting by rcpt to:
On Wed, 23 Nov 2005 09:32:38 -0800, you wrote: Russ Ringer wrote: Is it possible to whitelist by rcpt to: when there is nothing in the header to indicate the recipient? i.e. no To:, bcc:, cc:, etc. No. But you may be able to tell your MTA to put something in the header to indicate the recipient(s) (X-Apparently-To: [EMAIL PROTECTED], for example) This may break BCC, though, if you're not careful. I didn't think you could, but I had to ask. We're using qmail-scanner/spam control which gets the rcpt to in a variable so I made a simple mod to bypass SA on certain recips. We have a irrational marketing VP who is convinced he will miss a million dollar order if *anything* is blocked so I want to insure he gets all the spam he deserves (evil grin). Everyone else (including my boss) is grateful to not ever see all the crap that come in. -Russ
Re: whitelisting by rcpt to:
One thing to be wary of is if you're integrating at the MTA layer, there may be one message with multiple different recipients. If one is whitelisted but not the others, your tool will have to jump a few hoops to split the message into two copies to scan one and not the other. Yes, I warned my boss about unintended consequences for multiple different recipients.
problem with FORGED_HOTMAIL_RCVD
This triggered FORGED_HOTMAIL_RCVD. Another bug? Received: from bay0-smtp02.bay0.hotmail.com (65.54.241.109) by mail.avtcorp.com with SMTP; 31 May 2005 23:43:25 - Message-ID: [EMAIL PROTECTED] X-Originating-IP: [63.226.220.248] X-Originating-Email: [EMAIL PROTECTED] Received: from officepc ([63.226.220.248]) by BAY0-SMTP02.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 16:43:22 -0700 ---snip ---
Re: problem with FORGED_HOTMAIL_RCVD
On Wed, 01 Jun 2005 08:15:56 -0700, you wrote: This triggered FORGED_HOTMAIL_RCVD. Another bug? oops, sorry, this is from SA 3.0.3
problem with FORGED_YAHOO_RCVD rule
Why did this email from yahoo trigger FORGED_YAHOO_RCVD? Spamassassin 3.03 Received: from web31002.mail.mud.yahoo.com (68.142.200.165) by mail.avtcorp.com with SMTP; 31 May 2005 19:33:31 - Received: (qmail 41639 invoked by uid 60001); 31 May 2005 19:33:29 - Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Sa2pb3zJUtt/yxjo7ZUWK1sfoyNb87wSy/pE41/FfzEdSwPqvksdDIAL/9RHm1/lzAwsj6Hyvqq4zhDcDU5Wte/Kdl8O9Hk0irYuSGcqwqvOx+Cy0TexeS4W3xlCcVrvMBR7D5Vr8sNAo7lipWZZe9j 46611Z8hHCVOWsvnvimE= ; Message-ID: [EMAIL PROTECTED] Received: from [156.74.250.7] by web31002.mail.mud.yahoo.com via HTTP; Tue, 31 May 2005 12:33:29 PDT Date: Tue, 31 May 2005 12:33:29 -0700 (PDT)
