Bare addresses alternative for __MANY_RECIPS?
Hi, I have been using __MANY_RECIPS in some meta rules for some time now, and noticed a weird FP today. The rule seems to count the number of '@'s in the To and CC header. Someone sent a mail to using the (albeit silly) format, probably by using reply-to-all in a braindead MUA: To The foo mailing list f...@lists.domain.tld CC: f...@lists.domain.tld f...@lists.domain.tld This triggers the __MANY_RECIPS rule as the @ occurs (at least?) 3 times. Is there any alternative to this rule, that only lists the addresses (i.e. excludes the name part in the To/CC)? Or maybe even removes the duplicates (that would probably be an eval rule)? Regards, Tom signature.asc Description: OpenPGP digital signature
RP_MATCHES_RCVD
b Trying to figure out why RP_MATCHES_RCVD scored so low. Is it because Return-Path: se...@c001n01.zahost.ru and the last Received matches that domain? if so, anything I can do to score t as the proper spam it is? Original Message Return-Path: se...@c001n01.zahost.ru Delivered-To: r...@domain.com Received: from localhost (localhost [127.0.0.1]) by mail.domain.com (Postfix) with ESMTP id CAE8980058; Sun, 20 Oct 2013 22:10:19 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.domain.com X-Spam-Flag: NO X-Spam-Score: 4.1 X-Spam-Level: X-Spam-Status: No, score=4.1 required=4.7 tests=[BAYES_99=4.2, HTML_MESSAGE=1.27, RP_MATCHES_RCVD=-1.37] autolearn=no Received: from mail.domain.com ([127.0.0.1]) by localhost (mail.domain.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id Fzg7udDKz5bJ; Sun, 20 Oct 2013 22:10:17 -0400 (EDT) Received: from c001n01.zahost.ru (c001n01.zahost.ru [88.212.201.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domain.com (Postfix) with ESMTPS id 669DC80051 for i...@domain.com; Sun, 20 Oct 2013 22:10:15 -0400 (EDT) Received: from localhost.zahost.ru ([127.0.0.1] helo=c001n01.zahost.ru) by c001n01.zahost.ru with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from se...@c001n01.zahost.ru) id 1VY1ND-0005fT-Kk for i...@domain.com; Mon, 21 Oct 2013 02:21:23 +0400 Received: (from semik@localhost) by c001n01.zahost.ru (8.14.4/8.13.8/Submit) id r9KMLM0s021783; Mon, 21 Oct 2013 02:21:22 +0400 (MSD) (envelope-from semik) Date: Mon, 21 Oct 2013 02:21:22 +0400 (MSD) Message-Id: 201310202221.r9kmlm0s021...@c001n01.zahost.ru To: i...@domain.com Subject: 4 New Voicemail(s) X-PHP-Script: 35x35.ru/ for 127.0.0.1 From: WhatsApp Messaging Service serv...@35x35.ru X-Mailer: Spmailver8.5 Reply-To: WhatsApp Messaging Service serv...@35x35.ru Mime-Version: 1.0 Content-Type: multipart/alternative;boundary=--138230768252645762B1112 WhatsApp You have a new voicemail! *Details* Time of Call: Oct-15 2013 07:55:57 Lenth of Call: 57 seconds Play http link has been removed *If you cannot play, move message to the Inbox folder. 2013 WhatsApp Inc
Re: RP_MATCHES_RCVD
On Mon, 21 Oct 2013, Mauricio Tavares wrote: b Trying to figure out why RP_MATCHES_RCVD scored so low. Is it because Return-Path: se...@c001n01.zahost.ru and the last Received matches that domain? if so, anything I can do to score t as the proper spam it is? RP_MATCHES_RCVD is a check that the message metadata is internally consistent. While giving it a negative score may not be justified, don't think that it's useful as a spam indicator and should have a positive score. In fact, as spams usually exhibit internal *inconsistencies* due to being largely forged, a message *not* hitting RP_MATCHES_RCVD may actually be a better spam indicator - that's probably the reason that it has a negative score. Given the surge in WhatsApp spams recently (I've been getting a lot) I think I should add some specific rules to my sandbox for testing. For the time being, you might want to do this in your local rules: body __VOICEMAIL/\bYou have a new voicemail!/i body __WHATSAPP /\bWhatsApp\b/ meta LCL_WHATSAPP __WHATSAPP __VOICEMAIL score LCL_WHATSAPP 1.000 That should be enough to push it over the threshold without FPs on legitimate (non-WhatsApp) voicemail notifications. Pointers from anyone who actually uses WhatsApp about how to distinguish legitimate voicemail notifications from these spams are solicited. Original Message Return-Path: se...@c001n01.zahost.ru Delivered-To: r...@domain.com Received: from localhost (localhost [127.0.0.1]) by mail.domain.com (Postfix) with ESMTP id CAE8980058; Sun, 20 Oct 2013 22:10:19 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.domain.com X-Spam-Flag: NO X-Spam-Score: 4.1 X-Spam-Level: X-Spam-Status: No, score=4.1 required=4.7 tests=[BAYES_99=4.2, HTML_MESSAGE=1.27, RP_MATCHES_RCVD=-1.37] autolearn=no Received: from mail.domain.com ([127.0.0.1]) by localhost (mail.domain.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id Fzg7udDKz5bJ; Sun, 20 Oct 2013 22:10:17 -0400 (EDT) Received: from c001n01.zahost.ru (c001n01.zahost.ru [88.212.201.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domain.com (Postfix) with ESMTPS id 669DC80051 for i...@domain.com; Sun, 20 Oct 2013 22:10:15 -0400 (EDT) Received: from localhost.zahost.ru ([127.0.0.1] helo=c001n01.zahost.ru) by c001n01.zahost.ru with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from se...@c001n01.zahost.ru) id 1VY1ND-0005fT-Kk for i...@domain.com; Mon, 21 Oct 2013 02:21:23 +0400 Received: (from semik@localhost) by c001n01.zahost.ru (8.14.4/8.13.8/Submit) id r9KMLM0s021783; Mon, 21 Oct 2013 02:21:22 +0400 (MSD) (envelope-from semik) Date: Mon, 21 Oct 2013 02:21:22 +0400 (MSD) Message-Id: 201310202221.r9kmlm0s021...@c001n01.zahost.ru To: i...@domain.com Subject: 4 New Voicemail(s) X-PHP-Script: 35x35.ru/ for 127.0.0.1 From: WhatsApp Messaging Service serv...@35x35.ru X-Mailer: Spmailver8.5 Reply-To: WhatsApp Messaging Service serv...@35x35.ru Mime-Version: 1.0 Content-Type: multipart/alternative;boundary=--138230768252645762B1112 WhatsApp You have a new voicemail! *Details* Time of Call: Oct-15 2013 07:55:57 Lenth of Call: 57 seconds Play http link has been removed *If you cannot play, move message to the Inbox folder. 2013 WhatsApp Inc -- 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 --- Gun Control laws aren't enacted to control guns, they are enacted to control people: catholics (1500s), japanese peasants (1600s), blacks (1860s), italian immigrants (1911), the irish (1920s), jews (1930s), blacks (1960s), the poor (always) --- 508 days since the first successful private support mission to ISS (SpaceX)
Re: RP_MATCHES_RCVD
On Mon, 21 Oct 2013, Mauricio Tavares wrote: b Trying to figure out why RP_MATCHES_RCVD scored so low. Is it because Return-Path: se...@c001n01.zahost.ru and the last Received matches that domain? if so, anything I can do to score t as the proper spam it is? On 21.10.13 10:24, John Hardin wrote: RP_MATCHES_RCVD is a check that the message metadata is internally consistent. While giving it a negative score may not be justified, don't think that it's useful as a spam indicator and should have a positive score. Giving this rule positive value would uselessly add score to correct mail, but any negative score increases possibility of false negative. I don't think this should have any score, imho __RP_MATCHES_RCVD for meta rules is just enough. It can be T_ rule if anyone wants, imho. I have set score of this rule to 0 because of those. In fact, as spams usually exhibit internal *inconsistencies* due to being largely forged, a message *not* hitting RP_MATCHES_RCVD may actually be a better spam indicator - that's probably the reason that it has a negative score. not hitting is very common by any hosted domains. -- 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. A day without sunshine is like, night.
Re: Testing the _REMOTEHOSTNAME_ in a rule
On Oct 19, 2013, at 5:28 PM, Karsten Bräckelmann guent...@rudersport.de wrote: On Fri, 2013-10-18 at 18:34 -0600, Philip Prindeville wrote: I'm trying to write a rule that gives some spamminess score to messages received from any host that resolves to protection.outlook.com. I tried to use _REMOTEHOSTNAME_ to do this, but I think I got the header syntax wrong. Template Tags cannot be used in rules. What you're looking for is the X-Spam-Relays-External or -Untrusted pseudo-header. http://wiki.apache.org/spamassassin/TrustedRelays Run a sample through spamassassin -D and grep the debug output for the X-Spam-Relays headers. You'll likely want to match your rule against the rdns or helo values. To ensure matching against the very last untrusted relay, no closing square bracket may appear before the match. RULE_NAME X-Spam-Relays-Untrusted =~ /^[^\]]+ rdns=evil.example.net / That rdns value is added to the Received header by your SMTP, and your MX actually should be listed as by value in that very [...] block. Thanks. By the way, in your example, the dots in evil.example.net need to be escaped, don't they? I ended up going with: header L_OUTLOOKX-Spam-Relays-Untrusted =~ /^[^\]]+ rdns=[^ ]*\.(ptr|outbound)\.protection\.outlook\.com / describe L_OUTLOOK Anything coming from outlook.com score L_OUTLOOK 4.95 and this seems to work. -Philip
Re: Testing the _REMOTEHOSTNAME_ in a rule
On Mon, 2013-10-21 at 13:19 -0600, Philip Prindeville wrote:
On Oct 19, 2013, at 5:28 PM, Karsten Bräckelmann guent...@rudersport.de
wrote:
RULE_NAME X-Spam-Relays-Untrusted =~ /^[^\]]+ rdns=evil.example.net /
That rdns value is added to the Received header by your SMTP, and your
MX actually should be listed as by value in that very [...] block.
Thanks. By the way, in your example, the dots in evil.example.net need
to be escaped, don't they?
It's not a must, but definitely best practice, yes.
(Properly escaping the dot if you want to literally match a dot, rather
than any char is even more important in the general case. In this very
example FPs are almost impossible due to the trailing space, anchoring
the TLD and readable domain.)
--
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: Bare addresses alternative for __MANY_RECIPS?
On Mon, 2013-10-21 at 14:11 +0200, Tom Hendrikx wrote:
I have been using __MANY_RECIPS in some meta rules for some time now,
and noticed a weird FP today. The rule seems to count the number of '@'s
in the To and CC header. Someone sent a mail to using the (albeit silly)
format, probably by using reply-to-all in a braindead MUA:
To The foo mailing list f...@lists.domain.tld
CC: f...@lists.domain.tld f...@lists.domain.tld
This triggers the __MANY_RECIPS rule as the @ occurs (at least?) 3 times.
Is there any alternative to this rule, that only lists the addresses
(i.e. excludes the name part in the To/CC)?
Nothing even remotely correct and sufficiently simple to squeeze into a
RE. Counting the @ chars is pretty rough, but a suitable trade-off IMHO.
I'd argue that 3 is too low to count as many. (Regardless of the
implementation and the FP you encountered.)
Or maybe even removes the duplicates (that would probably be an eval
rule)?
Yep, that would require an eval rule. As would any more sophisticate
implementation of the original rule.
--
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; }}}
