Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Yes, I have checked on the real Zen lists and the real IP is there. Then your checking software is broken. None of the Spamhaus lists ever include anything in 10/8. John, the big hint was in the word *REAL IP*... as I said hundreds of times subsequently to the initial post, I stupidly forgot to mention in my original post that I obfuscated the first to octets of the IP into RFC1918 range. Yes, my bad, yes I should have said but I did tell everyone multiple times subsequently, I think you must have skipped over my subsequent posts. Anyway, back to the topic, I rolled out some new configs yesterday evening based on some of the suggestions received here, so will see how things pan out today.
Re: Problems with BCCing from spammers
On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote: I take it by the: a) lack of usable responses b) responses NOT claiming this ISN'T a bug it is *not* a bug. It's not SA's task to split a msg to multiple rcpts. Your glue (hack) or MTA (best) should do this.
Re: Problems with BCCing from spammers
On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote: Suggestions? http://www.snertsoft.com/sendmail/milter-spamc/ Spam:recipient-address value * (FRIEND or HATER are recognised) Spam:recipient-domain value * (FRIEND or HATER are recognised) Spam:recipient@ value * (FRIEND or HATER are recognised)
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Oh, OK. In the future, if you're not prepared to show the actual problem with their actual data, please don't waste our time. R's from a thing with no keyboard, John Nigel Smith gb10hkzo-...@yahoo.co.uk wrote: Yes, I have checked on the real Zen lists and the real IP is there. Then your checking software is broken. None of the Spamhaus lists ever include anything in 10/8. John, the big hint was in the word *REAL IP*... as I said hundreds of times subsequently to the initial post, I stupidly forgot to mention in my original post that I obfuscated the first to octets of the IP into RFC1918 range. Yes, my bad, yes I should have said but I did tell everyone multiple times subsequently, I think you must have skipped over my subsequent posts. Anyway, back to the topic, I rolled out some new configs yesterday evening based on some of the suggestions received here, so will see how things pan out today.
Re: Problems with BCCing from spammers
On 14.08.13 15:20, Ted Mittelstaedt wrote: I am using spamass-milter to process received mail. do you use -u user option? spamas-milter uses that user's config when the mail goes to multiple recipients. Isn't that user by any chance the one in all_spam_to list? I guess if you don't specify the -u option, user nobody is used. If the option was supposed to process BCC also why wasn't it called all_spam_to_both_to_and_bcc? I strongly doubt that any spam software does use Bcc: Bcc: is for MTAs that need to specify envelope users that do not go to the 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. They say when you play that M$ CD backward you can hear satanic messages. That's nothing. If you play it forward it will install Windows.
Re: Problems with BCCing from spammers
On 8/15/2013 12:29 AM, Axb wrote: On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote: Suggestions? http://www.snertsoft.com/sendmail/milter-spamc/ Spam:recipient-address value * (FRIEND or HATER are recognised) Spam:recipient-domain value * (FRIEND or HATER are recognised) Spam:recipient@ value * (FRIEND or HATER are recognised) The problem with that one is that it has no understanding of authenticated SMTP Only 1 of my mailservers has the sender and recipients split, I have several other mailservers that receive mail for users and act as outbound relays as well. The users are using suth-smtp from all over the place not from a defined set of subnets, and I have to make sure that SA is not run on email that comes from a user to be relayed out. The authenticated SMTP patch for spamass-milter might be able to be modified for this one but I'm not a good enough C programmer to do it. Ted
Re: Problems with BCCing from spammers
On 8/15/2013 12:14 AM, Axb wrote: On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote: I take it by the: a) lack of usable responses b) responses NOT claiming this ISN'T a bug it is *not* a bug. It's not SA's task to split a msg to multiple rcpts. Your glue (hack) or MTA (best) should do this. It IS a bug since the software is not acting according to how it's documented or expected. That is the definition of a software bug. You can argue that it's a documentation bug and I might agree but it's still a bug An option stating all_spam_to followed by the email address of the RECIPIENT is basically stating that ONLY mail sent TO the recipient will be exempted. It would be better to have the option all_spam_to_envelope_recipient with the explanation that the recipient is who is being passed on the envelope To: not the To: in the header, or something like that, but the option as it stands implies the To: in the header, and that implication should be disabused in the documentation for the config file, at the very least. Ted
Re: Problems with BCCing from spammers
On 8/15/2013 9:38 AM, Matus UHLAR - fantomas wrote: On 14.08.13 15:20, Ted Mittelstaedt wrote: I am using spamass-milter to process received mail. do you use -u user option? spamas-milter uses that user's config when the mail goes to multiple recipients. Isn't that user by any chance the one in all_spam_to list? None of the users have individual configs, this is a mailserver that does not store configuration data on a per-user basis, thus that option does not apply. I guess if you don't specify the -u option, user nobody is used. actually it's user root. It's a potato/potahto argument as to whether to modify local.cf or a config in the root user, the end result is a single global config. If the option was supposed to process BCC also why wasn't it called all_spam_to_both_to_and_bcc? I strongly doubt that any spam software does use Bcc: Bcc: is for MTAs that need to specify envelope users that do not go to the headers. spamass-milter isn't a spam software it is a milter that calls spam software. As David and John already discussed the way this appears to be happening is that spamass-milter is parsing the users in the BCC: header (which as you stated, shouldn't exist in an incoming email - but it does - since that email is a piece of spam generated by some spammers program) and passing those to spamassassin, which is seeing that one of those users is listed in the all_spam_to configuration, and assigning a -100 score, which is then essentially invalidating spamassassin's scoring. Or, something like that - if I'm understanding the discussion properly. Ted
Re: Problems with BCCing from spammers
On 8/15/13 11:53 AM, Ted Mittelstaedt t...@ipinc.net wrote: On 8/15/2013 12:14 AM, Axb wrote: On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote: I take it by the: a) lack of usable responses b) responses NOT claiming this ISN'T a bug it is *not* a bug. It's not SA's task to split a msg to multiple rcpts. Your glue (hack) or MTA (best) should do this. It IS a bug since the software is not acting according to how it's documented or expected. That is the definition of a software bug. You can argue that it's a documentation bug and I might agree but it's still a bug The wiki is reasonably clear that various headers are searched: http://wiki.apache.org/spamassassin/AllSpamToFiltering -- Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: Problems with BCCing from spammers
On Thu, 15 Aug 2013, Ted Mittelstaedt wrote: On 8/15/2013 12:14 AM, Axb wrote: On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote: I take it by the: a) lack of usable responses b) responses NOT claiming this ISN'T a bug it is *not* a bug. It's not SA's task to split a msg to multiple rcpts. Your glue (hack) or MTA (best) should do this. It IS a bug since the software is not acting according to how it's documented or expected. That is the definition of a software bug. SA only has the message headers to work with; *something else* has to put the complete envelope recipient list into the headers for SA to be able to see the BCC recipients. If the glue is putting BCC recipients into a header that SA is documented as checking for whitelisting, then it's *not SAs fault* that whitelisting a BCC recipient affects an exposed recipient. -- 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 --- Windows and its users got mentioned at home today, after my wife the psych major brought up Seligman's theory of learned helplessness. -- Dan Birchall in a.s.r --- Today: the 68th anniversary of the end of World War II
Re: SPF failure very low score
--On Monday, August 12, 2013 2:02 PM -0700 John Hardin jhar...@impsec.org wrote: On Mon, 12 Aug 2013, Bowie Bailey wrote: On 8/12/2013 2:48 PM, John Hardin wrote: On Mon, 12 Aug 2013, Quanah Gibson-Mount wrote: --On Friday, August 09, 2013 12:42 AM +0200 Benny Pedersen wrote: body __BODY_FACEBOOK /Facebook/ meta __FORGED_SENDER (!SPF_PASS !DKIM_VALID_AU) meta FORGED_FACEBOOK_BODY (__BODY_FACEBOOK __FORGED_SENDER) maybe it could be more specific, just not tested it, but why accept forged ? Thanks, that is helpful. So I assume then I would do something like: score FORGED_FACEBOOK_BODY 3.0 to give it a high SPAM score. ...so you want to punish any email that discusses Facebook and does not pass SPF *AND* DKIM? Regardless of where the message is (or claims to be) from? Actually, __FORGED_SENDER only fires if the message fails *both* SPF and DKIM. (not A) and (not B) == not (A or B) D'oh! But this is still a check for message *discussing* Facebook and not messages specifically *from* Facebook. Yeah, I'm not complaining about people discussing facebook, but pretending to be facebook. Example: Return-Path: no-re...@facebook.com Received: from edge02-zcs.vmware.com (LHLO edge02-zcs.vmware.com) (10.113.208.52) by mbs01-zcs.vmware.com with LMTP; Thu, 15 Aug 2013 11:11:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge02-zcs.vmware.com (Postfix) with ESMTP id 904D1992; Thu, 15 Aug 2013 11:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge02-zcs.vmware.com X-Spam-Flag: NO X-Spam-Score: 2.814 X-Spam-Level: ** X-Spam-Status: No, score=2.814 tagged_above=-10 required=3 tests=[BAYES_80=2, DKIM_ADSP_ALL=0.8, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_BIG_TO_CC=0.001, SPF_FAIL=0.001, T_HEADER_FROM_DIFFERENT_DOMAINS=0.01] autolearn=no Received: from edge02-zcs.vmware.com ([127.0.0.1]) by localhost (edge02-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezz1yu95KGdl; Thu, 15 Aug 2013 11:11:36 -0700 (PDT) Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use 'no-re...@facebook.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=edge02-zcs.vmware.com; identity=mailfrom; envelope-from=no-re...@facebook.com; helo=mail.oandpa.com; client-ip=68.169.160.233 Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use 'no-re...@facebook.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=edge02-zcs.vmware.com; identity=mailfrom; envelope-from=no-re...@facebook.com; helo=mail.oandpa.com; client-ip=68.169.160.233 Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use 'no-re...@facebook.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=edge02-zcs.vmware.com; identity=mailfrom; envelope-from=no-re...@facebook.com; helo=mail.oandpa.com; client-ip=68.169.160.233 Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use 'no-re...@facebook.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=edge02-zcs.vmware.com; identity=mailfrom; envelope-from=no-re...@facebook.com; helo=mail.oandpa.com; client-ip=68.169.160.233 Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use 'no-re...@facebook.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=edge02-zcs.vmware.com; identity=mailfrom; envelope-from=no-re...@facebook.com; helo=mail.oandpa.com; client-ip=68.169.160.233 Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use 'no-re...@facebook.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=edge02-zcs.vmware.com; identity=mailfrom; envelope-from=no-re...@facebook.com; helo=mail.oandpa.com; client-ip=68.169.160.233 Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use 'no-re...@facebook.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=edge02-zcs.vmware.com; identity=mailfrom; envelope-from=no-re...@facebook.com; helo=mail.oandpa.com; client-ip=68.169.160.233 Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use 'no-re...@facebook.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=edge02-zcs.vmware.com; identity=mailfrom; envelope-from=no-re...@facebook.com; helo=mail.oandpa.com; client-ip=68.169.160.233 Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use 'no-re...@facebook.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=edge02-zcs.vmware.com; identity=mailfrom; envelope-from=no-re...@facebook.com; helo=mail.oandpa.com; client-ip=68.169.160.233 Received-SPF: fail (facebook.com ... _spf.facebook.com: Sender is not authorized by default to use
RP_MATCHES_RCVD letting in SPAM
Some of our users are getting a ton of SPAM from .br domains. If it weren't for RP_MATCHES_RCVD they would actually end up in their junk folder rather than their Inbox. Is there a general suggested adjustment I can make catch these without tweaking RP_MATCHES_RCVD? Return-Path: s...@uptop.com.br Received: from edge01-zcs.vmware.com (LHLO edge01-zcs.vmware.com) (10.113.208.51) by mbs03-zcs.vmware.com with LMTP; Thu, 15 Aug 2013 11:27:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge01-zcs.vmware.com (Postfix) with ESMTP id A8C1A1931; Thu, 15 Aug 2013 11:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge01-zcs.vmware.com X-Spam-Flag: NO X-Spam-Score: 2.069 X-Spam-Level: ** X-Spam-Status: No, score=2.069 tagged_above=-10 required=3 tests=[BAYES_99=3.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-1.344, T_KHOP_FOREIGN_CLICK=0.01] autolearn=no Authentication-Results: edge01-zcs.vmware.com (amavisd-new); dkim=pass (1024-bit key) header.d=uptop.com.br Received: from edge01-zcs.vmware.com ([127.0.0.1]) by localhost (edge01-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjdqouuXTjs0; Thu, 15 Aug 2013 11:27:15 -0700 (PDT) Received: from vmta31.uptop.com.br (vmta31.uptop.com.br [5.135.117.31]) by edge01-zcs.vmware.com (Postfix) with ESMTP id 5502699B for xx...@zimbra.com; Thu, 15 Aug 2013 11:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=upkey; d=uptop.com.br; h=To:Subject:Message-ID:Date:From:Reply-To:MIME-Version:List-Unsubscribe:Con tent-Type:Content-Transfer-Encoding; i=a...@uptop.com.br; bh=T9iP2DjK/6AQ4Vs6z6J5Ns129Jg=; b=FmrfkS17Bdb5zaJItp0+1hdmmlIoC8TXdgt/Z1/8/dPdT5K5yBka+jdLfLWKiJhR18koFcHgBl f2 5p9CbRL25dr012hmqmgH5O/auyGb2HGHNxmAv5GgthtRuCTynO2oyUJ1Ykz/fQ6wnvsReynaz8oi pj4Oy7qviqGVdBzZZ4c= To: x...@zimbra.com Subject: =?UTF-8?B?QW5pdmVyc8OhcmlvIExhIEN1aXNpbmU6IDEwJSsxMCUgZGUgRGVzY29udG8gcGFyYSBWb2PDqiA=?= Message-ID: 32c1d84426a44ac5e446b2a57d539...@www.uptop.com.br Date: Thu, 15 Aug 2013 15:08:05 -0300 From: =?UTF-8?B?U2hvcHRpbWUuY29tLmJyIC0gTcOtZGlhTWFpbA==?= m...@uptop.com.br Reply-To: m...@uptop.com.br MIME-Version: 1.0 X-Mailer-LID: 3 List-Unsubscribe: http://www.uptop.com.br/unsubscribe.php?M=1938765C=b8da7e6dcf057fc02a0cb072c0312e6fL=3N=379 X-Mailer-RecptId: 1938765 X-Mailer-SID: 379 X-Mailer-Sent-By: 1 Content-Type: multipart/alternative; charset=UTF-8; boundary=b1_bb546d207080f5562bf4cdc2c79bfd11 Content-Transfer-Encoding: 8bit -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: SPF failure very low score
On 8/15/2013 2:53 PM, Quanah Gibson-Mount wrote: Yeah, I'm not complaining about people discussing facebook, but pretending to be facebook. Example: Return-Path: no-re...@facebook.com Received: from edge02-zcs.vmware.com (LHLO edge02-zcs.vmware.com) (10.113.208.52) by mbs01-zcs.vmware.com with LMTP; Thu, 15 Aug 2013 11:11:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge02-zcs.vmware.com (Postfix) with ESMTP id 904D1992; Thu, 15 Aug 2013 11:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge02-zcs.vmware.com X-Spam-Flag: NO X-Spam-Score: 2.814 X-Spam-Level: ** X-Spam-Status: No, score=2.814 tagged_above=-10 required=3 tests=[BAYES_80=2, DKIM_ADSP_ALL=0.8, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_BIG_TO_CC=0.001, SPF_FAIL=0.001, T_HEADER_FROM_DIFFERENT_DOMAINS=0.01] autolearn=no Received: from edge02-zcs.vmware.com ([127.0.0.1]) by localhost (edge02-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezz1yu95KGdl; Thu, 15 Aug 2013 11:11:36 -0700 (PDT) snip Message-ID: 520d16e7.407...@facebook.com Date: Thu, 15 Aug 2013 13:11:34 -0500 From: Facebook notification+zrdohvri=v...@facebookmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101103 Thunderbird/3.1.6 MIME-Version: 1.0 So what I need is something like: header __FROM_FACEBOOK Return-Path:addr =~ /no-reply\@facebook.com/ meta __FORGED_SENDER (!SPF_PASS !DKIM_VALID_AU) meta FORGED_FACEBOOK_FROM (__FROM_FACEBOOK __FORGED_SENDER) score FORGED_FACEBOOK 1.5 Does that look correct? Looks good to me. The only thing I see is that you need to escape the period in the regex. header __FROM_FACEBOOK Return-Path:addr =~ /no-reply\@facebook\.com/ Otherwise, the period means any character, which would probably not be an issue here, but is not what you were intending. -- Bowie
Re: SPF failure very low score
Quanah Gibson-Mount skrev den 2013-08-15 20:53: header __FROM_FACEBOOK Return-Path:addr =~ /no-reply\@facebook.com/ meta __FORGED_SENDER (!SPF_PASS !DKIM_VALID_AU) meta FORGED_FACEBOOK_FROM (__FROM_FACEBOOK __FORGED_SENDER) score FORGED_FACEBOOK 1.5 Does that look correct? yes, add and test
Re: SPF failure very low score
--On Thursday, August 15, 2013 3:06 PM -0400 Bowie Bailey bowie_bai...@buc.com wrote: On 8/15/2013 2:53 PM, Quanah Gibson-Mount wrote: Yeah, I'm not complaining about people discussing facebook, but pretending to be facebook. Example: Return-Path: no-re...@facebook.com Received: from edge02-zcs.vmware.com (LHLO edge02-zcs.vmware.com) (10.113.208.52) by mbs01-zcs.vmware.com with LMTP; Thu, 15 Aug 2013 11:11:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge02-zcs.vmware.com (Postfix) with ESMTP id 904D1992; Thu, 15 Aug 2013 11:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge02-zcs.vmware.com X-Spam-Flag: NO X-Spam-Score: 2.814 X-Spam-Level: ** X-Spam-Status: No, score=2.814 tagged_above=-10 required=3 tests=[BAYES_80=2, DKIM_ADSP_ALL=0.8, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_BIG_TO_CC=0.001, SPF_FAIL=0.001, T_HEADER_FROM_DIFFERENT_DOMAINS=0.01] autolearn=no Received: from edge02-zcs.vmware.com ([127.0.0.1]) by localhost (edge02-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezz1yu95KGdl; Thu, 15 Aug 2013 11:11:36 -0700 (PDT) snip Message-ID: 520d16e7.407...@facebook.com Date: Thu, 15 Aug 2013 13:11:34 -0500 From: Facebook notification+zrdohvri=v...@facebookmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101103 Thunderbird/3.1.6 MIME-Version: 1.0 So what I need is something like: header __FROM_FACEBOOK Return-Path:addr =~ /no-reply\@facebook.com/ meta __FORGED_SENDER (!SPF_PASS !DKIM_VALID_AU) meta FORGED_FACEBOOK_FROM (__FROM_FACEBOOK __FORGED_SENDER) score FORGED_FACEBOOK 1.5 Does that look correct? Looks good to me. The only thing I see is that you need to escape the period in the regex. header __FROM_FACEBOOK Return-Path:addr =~ /no-reply\@facebook\.com/ Otherwise, the period means any character, which would probably not be an issue here, but is not what you were intending. Yeah, I noticed that after I sent it, thanks. :) --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: RP_MATCHES_RCVD letting in SPAM
Quanah Gibson-Mount skrev den 2013-08-15 21:05: Some of our users are getting a ton of SPAM from .br domains. If it weren't for RP_MATCHES_RCVD they would actually end up in their junk folder rather than their Inbox. Is there a general suggested adjustment I can make catch these without tweaking RP_MATCHES_RCVD? meta LOTS_OF_MONEY (3) (3) (3) (3) meta RP_MATCHES_RCVD (1) (1) (1) (1)
Re: RP_MATCHES_RCVD letting in SPAM
--On Thursday, August 15, 2013 9:16 PM +0200 Benny Pedersen wrote: Quanah Gibson-Mount skrev den 2013-08-15 21:05: Some of our users are getting a ton of SPAM from .br domains. If it weren't for RP_MATCHES_RCVD they would actually end up in their junk folder rather than their Inbox. Is there a general suggested adjustment I can make catch these without tweaking RP_MATCHES_RCVD? meta LOTS_OF_MONEY (3) (3) (3) (3) meta RP_MATCHES_RCVD (1) (1) (1) (1) Perfect, thanks! --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: RP_MATCHES_RCVD letting in SPAM
--On Thursday, August 15, 2013 12:21 PM -0700 Quanah Gibson-Mount qua...@zimbra.com wrote: --On Thursday, August 15, 2013 9:16 PM +0200 Benny Pedersen wrote: Quanah Gibson-Mount skrev den 2013-08-15 21:05: Some of our users are getting a ton of SPAM from .br domains. If it weren't for RP_MATCHES_RCVD they would actually end up in their junk folder rather than their Inbox. Is there a general suggested adjustment I can make catch these without tweaking RP_MATCHES_RCVD? meta LOTS_OF_MONEY (3) (3) (3) (3) meta RP_MATCHES_RCVD (1) (1) (1) (1) Perfect, thanks! Hm, that won't catch our other BR spam though. :( Return-Path: reto...@registraclique.com.br Received: from edge01-zcs.vmware.com (LHLO edge01-zcs.vmware.com) (10.113.208.51) by mbs03-zcs.vmware.com with LMTP; Thu, 15 Aug 2013 11:15:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge01-zcs.vmware.com (Postfix) with ESMTP id CB83A1968; Thu, 15 Aug 2013 11:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge01-zcs.vmware.com X-Spam-Flag: NO X-Spam-Score: 2.833 X-Spam-Level: ** X-Spam-Status: No, score=2.833 tagged_above=-10 required=3 tests=[BAYES_99=3.5, DKIM_SIGNED=0.1, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.344, T_DKIM_INVALID=0.01, T_KHOP_FOREIGN_CLICK=0.01] autolearn=no Authentication-Results: edge01-zcs.vmware.com (amavisd-new); dkim=neutral reason=invalid (public key: not available) header.d=registraclique.com.br Received: from edge01-zcs.vmware.com ([127.0.0.1]) by localhost (edge01-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qup1pMAcaDgg; Thu, 15 Aug 2013 11:15:53 -0700 (PDT) Received: from registraclique.com.br (s175.registraclique.com.br [141.105.64.175]) by edge01-zcs.vmware.com (Postfix) with ESMTPS id 90F8A1940 for xx...@zimbra.com; Thu, 15 Aug 2013 11:15:52 -0700 (PDT) Received: by registraclique.com.br (Postfix, from userid 0) id 2BAEB8860B8; Thu, 15 Aug 2013 10:22:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=registraclique.com.br; s=default; t=1376590475; bh=nUoQ44WhTVHL4zF0mcmuHnMTLjLNO1sgscswqFRg/0g=; h=To:Subject:Date:From:Reply-To:List-Unsubscribe; b=ovlYK4eRDyhcbVMwLbd+TqVjdXO2pwQyko4Kc0FKjdan2k8tz9uO6y2633kIBG+fb NJLigYccPUTrD/2B6MYTgWzXulw8pQtVbXSKnuzXAq0pZmwx5a+jXiVJOWH8gsW1e7 FW+Qaxu0aIrmfOkPLOzGHALhLkg8JIxWLiAbe/lE= To: xx...@zimbra.com Subject: Fale Ilimitado Com Todo O Brasil Por R$19,90! Message-ID: 350297cb0672e79fdb9aa53472cca...@www.registraclique.com.br Date: Thu, 15 Aug 2013 09:16:29 -0400 From: =?UTF-8?B?Q2xhcm8gRmFsZSDDoCBWb250YWRl?= cont...@registraclique.com.br Reply-To: cont...@registraclique.com.br MIME-Version: 1.0 X-Mailer-LID: 11 List-Unsubscribe: http://www.registraclique.com.br/iem/unsubscribe.php?M=1531174C=77d064e695a19edb4155caf4c244402aL=11N=72 X-Mailer-RecptId: 1531174 X-Mailer-SID: 72 X-Mailer-Sent-By: 1 Content-Type: multipart/alternative; charset=UTF-8; boundary=b1_bb3d14c03992adb6a28e84dfa3fb4b7d Content-Transfer-Encoding: 8bit --b1_bb3d14c03992adb6a28e84dfa3fb4b7d Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8bit -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: SPF failure very low score
On Thu, 15 Aug 2013, Quanah Gibson-Mount wrote: header __FROM_FACEBOOK Return-Path:addr =~ /no-reply\@facebook\.com/ Any reason you're limiting it to just the no-reply address? You might also want to broaden the domain a bit. How about: header __FROM_FACEBOOK Return-Path:addr =~ /\@facebook(?:mail)?\.com$/ -- 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 --- Maxim IX: Never turn your back on an enemy. --- Today: the 68th anniversary of the end of World War II
Re: RP_MATCHES_RCVD letting in SPAM
On Thu, 15 Aug 2013, Benny Pedersen wrote: meta LOTS_OF_MONEY (3) (3) (3) (3) I *do not recommend* doing that. There is a lot of legitimate email that mentions large monetary amounts (e.g. a newsletter discussing the US budget deficit). That rule's score is informational on purpose, so that the description will appear in the rule hits without affecting the score noticeably. It's intended to be used in metas with other rules that make a mention of a large amount of money suspicious. -- 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 --- Maxim IX: Never turn your back on an enemy. --- Today: the 68th anniversary of the end of World War II
Re: SPF failure very low score
--On Thursday, August 15, 2013 12:36 PM -0700 John Hardin wrote: On Thu, 15 Aug 2013, Quanah Gibson-Mount wrote: header __FROM_FACEBOOK Return-Path:addr =~ /no-reply\@facebook\.com/ Any reason you're limiting it to just the no-reply address? You might also want to broaden the domain a bit. How about: header __FROM_FACEBOOK Return-Path:addr =~ /\@facebook(?:mail)?\.com$/ well, so far, all 200 or so of these I've seen all use the same Return-Path. The From: varies, but Return-Path doesn't. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: RP_MATCHES_RCVD letting in SPAM
John Hardin skrev den 2013-08-15 21:41: the score noticeably. It's intended to be used in metas with other rules that make a mention of a large amount of money suspicious. also why i used soft blacklists, i have not seen the real problem yet, but imho anyone can soft score adjust if needed, or even make more specific rules to detect spams localy, i loosed to check if the mails was really from a maillist with opt-out problematic, only the recipient can tell
Re: RP_MATCHES_RCVD letting in SPAM
Quanah Gibson-Mount skrev den 2013-08-15 21:25: Hm, that won't catch our other BR spam though. :( List-Unsubscribe: http://www.registraclique.com.br/iem/unsubscribe.php?M=1531174C=77d064e695a19edb4155caf4c244402aL=11N=72 unsubscribe ? if recipient was not opt-in then block sender domain with mta rule, dont accept opt-out !
Re: SPF failure very low score
John Hardin skrev den 2013-08-15 21:36: header __FROM_FACEBOOK Return-Path:addr =~ /\@facebook(?:mail)?\.com$/ https://dmarcian.com/dmarc-inspector/facebookmail.com https://dmarcian.com/spf-survey/facebookapp.com
Re: SPF failure very low score
Quanah Gibson-Mount skrev den 2013-08-15 21:43: well, so far, all 200 or so of these I've seen all use the same Return-Path. The From: varies, but Return-Path doesn't. then dont test other facebook domains, there is alot of other facebook real domains that is owned by same payers, make rules simple so it is to learn from also on errors :) teories and pratics is not always the same solution or problems
Re: Whitelisting subdomains?
On Wed, 2013-08-14 at 14:53 -0400, Andrew Talbot wrote:
I’m trying to whitelist all our internal subdomains but I can’t seem
to get it to work.
We have so many of them that it’s impractical to do them individually.
I was thinking that whitelist_from *.domain.com would work but it
doesn’t
According to the docs [1], it does. That's precisely one of the
examples. If it does not work for you, you'll have to show some samples
by providing raw headers.
I strongly suggest to use the much safer variants with additional
constraints: whitelist_from_rcvd and whitelist_auth.
I can’t seem to find any documentation on the net anywhere – is it
even possible to do this?
M:SA:Conf docs [1], section Whitelist and Blacklist Options.
[1] http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Conf.html
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: RP_MATCHES_RCVD letting in SPAM
On 15.08.13 12:05, Quanah Gibson-Mount wrote: Some of our users are getting a ton of SPAM from .br domains. If it weren't for RP_MATCHES_RCVD they would actually end up in their junk folder rather than their Inbox. Is there a general suggested adjustment I can make catch these without tweaking RP_MATCHES_RCVD? I have score RP_MATCHES_RCVD 0 in /etc/mail/local.cf there is __RP_MATCHES_RCVD that has to be used in metas. I don't see any poing in giving positive score to mail just because it's not any kind of forged... -- 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. Fighting for peace is like fucking for virginity...
Re: RP_MATCHES_RCVD letting in SPAM
Matus UHLAR - fantomas skrev den 2013-08-15 22:33: score RP_MATCHES_RCVD 0 hard scoreing there is __RP_MATCHES_RCVD that has to be used in metas. I don't see any poing in giving positive score to mail just because it's not any kind of forged... __foo have no scores, no point in setting it, well if rules gives negative scores for spam it would make sense to add (softblacklist) that rule until its detected as spam, or create another rule so it works specific to the spam with hard scoreing one loose corpus scoreing from apache.org :)
Re: RP_MATCHES_RCVD letting in SPAM
Matus UHLAR - fantomas skrev den 2013-08-15 22:33: score RP_MATCHES_RCVD 0 hard scoreing there is __RP_MATCHES_RCVD that has to be used in metas. I don't see any poing in giving positive score to mail just because it's not any kind of forged... On 15.08.13 22:41, Benny Pedersen wrote: __foo have no scores, no point in setting it, well if rules gives negative scores for spam it would make sense to add (softblacklist) that rule until its detected as spam, or create another rule so it works specific to the spam with hard scoreing one loose corpus scoreing from apache.org :) I have said it already: There's no point in decreasing score just because the sender domain is the same as the mail server. That's why I set RP_MATCHES_RCVD to 0 so it will not hit. If anyone wants to use this in meta rules, we have __RP_MATCHES_RCVD (with default score of 0) for such usage. Since RP_MATCHES_RCVD has score of 0, it won' hit any metas since it's disabled by setting the score to 0. -- 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. Save the whales. Collect the whole set.
Re: RP_MATCHES_RCVD letting in SPAM
--On Thursday, August 15, 2013 10:07 PM +0200 Benny Pedersen wrote: Quanah Gibson-Mount skrev den 2013-08-15 21:25: Hm, that won't catch our other BR spam though. :( List-Unsubscribe: http://www.registraclique.com.br/iem/unsubscribe.php?M=1531174C=77d064 e695a19edb4155caf4c244402aL=11N=72 unsubscribe ? if recipient was not opt-in then block sender domain with mta rule, dont accept opt-out ! Thanks Benny, I will just blacklist them. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: Problems with BCCing from spammers
On Wed, 2013-08-14 at 15:20 -0700, Ted Mittelstaedt wrote:
I take it by the:
a) lack of usable responses
b) responses NOT claiming this ISN'T a bug
c) responses tacitly acknowledging this is an Oh crap they forgot about
BCCs when they wrote it but I don't have the balls to publicly call them
out on it like he did
that I am dealing with a bona-fide Spamassassing design fuck-up, and in
summary if I'm going to continue to use spamass-milter that the option
all_spam_to is off the table.
Just 4 hours in and you're going off like that?
What do you expect by a volunteer driven Open Source project? 24/7
support with a guaranteed reaction time of less than an hour?
That's all I needed to know. If I'm wrong, and it's me that is doing
something wrong with the option, then tell me. But in the absence of
that, I will have to assume that I am correct, that this is a design
oversight/cock-up/ass-scratcher and deal with it.
You're free to assume whatever floats your boat. You're still wrong,
though, even if you *assume* you are right.
It is also pretty obvious you didn't bother to read the docs [1] before
going all ranty.
Coolest would be someone posting a patch to spamass-milter to the list
that would add ignore BCC in header as an option, just like someone
posted a patch a few years ago for spamass-milter that adds an
authentication bypass. (which has yet to be added to the spamassassin
distro, even though many Linux/Unix distros now include it)
spamass-milter is NOT part of SA.
Thus, the patch you're referring to cannot and will never be added to
SA. No matter how hard you try to blame SA for not including the
spamass-milter patch...
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Problems with BCCing from spammers
On Thu, 2013-08-15 at 09:53 -0700, Ted Mittelstaedt wrote:
it is *not* a bug. It's not SA's task to split a msg to multiple rcpts.
Your glue (hack) or MTA (best) should do this.
It IS a bug since the software is not acting according to how it's
documented or expected. That is the definition of a software bug.
You can argue that it's a documentation bug and I might agree but it's
still a bug
See the M::SA::Conf [1] docs, option whitelist_to. The expected behavior
and headers considered are clearly listed.
Please show some evidence, that SA is acting in violation to its
documentation, and that none of the listed headers contain an address in
your whitelist_to / all_spam_to configuration.
An option stating all_spam_to followed by the email address of the
^^^
RECIPIENT is basically stating that ONLY mail sent TO the recipient will
be exempted.
Let me re-emphasize that: THE recipient. Who is the recipient of a
message with multiple recipients? At which point is it the recipient,
before or after local alias expansion?
Regardless, the whitelist_to option is not about THE recipient, but A
recipient. The first sentence of documentation shows this:
If the given address appears as a recipient in the message headers
(Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will be
whitelisted.
It would be better to have the option
all_spam_to_envelope_recipient
Patches accepted.
with the explanation that the recipient is who is being passed on the
envelope To: not the To: in the header, or something like that, but
the option as it stands implies the To: in the header, and that
implication should be disabused in the documentation for the config
file, at the very least.
It only implies (referring exclusively to) the To header, if one fails
to read the documentation -- absolutely clearly listing 12 headers.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
