Re: Anybody else getting bombarded with "I RECORDED YOU" spam?
Sendmail didn't introduce FEATURE(require_rdns) until 2007. I'm sure I've been using it longer than that. And by default it's not enabled. It doesn't totally block the "I RECOVERED YOU" spams. Occasional some come through with ip addresses that have valid reverse lookups. But the number getting blocked, is still huge. On 11/10/2023 4:48 AM, Reindl Harald (privat) wrote: Am 10.11.23 um 08:40 schrieb Mark London: Marc - You are correct. All the IP sources of this spam, don't a valid reverse lookup of the IP address, to an IP name. That will solve my problem. Thanks! - Mark in other words your MTA is misconfigured https://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname On 11/9/2023 12:38 PM, Marc wrote: Do you at least verify the reverse lookup? That already stops a lot of such networks.
Re: Anybody else getting bombarded with "I RECORDED YOU" spam?
Marc - You are correct. All the IP sources of this spam, don't a valid reverse lookup of the IP address, to an IP name. That will solve my problem. Thanks! - Mark On 11/9/2023 12:38 PM, Marc wrote: Do you at least verify the reverse lookup? That already stops a lot of such networks.
Re: Anybody else getting bombarded with "I RECORDED YOU" spam?
Unfortunately most of the ip addresses do have reverse lookups. On the other hand, I do see that some have common domains. So I could use block by domain using sendmail. Heck, maybe I should just block the whole country. :) On 11/9/2023 12:38 PM, Marc wrote: The spam is coming from many different IP ranges, with little repetition. Most of them are from countries like Afghanistan, Kyrgyzstan, Azerbaijan, Kazakhstan, and Uzbekistan. Are these the latest sources that spam software is using, because other countries have tightened up their security? Do you at least verify the reverse lookup? That already stops a lot of such networks. I've been using spamassassin for almost several decades, and I've never noticed anything like this. I don't understand why the spam continues to be sent over and over. I do reject emails with a very high spam, which these spams have. So I tried changing my configuration to discard the email instead, hoping the spammer software would decide that the email had been received. This didn't help. I'm curious if anyone is noticing this spam. Thanks. - Mark This takes a while (afaik months at least).
Anybody else getting bombarded with "I RECORDED YOU" spam?
In the last couple of days, the number of "I RECORDED YOU" spams that my server has been receiving, has gone way up. Well over a thousand a day. And the spam is only being sent to about 20 of my users. We had been receiving these for the last month, but nothing at all like rate it's now happening. It's not using up a ton of CPU, but it is very annoying to see happening. The spam is coming from many different IP ranges, with little repetition. Most of them are from countries like Afghanistan, Kyrgyzstan, Azerbaijan, Kazakhstan, and Uzbekistan. Are these the latest sources that spam software is using, because other countries have tightened up their security? I've been using spamassassin for almost several decades, and I've never noticed anything like this. I don't understand why the spam continues to be sent over and over. I do reject emails with a very high spam, which these spams have. So I tried changing my configuration to discard the email instead, hoping the spammer software would decide that the email had been received. This didn't help. I'm curious if anyone is noticing this spam. Thanks. - Mark z
Re: users Digest 29 Sep 2023 01:08:28 -0000 Issue 5575
Sorry, I didn't change the subject line when I posted this. On 9/29/2023 12:41 PM, Mark London wrote: Hi - Can anyone tell me why the following email header triggered DKIM_SIGNED and DKIM_VALID, yet I don't see a DKIM header line? Strangely, if I run spamassassin from the command line on the message, DKIM_SIGNED is not triggered. SpamAssassin version 3.4.6 (Note, I truncated the X-Spam-Level header, as I have some customized rules.) Thanks. - MARK Received: from SRV-EXCHANGE.sdis58.local (static-css-csd-160189.business.bouyguestelecom.com [176.162.160.1 89]) by simplerelay.pulsation.fr (Postfix) with ESMTPS id 644B1203A3E3; Fri, 29 Sep 2023 04:56:31 +0200 (CEST) Received: from simplerelay.pulsation.fr (simplerelay.pulsation.fr [80.74.64.73]) by psfcmail2.psfc.mit.edu (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTP id 38T31Prc585381 for ; Thu, 28 Sep 2023 23:01:25 -0400 Received: from SRV-EXCHANGE.sdis58.local ([fe80::5034:8469:e7c0:7ca0]) by SRV-EXCHANGE.sdis58.local ([fe80::5034:8469:e7c0:7ca0%5]) with mapi id 15.01.2507.032; Fri, 29 Sep 2023 04:56:20 +0200 Received: from SRV-EXCHANGE.sdis58.local (192.168.20.11) by SRV-EXCHANGE.sdis58.local (192.168.20.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Fri, 29 Sep 2023 04:56:20 +0200 Received: from psfcmail2.psfc.mit.edu ([unix socket]) by psfcmail2.psfc.mit.edu (Cyrus 3.4.3-dirty-Debian-3.4.3-3build2) with LMTPA; Thu, 28 Sep 2023 23:01:27 -0400 Reply-To: From: "Louis LASTELLA" To: "Louis LASTELLA" Subject: RE: GRANT Date: Thu, 28 Sep 2023 20:56:19 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_NextPart_000_0AB3_01D9F291.A3EE6670" X-Mailer: Microsoft Outlook 16.0 X-Cyrus-Session-Id: cyrus-1695956487-582568-1-13949929973302507258 X-Sieve: CMU Sieve 3.0 X-Spam-Level: 5.61 (*) DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU ... X-Scanned-By: MIMEDefang 2.84 Thread-Index: AQE/AG+iBnwgFQrrEE2E+wgvHkku+Q== Content-Language: en-us X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OlkEid: D75AD23CECE28241A24D055234BB07EE0700C3B68E10F77511CEB4CD00AA00BBB6E6000B5BBF9 7B16F0AE24BA3D270A637831578CAB77333E06029E36245B2E3DACE37D29594 x-originating-ip: [195.154.60.67] x-esetresult: clean, is OK x-esetid: 37303A2976F0D65A657466
Re: Mysterious bogus DKIM hits (was: Re: users Digest 29 Sep 2023 01:08:28 -0000 Issue 5575)
On 9/29/2023 1:47 PM, Reindl Harald (gmail) wrote: Am 29.09.23 um 19:37 schrieb Bill Cole: Strangely, if I run spamassassin from the command line on the message, DKIM_SIGNED is not triggered. SpamAssassin version 3.4.6 Oh. So you've let a piece of security software go most of year after the explicitly final update to your version and the release of a new major version? That is not robust praxis what is NOT a robust praxis is bypassing the package amanager of your distribution spamassassin-3.4.6-7.fc37.x86_64 I'm using Ubuntu 22. not Fedpra. I installed the version from ubuntu, that was available when I created the server 6 months ago. I've updated it, and now it's 3.4.6-1ubuntu0.22.04.1 Not a big difference. FWIW.
Re: users Digest 29 Sep 2023 01:08:28 -0000 Issue 5575
Hi - Can anyone tell me why the following email header triggered DKIM_SIGNED and DKIM_VALID, yet I don't see a DKIM header line? Strangely, if I run spamassassin from the command line on the message, DKIM_SIGNED is not triggered. SpamAssassin version 3.4.6 (Note, I truncated the X-Spam-Level header, as I have some customized rules.) Thanks. - MARK Received: from SRV-EXCHANGE.sdis58.local (static-css-csd-160189.business.bouyguestelecom.com [176.162.160.1 89]) by simplerelay.pulsation.fr (Postfix) with ESMTPS id 644B1203A3E3; Fri, 29 Sep 2023 04:56:31 +0200 (CEST) Received: from simplerelay.pulsation.fr (simplerelay.pulsation.fr [80.74.64.73]) by psfcmail2.psfc.mit.edu (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTP id 38T31Prc585381 for ; Thu, 28 Sep 2023 23:01:25 -0400 Received: from SRV-EXCHANGE.sdis58.local ([fe80::5034:8469:e7c0:7ca0]) by SRV-EXCHANGE.sdis58.local ([fe80::5034:8469:e7c0:7ca0%5]) with mapi id 15.01.2507.032; Fri, 29 Sep 2023 04:56:20 +0200 Received: from SRV-EXCHANGE.sdis58.local (192.168.20.11) by SRV-EXCHANGE.sdis58.local (192.168.20.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Fri, 29 Sep 2023 04:56:20 +0200 Received: from psfcmail2.psfc.mit.edu ([unix socket]) by psfcmail2.psfc.mit.edu (Cyrus 3.4.3-dirty-Debian-3.4.3-3build2) with LMTPA; Thu, 28 Sep 2023 23:01:27 -0400 Reply-To: From: "Louis LASTELLA" To: "Louis LASTELLA" Subject: RE: GRANT Date: Thu, 28 Sep 2023 20:56:19 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_NextPart_000_0AB3_01D9F291.A3EE6670" X-Mailer: Microsoft Outlook 16.0 X-Cyrus-Session-Id: cyrus-1695956487-582568-1-13949929973302507258 X-Sieve: CMU Sieve 3.0 X-Spam-Level: 5.61 (*) DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU ... X-Scanned-By: MIMEDefang 2.84 Thread-Index: AQE/AG+iBnwgFQrrEE2E+wgvHkku+Q== Content-Language: en-us X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OlkEid: D75AD23CECE28241A24D055234BB07EE0700C3B68E10F77511CEB4CD00AA00BBB6E6000B5BBF9 7B16F0AE24BA3D270A637831578CAB77333E06029E36245B2E3DACE37D29594 x-originating-ip: [195.154.60.67] x-esetresult: clean, is OK x-esetid: 37303A2976F0D65A657466
Dropbox invoice phishing
Dropbox now has an invoice feature, that allows you to create a customized invoice. So what this person did was to create an invoice that looks like it’s coming from PayPal. Except for the fact that the From address shows it is coming from Dropbox. Months ago I saw a similar problem with fake invoices coming from PayPal. I hate Spammers. > On Mar 20, 2023, at 2:58 PM, Greg Troxel wrote: > > A quick grep shows: > > > 4.00/updates_spamassassin_org/60_welcomelist_auth.cf:def_welcomelist_auth > *@*.dropbox.com > > so the code is operating as designed. > > It seems that either dropbox is compromised, or dropbox is allowing > user-generated content to go out under their domain. Either way it > seems they should be removed from USER_IN_DEF_SPF_WL, unless this is a > blip and they fix it right away. > > Have you written to ab...@dropbox.com, and what did they say? >
Re: Why was USER_IN_DEF_SPF_WL triggered on this email, even though it's spam?
I’ve never seen a false positive with USER_IN_DEF_SPF_WL. > On Mar 20, 2023, at 1:48 PM, Reindl Harald wrote: > > > >> Am 20.03.23 um 18:44 schrieb Mark London: >> It seems like it too high a negative score. > > then adjust it in local.cf > > the point of a WL is exactly to WL something - and yes, it can happen that > spam comes from a whitelisted source > > for example when some employeer of your bank has malware on his machine - > would you want regular mails from your bank at the risk of FP and lose money > just because filtering can't be perfect by definition? > >>> On 3/20/2023 1:24 PM, Reindl Harald wrote: >>> >>> >>> Am 20.03.23 um 18:17 schrieb Mark London: >>>> Can someone tell me why this paypal phishing email, managed to trigger >>>> USER_IN_DEF_SPF_WL? >>>> Or put it another way. Why wasn't it detected as a phishing email? Thanks. >>> >>> Becasue it was a SPF hit and the envelope sender is in USER_IN_DEF_SPF_WL? >>> frankly - what else do you expect to hear? >
Re: Why was USER_IN_DEF_SPF_WL triggered on this email, even though it's spam?
It seems like it too high a negative score. On 3/20/2023 1:24 PM, Reindl Harald wrote: Am 20.03.23 um 18:17 schrieb Mark London: Can someone tell me why this paypal phishing email, managed to trigger USER_IN_DEF_SPF_WL? Or put it another way. Why wasn't it detected as a phishing email? Thanks. Becasue it was a SPF hit and the envelope sender is in USER_IN_DEF_SPF_WL? frankly - what else do you expect to hear?
Why was USER_IN_DEF_SPF_WL triggered on this email, even though it's spam?
Can someone tell me why this paypal phishing email, managed to trigger USER_IN_DEF_SPF_WL? Or put it another way. Why wasn't it detected as a phishing email? Thanks. Received: from a39-208.smtp-out.amazonses.com (a39-208.smtp-out.amazonses.com [54.240.39.208]) by PSFCMAIL.MIT.EDU (8.14.7/8.14.7) with ESMTP id 32KGQHFm099160 (version=TLSv1/SSLv3 cipher=AES128-SHA256 bits=128 verify=NOT) for ; Mon, 20 Mar 2023 12:26:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=rid2v4iwdmeb26wntc7bqs5dnqgasdul; d=dropbox.com; t=1679329577; h=Content-Type:MIME-Version:From:To:CC:Subject:Date:Message-ID:Reply-To; bh=l2b7HMFmOjBDciMdIctq/6okXsHLQ3QtlCcrrKeBJFo=; b=JZDgJOd2uPgAFKgSkAHeZ91+AJxLr/Rl231qxeOFdeMpeSo3NYG+WyedzpPWJneI IkTEHtDYWQMhQf5bAJYJB+3hEF0n6t9MnmQzaF8xDlRK269ILVw/pfn8NHiNW7XR5R5 S/Y1XQpbvN8ezTWvCqiedTTQ/ubqm9KPXljCyPF4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1679329577; h=Content-Type:MIME-Version:From:To:CC:Subject:Date:Message-ID:Reply-To:Feedback-ID; bh=l2b7HMFmOjBDciMdIctq/6okXsHLQ3QtlCcrrKeBJFo=; b=WvG6JHQ5+a4w8pq7gZNZYz/ph2i13+NZaJqfqWqnQYRewLpSyhcx5a5AeaJ+JPd+ xwwriSGEl5bNes3b0gkdp/oYd9niSty0sZy/Vquwx5tQiZWVr6zWXzhyBMyqHvWbkh0 sK3+fUdnhNigDX3wqE7/W3+ccK+XgH7ab5pstqb0= Content-Type: multipart/alternative; boundary="===1633481412880569064==" MIME-Version: 1.0 From: PayPal Support To: x...@psfc.mit.edu CC: Subject: =?utf-8?q?Your_invoice_from_PayPal_Support_=28=23038989SL43=29?= Date: Mon, 20 Mar 2023 16:26:17 + Message-ID: <01000186ffd7c860-2ed35238-7287-4f0b-b752-22466377b187-000...@email.amazonses.com> X-Dropbox-Message-ID: 3637112534418604150 Reply-To: no-re...@paypal.com Feedback-ID: 1.us-east-1.syWQ1+fF8Wo1tY8y/+s85ptiAKu7bILK6PHyxwpB+xo=:AmazonSES X-SES-Outgoing: 2023.03.20-54.240.39.208 --===1633481412880569064== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New invoice$629.00 Paid on March 20, 2023 View invoice[1] To PayPal= Billing Bot invoice_rece...@paypal.com From PayPal Support no-reply@P= ayPal.com Issued March 20, 2023 Title wish to request a refund, please co= ntact our support team at : +1 (833) 465-5681 Your recent purchase of Te= ther (USDT) for $629.00 via PayPal has been confirmed. The funds will be re= flected in your account within 24 hours. If you require any assistance or w= ish to request a refund, please contact our support team at : +1 (833) = 465-5681 PayPal Support sent you an invoice using Dropbox, Inc. PO Box 77= 767, San Francisco, CA 94107 View Privacy Policy[2] =20 [1]: https://invoice.dropbox.com/invoices/view/cap_pid_inv%3AAOxsdGyt1l= 3tFh9ZGervJ5Of-1znmrl1kE1pnlfEDUsg?utm_campaign=3Dsend_invoice_medium= =3Demail_source=3Ddropbox_term=3Dview_invoice [2]: https://www.dropbox.com/l/AABfXvXi7J31sSfCfcEcmcs-kdTvg1Al_EE/privacy --===1633481412880569064== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable http://www.w= 3.org/TR/REC-html40/loose.dtd"> http://www.w3.org/1999/xhtml;> Sans, HelveticaNeue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica= , Arial, Lucida Grande, sans-serif; font-size: 20px; font-weight: 300; line= -height: 1.45em; padding: 15px 0; width: 720px;"> <= /div> $629.00 P= aid on March 20, 2023 https://invoice.dropbox.com/invoices/view/cap_pid_inv%3AAOxsdGyt= 1l3tFh9ZGervJ5Of-1znmrl1kE1pnlfEDUsg?utm_campaign=3Dsend_invoiceutm_me= dium=3Demailutm_source=3Ddropboxutm_term=3Dview_invoice" style=3D= "text-decoration: none; background-color: #0061FE; color: white; font-size:= 16px; line-height: 20px; margin: 0 auto; width: 100%; padding: 10px 0; dis= play: block; background-color: #002C8A; color:#f7f5f2; ">View invoice #F7F5F2; width: 100%; min-width:375px; margin: 0px auto; padding: 16px 20p= x 20px; font-size: 12px; line-height: 20px; font-weight: 400; text-align: = left;"> To PayPal Billing Bot invoice_rece...@paypal.com From PayPal Support no-re...@paypal.com Issued March 20, 2023 Title 0;">wish to request a refund, please contact our support team at : +1 (83= 3) 465-5681 Your recent purchase of Tether= (USDT) for $629.00 via PayPal has been confirmed. The funds will be reflec= ted in your account within 24 hours. If you require any assistance or wish = to request a refund, please contact our support team at : +1 (833) 465-= 5681 PayPal Support sent you an invoice using https://www.dropbox.com/static/images/fbm/invoi= ce_wordmark_2x.png"> Dropbox, Inc. PO Box 77767, San Francisco, CA 94107 https://www.dropbox.com/l/AABu1cd-4liBqZhM00gH24g3= HtVHu7tb9rc/privacy" style=3D"text-decoration: none; margin-left: 12px">Vie= w Privacy Policy https://www.dropbox.com/l/AACSvyNy75C_S_pXf= DFRWnzE6wulAbspDwg" width=3D"1" /> --===1633481412880569064==--
Re: Maybe it's time to revive EvilNumbers?
Loren - Unfortunately, LW_BOGUS_ORDER doesn't get triggered for my
email, because there is no List-Id. The email actually came from a
microsoft account. - Mark
header __LW_SUB_INVOICE Subject =~ /\b(?:invoice|order)\b/
header __LW_FROM_INVOICE From =~ /\b(?:invoice|order)\b/
header __LW_ABC_LISTID List-Id =~ /\w{13}\s+\, some
meta LW_BOGUS_ORDER (__LW_SUB_INVOICE || __LW_FROM_INVOICE) &&
__LW_ABC_LISTID
score LW_BOGUS_ORDER 5
describe LW_BOGUS_ORDER Fake order or invoice
On 6/19/2021 4:41 PM, users-digest-h...@spamassassin.apache.org wrote:
A number of the rules I passed along are generic "order" rules rather
than Amazon specific. I had to go back to last month's spam to find an
Amazon order spam, but I've gotten a dozen or so fake orders for other
things this month, all of which hit on the LW_BOGUS_ORDER rule
Re: Maybe it's time to revive EvilNumbers?
Loren - Unfortunately, the fake amazon shipment email that we received, doesn't contain the word Amazon in it's From or Subject headers. Or even the word amazon in the text of the message! Just the Amazon logo. And they've removed all the URLs, so the links don't work at the bottom. And they left the postal address of amazon, without the word amazon. I hate bogus spam that is so obviously bogus that it avoids filter rules. :) - Mark On 6/17/2021 10:52 AM, users-digest-h...@spamassassin.apache.org wrote: Subject: Re: Maybe it's time to revive EvilNumbers? From: "Loren Wilton" Date: 6/16/2021, 8:18 PM To: Here are a handful of rules that work for me. Feel free to try them. If you do, please let me know how they work for you. (Apologies for my mail client trashing the formatting. Be sure to check for possible line wrap on some of the rules!)
Maybe it's time to revive EvilNumbers?
My site is getting a lot of spam that is getting past spamassassin. Because it has a hone number to call, and rather than a link to login using username and password. Mostly fake amazon purchases. They are getting past a lot of URL block lists because of that. FWIW. - Mark
Why is SENDGRID_REDIR score so high?
Hi - I receive email from spiceworks.com help desk, which are sent via sendgrid. Why do these URLs trigger the SENDGRID_REDIR rule score, which is 3.4 ? Thanks. - Mark Terms and Conditions: https://u2752257.ct.sendgrid.net/ls/click?upn=cXUsNXpk4aguQpIafAEOmIejjD9ZkCNTPoNNmoa1ebrAUotywMJTp7DEBn7GytalLkTf_8lxoDjRwBLjcEcMtF8M5ApYR1AJKfKZukCa01OUZ6PgghULd-2FNN7L6qPk5t3kRl0b1zrUCfn5j7veAMSuKobLbvM1i2BY9-2FM8B1BpQSRnSs54y0iV7P8FnmuQXGD4eQkIqKfPELx6aNdbuFCgIQecDPo5\ EFoQxdE7JySPVPuU9N49Iip-2FAXbBQj-2BLN0cly9tAICcjMYqlAxin7RkTG4oRA Privacy Policy: https://u2752257.ct.sendgrid.net/ls/click?upn=cXUsNXpk4aguQpIafAEOmIejjD9ZkCNTPoNNmoa1ebqRhFzshCDTA7-2BL-2FYYwBE3VGk_y_8lxoDjRwBLjcEcMtF8M5ApYR1AJKfKZukCa01OUZ6PgghULd-2FNN7L6qPk5t3kRl0YIWr1WEURsRppHsiq7oYUNdAmf1x7n6J-2BNofwjd7xwa8e-2FvvCVFrqBYuLGxS3Z7NV0qlW-2FJoasrFm8xaQ0-2BrfN04MfX-2Bo-2BobNtFOsUHtI-2BERUMY5rBGmZTY7WFV7eoMJ8Kal5pHd-2FjR5xXpKzlEzjQ
Sendgrid Under Siege from Hacked Accounts
https://krebsonsecurity.com/2020/08/sendgrid-under-siege-from-hacked-accounts/ <https://krebsonsecurity.com/2020/08/sendgrid-under-siege-from-hacked-accounts/> - Mark
Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK
Can we start a separate mailing list for people to discuss this issue elsewhere?
Re: Linux, Twitter, Mysql, Github, etc, all plan to remove blacklist and whitelist, master and slave.
"As programmers, our day to day work doesn’t typically present us with opportunities to take a stand against racism. Situations like this are opportunities to be the change we want to see. When you get that opportunity and you don’t act, or even worse, you defend the status quo." That quote was from a 2018 blog: https://blog.carbonfive.com/problematic-terminology-in-open-source/ According to Wikipedia, Master/Slave was changed by IBM,[8] Microsoft,[9] Engine Yard,[10] Amazon Web Services/Amazon Relational Database Service,[11] as well as in Python,[12] Django,[13][14] Drupal,[15] CouchDB,[16] and Redis: https://en.wikipedia.org/wiki/Master/slave_(technology)#Terminology_concerns The creator of Redis initially resisted the change of master/slave, and he received many "colorful" responses to his view at that time, which are worth reading: http://antirez.com/news/122 Eventually, he decided to make the change, and also received many "interesting" responses: https://github.com/redis/redis/issues/5335 Arguing for or against the change in terms, would have been useful when it was originally proposed, years ago. But since the terms are being changed in the software world, arguing now is pointless. Things are changing, whether people like it or not. The year 2000 didn't bring changes that people expected. But the year 2020, certainly has.
Re: Linux, Twitter, Mysql, Github, etc, all plan to remove blacklist and whitelist, master and slave.
The proposed name changes were proposed for many years in the software community. For example in 2014, Drupal opted to use "primary/replica" instead, and Django followed suit the same year with "leader/follower". In 2018, there apparently was a renewed interest in changing the names by many others. For example, I found: https://tools.ietf.org/id/draft-knodel-terminology-00.html So this issue is nothing new, and the arguments on this issue, that have been occurring on this mailing list, have already occurred. - Mark On 7/10/2020 7:18 PM, Marc Roos wrote: Pf, twitter, microsoft, oracle all billion dollar companies only removing some words The news is full of black minorities having higher risk of death in coronavirus. Unemployment is highest amongst ethnic minorities. And these companies are only concerned filling their pockets, storing their money in tax havens. You have in the states famous people bribe good schools so their kids can attend (at the expense of others). It is just a fucking insult to ethnic minorities having such companies talking only about changing words! Wtf this Amazon guy 150 billion, the most greediest man on the planet!!! Let me guess, his employees get paid lowest on the market I would think twice mentioning such companies as examples. Don't forget Zuckerberg called facebook users 'dumb fucks', that is the standard at such companies. [1] https://www.zerohedge.com/news/2018-03-25/dumb-f-ks-julian-assange-reminds-us-what-mark-zuckerberg-thinks-facebook-users -Original Message- To: users@spamassassin.apache.org Subject: Linux, Twitter, Mysql, Github, etc, all plan to remove blacklist and whitelist, master and slave. Spamassassin is not alone. https://www.google.com/search?q=whitelist+blacklist=1C1CHBD_enUS893US893=ALeKk02i5oEeNFMyRbCSyvz1P74SAG8W8A:1594419806351=lnms=nws=X=2ahUKEwiwobjR3MPqAhVUknIEHbzFCdwQ_AUoAXoECA0QAw=1008=5900
Linux, Twitter, Mysql, Github, etc, all plan to remove blacklist and whitelist, master and slave.
Spamassassin is not alone. https://www.google.com/search?q=whitelist+blacklist=1C1CHBD_enUS893US893=ALeKk02i5oEeNFMyRbCSyvz1P74SAG8W8A:1594419806351=lnms=nws=X=2ahUKEwiwobjR3MPqAhVUknIEHbzFCdwQ_AUoAXoECA0QAw=1008=5900
__BITCOIN_ID doesn't test for SegWit addresses that start with bc1
Hi - I just got a BITCOIN blackmail spam that avoided detection, because it used a SegWit bitcoin address, that starts with a bc1: bc1q0q7u8a7735za93um20yk5ynphdnpvenj0k0ufn This format is explained here: https://changelly.com/blog/bitcoin-addresses-types-and-meaning/ I guess the definition of __BITCOIN_ID needs to updated to include this format. Thanks. - Mark
False positives due to __BITCOIN_ID
It seems to me that the rule for detecting a BITCOIN in an email, is incorrect. See below: body __BITCOIN_ID /\b(?Why is there a \s in this rule?I didn't think that a BITCOIN id has a space. This rule is triggered, on a simple line like this, because of the fact that the line has a "1" in it: For sure figure 1 is convincing that nqR is a good organising Maybe this rule needs tweaking? Thanks. - Mark
Bombard by spam source in India that wasn't in any RBL used by spamassassin.
Hi - We got several hours of spam from the IP address 103.136.41.36 in India.When I did a Multi-RBL check, the ip address was in the following databases: bl.emailbasura.org dnsbl.sorbs.net dns.spfbl.net spam.spamrats.com truncate.gbudb.net I think sorbs.net is a paid for service. At least I tried adding rules, but they weren't triggered. I was able to successfully add rules for spamrats and gbudb. Does anyone have experience with those? After about 3 hours, the IP address finally appeared in barracudacentra.org, which spamassassin uses. Given the amount of traffic we were receiving, I'm surprised it didn't show up sooner on the other RBLs. Thanks. - Mark
Is PDS_TONAME_EQ_TOLOCAL_SHORT new?
Is PDS_TONAME_EQ_TOLOCAL_SHORT new? I see it hitting real emails here, but hitting no spam emails. Thanks. - Mark Sent from my iPhone
PDS_NO_HELO_DNS is not helpful at all.
I'm sorry for not using bugzilla, but the new rule for PDS_NO_HELO_DNS is mostly hittng real emails at my site 1168 real emails versus 219 spam mls. Luckily, the score is not high, to be making any difference. FWIW. - Mark
Re: How do I filter emails that have only special characters in them.
The header is huge (stupid Microsoft!), but yes, it’s UTF-8 encoding, in order to include special characters that look like normal letters. So I can’t easily do text filtering on it. Below is the whole body of the text, except for a link at the bottom. It is not an html email. Maybe I can test for short non-html emails that only have utf-8 characters and a single link at the bottom of the email. Sent from my iPhone > On Jul 2, 2019, at 8:42 AM, Kevin A. McGrail wrote: > > Mark, can you put a sample up on pastebin? That looks like ASCII hex but > ending up with UTF-8 chars I think. I can't remember an encoding format like > that so hoping the sample gives me a hint. > > Regards, > KAM > -- > Kevin A. McGrail > Member, Apache Software Foundation > Chair Emeritus Apache SpamAssassin Project > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > >> On Tue, Jul 2, 2019 at 8:17 AM Mark London wrote: >> Hi - I'm trying to filter emails that have only special characters in >> them. Like the text of the following email. Thanks. - Mark >> >> - =CA=9C=C9=AA=CA=80=E1=B4=87s s=CA=9C=E1=B4=87=E1=B4=8D=E1=B4=80=CA=9F=E1= >> =B4=87s =E1=B4=9B=E1=B4=8F s=E1=B4=9C=E1=B4=84=E1=B4=8B =E1=B4=9B=CA=9C=E1= >> =B4=87=C9=AA=CA=80 =E1=B4=84=E1=B4=8F=E1=B4=84=E1=B4=8B =C9=AA=C9=B4 =E1=B4= >> =9B=CA=9C=E1=B4=87 =E1=B4=84=E1=B4=8F=E1=B4=8D=E1=B4=98=E1=B4=80=C9=B4=CA= >> =8F's =E1=B4=9B=E1=B4=8F=C9=AA=CA=9F=E1=B4=87=E1=B4=9Bs.=20=20 >> - =E1=B4=8D=E1=B4=80s=E1=B4=9B=E1=B4=9C=CA=80=CA=99=E1=B4=80=E1=B4=9B=E1=B4= >> =87 =E1=B4=8F=C9=B4 =E1=B4=9B=CA=9C=E1=B4=87 =E1=B4=87=E1=B4=8D=E1=B4=98=CA= >> =9F=E1=B4=8F=CA=8F=E1=B4=87=E1=B4=87s =E1=B4=84=E1=B4=A0's.=20=20 >> - =D2=93=C9=AA=CA=80=E1=B4=87s =E1=B4=87=E1=B4=8D=E1=B4=98=CA=9F=E1=B4=8F= >> =CA=8F=E1=B4=87=E1=B4=87s =C9=AA=D2=93 =E1=B4=9B=CA=9C=E1=B4=87=CA=8F =E1= >> =B4=85=E1=B4=8F=C9=B4'=E1=B4=9B =E1=B4=98=CA=80=E1=B4=80=E1=B4=84=E1=B4=9B= >> =C9=AA=E1=B4=84=E1=B4=87 =E1=B4=98=CA=80=E1=B4=8Fs=E1=B4=9B=C9=AA=E1=B4=9B= >> =E1=B4=9C=E1=B4=9B=C9=AA=E1=B4=8F=C9=B4.=20=20 >> - =C9=AAs =E1=B4=80 =E1=B4=98s=CA=8F=E1=B4=84=CA=9C=E1=B4=8F=E1=B4=98=E1=B4= >> =80=E1=B4=9B=CA=9C.=20=20 >> - s=E1=B4=87=C9=B4=E1=B4=85 =E1=B4=9B=CA=9C=E1=B4=87 =E1=B4=98=E1=B4=8F=CA= >> =9F=C9=AA=E1=B4=84=E1=B4=87 =C9=AA=C9=B4 =E1=B4=9B=E1=B4=8F =CA=8F=E1=B4=8F= >> =E1=B4=9C=CA=80 =CA=9C=E1=B4=8F=E1=B4=8D=E1=B4=87 =C9=AA=D2=93 =CA=8F=E1=B4= >> =8F=E1=B4=9C =E1=B4=84=E1=B4=8F=E1=B4=8D=E1=B4=98=CA=9F=E1=B4=80=C9=AA=C9= >> =B4 =E1=B4=80=CA=99=E1=B4=8F=E1=B4=9C=E1=B4=9B =E1=B4=8D=E1=B4=80=C9=B4=E1= >> =B4=80=C9=A2=E1=B4=87=CA=80's =E1=B4=80=CA=99=E1=B4=9Cs=E1=B4=87s! >> >> =E1=B4=84=E1=B4=8F=E1=B4=8D=E1=B4=98=CA=9F=E1=B4=80=C9=AA=C9=B4=E1=B4=9B = >> =E1=B4=9B=E1=B4=8F =E1=B4=A1=CA=80=E1=B4=8F=E1=B4=84=CA=9F=E1=B4=80=E1=B4= >> =A1 =E1=B4=98=E1=B4=8F=CA=9F=C9=AA=E1=B4=84=E1=B4=87 =E1=B4=9B=CA=9C=E1=B4= >> =80=E1=B4=9B =C9=AA=CA=99=E1=B4=8D =E1=B4=A1=CA=80=E1=B4=8F=E1=B4=84=CA=9F= >> =E1=B4=80=E1=B4=A1 =E1=B4=98=CA=80=E1=B4=80=E1=B4=84=E1=B4=9B=C9=AA=E1=B4= >> =84=E1=B4=87 =E1=B4=98=CA=80=E1=B4=8Fs=E1=B4=9B=C9=AA=E1=B4=9B=E1=B4=9C=E1= >> =B4=9B=C9=AA=E1=B4=8F=C9=B4: >>
How do I filter emails that have only special characters in them.
Hi - I'm trying to filter emails that have only special characters in them. Like the text of the following email. Thanks. - Mark - =CA=9C=C9=AA=CA=80=E1=B4=87s s=CA=9C=E1=B4=87=E1=B4=8D=E1=B4=80=CA=9F=E1= =B4=87s =E1=B4=9B=E1=B4=8F s=E1=B4=9C=E1=B4=84=E1=B4=8B =E1=B4=9B=CA=9C=E1= =B4=87=C9=AA=CA=80 =E1=B4=84=E1=B4=8F=E1=B4=84=E1=B4=8B =C9=AA=C9=B4 =E1=B4= =9B=CA=9C=E1=B4=87 =E1=B4=84=E1=B4=8F=E1=B4=8D=E1=B4=98=E1=B4=80=C9=B4=CA= =8F's =E1=B4=9B=E1=B4=8F=C9=AA=CA=9F=E1=B4=87=E1=B4=9Bs.=20=20 - =E1=B4=8D=E1=B4=80s=E1=B4=9B=E1=B4=9C=CA=80=CA=99=E1=B4=80=E1=B4=9B=E1=B4= =87 =E1=B4=8F=C9=B4 =E1=B4=9B=CA=9C=E1=B4=87 =E1=B4=87=E1=B4=8D=E1=B4=98=CA= =9F=E1=B4=8F=CA=8F=E1=B4=87=E1=B4=87s =E1=B4=84=E1=B4=A0's.=20=20 - =D2=93=C9=AA=CA=80=E1=B4=87s =E1=B4=87=E1=B4=8D=E1=B4=98=CA=9F=E1=B4=8F= =CA=8F=E1=B4=87=E1=B4=87s =C9=AA=D2=93 =E1=B4=9B=CA=9C=E1=B4=87=CA=8F =E1= =B4=85=E1=B4=8F=C9=B4'=E1=B4=9B =E1=B4=98=CA=80=E1=B4=80=E1=B4=84=E1=B4=9B= =C9=AA=E1=B4=84=E1=B4=87 =E1=B4=98=CA=80=E1=B4=8Fs=E1=B4=9B=C9=AA=E1=B4=9B= =E1=B4=9C=E1=B4=9B=C9=AA=E1=B4=8F=C9=B4.=20=20 - =C9=AAs =E1=B4=80 =E1=B4=98s=CA=8F=E1=B4=84=CA=9C=E1=B4=8F=E1=B4=98=E1=B4= =80=E1=B4=9B=CA=9C.=20=20 - s=E1=B4=87=C9=B4=E1=B4=85 =E1=B4=9B=CA=9C=E1=B4=87 =E1=B4=98=E1=B4=8F=CA= =9F=C9=AA=E1=B4=84=E1=B4=87 =C9=AA=C9=B4 =E1=B4=9B=E1=B4=8F =CA=8F=E1=B4=8F= =E1=B4=9C=CA=80 =CA=9C=E1=B4=8F=E1=B4=8D=E1=B4=87 =C9=AA=D2=93 =CA=8F=E1=B4= =8F=E1=B4=9C =E1=B4=84=E1=B4=8F=E1=B4=8D=E1=B4=98=CA=9F=E1=B4=80=C9=AA=C9= =B4 =E1=B4=80=CA=99=E1=B4=8F=E1=B4=9C=E1=B4=9B =E1=B4=8D=E1=B4=80=C9=B4=E1= =B4=80=C9=A2=E1=B4=87=CA=80's =E1=B4=80=CA=99=E1=B4=9Cs=E1=B4=87s! =E1=B4=84=E1=B4=8F=E1=B4=8D=E1=B4=98=CA=9F=E1=B4=80=C9=AA=C9=B4=E1=B4=9B = =E1=B4=9B=E1=B4=8F =E1=B4=A1=CA=80=E1=B4=8F=E1=B4=84=CA=9F=E1=B4=80=E1=B4= =A1 =E1=B4=98=E1=B4=8F=CA=9F=C9=AA=E1=B4=84=E1=B4=87 =E1=B4=9B=CA=9C=E1=B4= =80=E1=B4=9B =C9=AA=CA=99=E1=B4=8D =E1=B4=A1=CA=80=E1=B4=8F=E1=B4=84=CA=9F= =E1=B4=80=E1=B4=A1 =E1=B4=98=CA=80=E1=B4=80=E1=B4=84=E1=B4=9B=C9=AA=E1=B4= =84=E1=B4=87 =E1=B4=98=CA=80=E1=B4=8Fs=E1=B4=9B=C9=AA=E1=B4=9B=E1=B4=9C=E1= =B4=9B=C9=AA=E1=B4=8F=C9=B4:
Another form of obfuscation email.
Does anyone have any rules that can catch this type of obfuscated spam? https://pastebin.com/qi8dsREW Thanks. - Mark
Re: How to block email with multiple addresses in From: IGNORE ME.
Sorry, I meant this doesn't work: header BAD_FROM_PSFCFrom: =~ /^\S+\@psfc.mit.edu,/i Without the ^ It does work: header BAD_FROM_PSFCFrom: =~ /\S+\@psfc.mit.edu,/i So I just tried: header BAD_FROM_PSFCFrom: =~ /^\W*\S+\@psfc.mit.edu,/i And that works. although I don't know why I need the \W*. But, whatever! Never mind. - Mark On 12/20/2018 12:30 PM, Mark London wrote: Hi - What's the best rule to catch email with multiple addresses in the From: line? I realize thatrfc2822allows it. But the only email we've ever received with multiple addresses, were spam, and even GMAIL.COM doesn't allow it: <<< 550-5.7.1 Messages with multiple addresses in From: <<< 550 5.7.1 header are not accepted. e7si4119336qvp.159 - gsmtp At the very least, I want to block emails that spoof my domain. I.e. I want to block email that has @psfc.mit.edu followed by a comma. For example: From:struth...@psfc.mit.edu, "Lorraine M." I tried to have a rule like: header BAD_FROM_PSFCFrom: =~ /\S+\@psfc.mit.edu,/i This rule gets triggered when I run spamassasin manually on the email. But it doesn't gets triggered on actual incoming email. I even tried: header BAD_FROM_PSFCALL =~ /From: \S+\@psfc.mit.edu,/i It's still not triggered. Any ideas? Thanks. - Mark
How to block email with multiple addresses in From:
Hi - What's the best rule to catch email with multiple addresses in the From: line? I realize thatrfc2822allows it. But the only email we've ever received with multiple addresses, were spam, and even GMAIL.COM doesn't allow it: <<< 550-5.7.1 Messages with multiple addresses in From: <<< 550 5.7.1 header are not accepted. e7si4119336qvp.159 - gsmtp At the very least, I want to block emails that spoof my domain. I.e. I want to block email that has @psfc.mit.edu followed by a comma. For example: From: struth...@psfc.mit.edu, "Lorraine M. " I tried to have a rule like: header BAD_FROM_PSFCFrom: =~ /\S+\@psfc.mit.edu,/i This rule gets triggered when I run spamassasin manually on the email. But it doesn't gets triggered on actual incoming email. I even tried: header BAD_FROM_PSFCALL =~ /From: \S+\@psfc.mit.edu,/i It's still not triggered. Any ideas? Thanks. - Mark
Re: BITCOIN_PAY_ME and new type of blackmail, non porn.
However, I think the BITCOIN_PAY_ME rule need a bit of fine tuning, to catch other emails. Like the one below, which escaped triggering the rule. A constant battle between spam rules, and bad English grammar. Maybe I should say the hell with it, and simply block any email sent to me, with a bitcoin address in it. :) - Mark -- I've got a personal webpage that includes all types of products and services which actually i sell in darknet.Anything from completely messing up somebody's small business to physical accidents etcetera, nevertheless almost nothing significant like getting rid of. Quite often it is some shit similar too declined relationship or rivalry at the job.Anyway i have been contacted recently by customer to make an arrangement and also target is clearly you. In a immediate and painless manner. The simple truth is i only get money following any complete task and so choice to contact you before, in order to give me for sitting non-active this i quite often offer the victim.If perhaps i do not get everything that im requesting, my people will accomplish the sequence.Yet if i will make an agreement, apart eliminating the request you are going to receive full details concerning the customer that i have found. Immediately after the order is accomplished, I often wipe out the operator also, as a result i have a decision, to get a grand and two hundred via you, in essence with no efforts, or simply to get four grand from the customer, but get rid of my operator. I am getting transfers just through Btc aka bitcoin , it is my BTC transaction address - 17Jwo9gG4hnffteqe2h4AVfbMrzXLJQFtA From now on you have only thirty-nine hours to balance transfer
BITCOIN_PAY_ME and new type of blackmail, non porn.
This email hit the new (to me) BITCOIN_PAY_ME rule. Never ending fun. Begin forwarded message: > From: "Broaddus Walther" > Date: December 17, 2018 at 1:49:04 PM EST > To: m...@psfc.mit.edu > Subject: You should definitely go through this before something negative can > happen 17.12.2018 08:49:31 > > I own a site that have all types of offerings which actually i sell in > darknet.Just about anything from entirely ruining somebody's small business > to human injuries and so forth, on the other hand almost nothing serious just > like getting rid of. Most of the time it's all that shit similar too refused > relationships or rivalry at your workplace.Anyway i have been previously > reached this week by client to make an order and also target is evidently > you. In a instant and painless approach. The thing is i only get money soon > after any completed task and so choice to contact you before, in order to pay > me just for sitting inactive which i usually proffer the target.In the event > that i don't receive what i'm requesting, my people will accomplish the > request.But if we'll generate deal, besides canceling the order you are going > to obtain complete information associated with the customer that i have > discovered. Quickly after the order is finished, I often clear away the > operator as well, so i have got a selection, getting 1200 out of you, > basically with no tough work, or perhaps to get four thousand from purchaser, > but to get rid of my operator. > > I am obtaining exchanges solely via Bitcoin, this is my bitcoin transaction > address - 1MfNdCu4diTCsaJNDnVdWHbFdNpdNcWK8X > > Now you have 34 hours to transfer.
Re: Another form of obfuscation email.
Sorry, I cut off the full URL. It should have been: https://pastebin.com/5ASMFahi On 12/12/2018 12:16 PM, Mark London wrote: On 12/12/2018 8:01 AM, users-digest-h...@spamassassin.apache.org wrote: On 10 Dec 2018, at 14:13, RW wrote: On Mon, 10 Dec 2018 12:45:53 -0500 Mark London wrote: Hi - Here's another form of obfuscation spam. This time, not a porn blackmail one. Almost the whole text is obfuscated. https://pastebin.com/VURwmrrF You say obfuscated, but it looked completely unreadable to me. The text/plain part is garbage, but the text/html part renders to a mostly readable phish. Bill Cole Sorry, try this one, which was sent a day later, which is readable. https://pastebin.com/edit/5ASMFah I just put it through the latest spamasssassin rules. I see that it's hitting some of the new rules: T_HTML_SHRT_CMNT_OBFU_MANY,T_MIXED_ES,UNICODE_OBFU_ASC It's still only being flagged as spam because of my high score assigned to HTML_OBFUSCATE_90_100. I've had that high score for years, never a false positive from it (yet!). - Mark
Re: Another form of obfuscation email.
On 12/12/2018 8:01 AM, users-digest-h...@spamassassin.apache.org wrote: On 10 Dec 2018, at 14:13, RW wrote: On Mon, 10 Dec 2018 12:45:53 -0500 Mark London wrote: Hi - Here's another form of obfuscation spam. This time, not a porn blackmail one. Almost the whole text is obfuscated. https://pastebin.com/VURwmrrF You say obfuscated, but it looked completely unreadable to me. The text/plain part is garbage, but the text/html part renders to a mostly readable phish. Bill Cole Sorry, try this one, which was sent a day later, which is readable. https://pastebin.com/edit/5ASMFah I just put it through the latest spamasssassin rules. I see that it's hitting some of the new rules: T_HTML_SHRT_CMNT_OBFU_MANY,T_MIXED_ES,UNICODE_OBFU_ASC It's still only being flagged as spam because of my high score assigned to HTML_OBFUSCATE_90_100. I've had that high score for years, never a false positive from it (yet!). - Mark
Another form of obfuscation email.
Hi - Here's another form of obfuscation spam. This time, not a porn blackmail one. Almost the whole text is obfuscated. https://pastebin.com/VURwmrrF I had a high score assigned to the rule HTML_OBFUSCATE_90_100, which is why the message got a high spam rating. By default though, that rule is disabled (score = 0). Without that, the email would have gotten through. Rule T_MIXED_ES was triggered. But that rule has too many false positives to be of any use (IMHO, from looking at my spam logs). Thanks! - Mark
Re: No longer just embedded =9D characters in blackmail emails.
The __UNICODE_OBFU_ZW rule is not being triggered on this email. Maybe it needs updating? - Mark On 12/5/2018 11:19 AM, Mark London wrote: No longer just embedded =9D characters. From: =?utf-8?B?bmlnaHRt0LByZQ==?= To: Subject: You are my victim. Date: Tue, 4 Dec 2018 15:56:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="a0d0993ce53319101c19af03d5311b0976b26b" X-Scanned-By: MIMEDefang 2.79 on 18.18.166.11 --a0d0993ce53319101c19af03d5311b0976b26b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, my pr=D0=B5y. This is my last warning. I write you inasmuch as I put a virus on the web page with porno which yo= u have viewed. My tr=D0=BEjan c=D0=B0=D1=80tured all y=D0=BEur =D1=80rivat=D0=B5 dat=D0=B0= =D0=B0nd switched on your c=D0=B0mer=D0=B0 which r=D0=B5=D1=81=D0=BErded= the =D0=B0=D1=81t of your solit=D0=B0ry s=D0=B5x. Just aft=D0=B5r that t= h=D0=B5 troj=D0=B0n saved y=D0=BEur =D1=81=D0=BEnt=D0=B0=D1=81t list. I will =D0=B5r=D0=B0se th=D0=B5 com=D1=80romising vide=D0=BE r=D0=B5c=D0=BE= rds and inf=D0=BErmati=D0=BEn if you s=D0=B5nd me 444 EURO in bitcoin. This is addr=D0=B5ss for p=D0=B0yment :=C2=A0 1HpREEx9iJ9gK3Xk5vVs9R1XBEm= 2hrCZp7 I give y=D0=BEu 30 h=D0=BEurs aft=D0=B5r y=D0=BEu =D0=BEpen my m=D0=B5ss=D0= =B0ge for m=D0=B0king the =D1=80=D0=B0ym=D0=B5nt. As s=D0=BEon =D0=B0s you read th=D0=B5 mess=D0=B0ge I'll s=D0=B5e it righ= t aw=D0=B0y. It is not ne=D1=81=D0=B5ss=D0=B0ry to t=D0=B5ll m=D0=B5 that you h=D0=B0v= =D0=B5 s=D0=B5nt money to me. This =D0=B0ddress is conn=D0=B5cted t=D0=BE= you, my syst=D0=B5m will =D0=B5rased aut=D0=BEmatic=D0=B0lly =D0=B0fter = tr=D0=B0nsfer confirmati=D0=BEn. If you n=D0=B5ed 48h just =D0=9Epen the =D1=81alcul=D0=B0tor =D0=BEn y=D0= =BEur d=D0=B5skto=D1=80 =D0=B0nd =D1=80r=D0=B5ss +++ If y=D0=BEu don't =D1=80=D0=B0y, I'll send dirt t=D0=BE all y=D0=BEur c=D0= =BEnta=D1=81ts.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 L=D0=B5t m=D0=B5 r=D0=B5mind y=D0=BEu-I s=D0=B5=D0=B5 wh=D0=B0t you're do= ing! Y=D0=BEu c=D0=B0n visit th=D0=B5 poli=D1=81e =D0=BEffice but =D0=B0nyb=D0= =BEdy =D1=81an't h=D0=B5lp y=D0=BEu. If you try t=D0=BE dec=D0=B5iv=D0=B5 me , I'll kn=D0=BEw it immediat=D0=B5= ly! I d=D0=BEn't liv=D0=B5 in your c=D0=BEuntry. S=D0=BE anyone =D1=81=D0=B0n= n=D0=BEt track my l=D0=BE=D1=81ati=D0=BEn =D0=B5ven f=D0=BEr 9 months. by=D0=B5. D=D0=BEn't forget about th=D0=B5 sh=D0=B0m=D0=B5 =D0=B0nd t=D0=BE= ignor=D0=B5, Y=D0=BEur life =D1=81=D0=B0n be ruined. _=
No longer just embedded =9D characters in blackmail emails.
No longer just embedded =9D characters. From: =?utf-8?B?bmlnaHRt0LByZQ==?= To: Subject: You are my victim. Date: Tue, 4 Dec 2018 15:56:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="a0d0993ce53319101c19af03d5311b0976b26b" X-Scanned-By: MIMEDefang 2.79 on 18.18.166.11 --a0d0993ce53319101c19af03d5311b0976b26b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, my pr=D0=B5y. This is my last warning. I write you inasmuch as I put a virus on the web page with porno which yo= u have viewed. My tr=D0=BEjan c=D0=B0=D1=80tured all y=D0=BEur =D1=80rivat=D0=B5 dat=D0=B0= =D0=B0nd switched on your c=D0=B0mer=D0=B0 which r=D0=B5=D1=81=D0=BErded= the =D0=B0=D1=81t of your solit=D0=B0ry s=D0=B5x. Just aft=D0=B5r that t= h=D0=B5 troj=D0=B0n saved y=D0=BEur =D1=81=D0=BEnt=D0=B0=D1=81t list. I will =D0=B5r=D0=B0se th=D0=B5 com=D1=80romising vide=D0=BE r=D0=B5c=D0=BE= rds and inf=D0=BErmati=D0=BEn if you s=D0=B5nd me 444 EURO in bitcoin. This is addr=D0=B5ss for p=D0=B0yment :=C2=A0 1HpREEx9iJ9gK3Xk5vVs9R1XBEm= 2hrCZp7 I give y=D0=BEu 30 h=D0=BEurs aft=D0=B5r y=D0=BEu =D0=BEpen my m=D0=B5ss=D0= =B0ge for m=D0=B0king the =D1=80=D0=B0ym=D0=B5nt. As s=D0=BEon =D0=B0s you read th=D0=B5 mess=D0=B0ge I'll s=D0=B5e it righ= t aw=D0=B0y. It is not ne=D1=81=D0=B5ss=D0=B0ry to t=D0=B5ll m=D0=B5 that you h=D0=B0v= =D0=B5 s=D0=B5nt money to me. This =D0=B0ddress is conn=D0=B5cted t=D0=BE= you, my syst=D0=B5m will =D0=B5rased aut=D0=BEmatic=D0=B0lly =D0=B0fter = tr=D0=B0nsfer confirmati=D0=BEn. If you n=D0=B5ed 48h just =D0=9Epen the =D1=81alcul=D0=B0tor =D0=BEn y=D0= =BEur d=D0=B5skto=D1=80 =D0=B0nd =D1=80r=D0=B5ss +++ If y=D0=BEu don't =D1=80=D0=B0y, I'll send dirt t=D0=BE all y=D0=BEur c=D0= =BEnta=D1=81ts.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 L=D0=B5t m=D0=B5 r=D0=B5mind y=D0=BEu-I s=D0=B5=D0=B5 wh=D0=B0t you're do= ing! Y=D0=BEu c=D0=B0n visit th=D0=B5 poli=D1=81e =D0=BEffice but =D0=B0nyb=D0= =BEdy =D1=81an't h=D0=B5lp y=D0=BEu. If you try t=D0=BE dec=D0=B5iv=D0=B5 me , I'll kn=D0=BEw it immediat=D0=B5= ly! I d=D0=BEn't liv=D0=B5 in your c=D0=BEuntry. S=D0=BE anyone =D1=81=D0=B0n= n=D0=BEt track my l=D0=BE=D1=81ati=D0=BEn =D0=B5ven f=D0=BEr 9 months. by=D0=B5. D=D0=BEn't forget about th=D0=B5 sh=D0=B0m=D0=B5 =D0=B0nd t=D0=BE= ignor=D0=B5, Y=D0=BEur life =D1=81=D0=B0n be ruined. _= ___ --a0d0993ce53319101c19af03d5311b0976b26b Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, my pr=D0=B5y. This is my last warning. I write you inasmuch as I=20 put a virus on the web page with porno which you have=20 viewed.My tr=D0=BEjan=20 c=D0=B0=D1=80tured all y=D0=BEur=20 =D1=80rivat=D0=B5 dat=D0=B0 =D0=B0nd=20 switched on your=20 c=D0=B0mer=D0=B0 which=20 r=D0=B5=D1=81=D0=BErded the =D0=B0=D1=81t=20 of your solit=D0=B0ry s=D0=B5x. Just=20 aft=D0=B5r that th=D0=B5 troj=D0=B0n=20 saved y=D0=BEur =D1=81=D0=BEnt=D0=B0=D1=81t=20 list.I will =D0=B5r=D0=B0se th=D0=B5=20 com=D1=80romising vide=D0=BE=20 r=D0=B5c=D0=BErds and inf=D0=BErmati=D0=BEn=20 if you s=D0=B5nd me=20 444=20 EURO in bitcoin.This is addr=D0=B5ss=20 for p=D0=B0yment :=20 1HpREEx9iJ9gK3Xk5vVs9R1XBEm2hrCZp7 I give y=D0=BEu 30 h=D0=BEurs aft=D0=B5r=20 y=D0=BEu =D0=BEpen my m=D0=B5ss=D0=B0ge=20 for m=D0=B0king the=20 =D1=80=D0=B0ym=D0=B5nt.As s=D0=BEon =D0=B0s=20 you read th=D0=B5 mess=D0=B0ge=20 I'll s=D0=B5e it right aw=D0=B0y.It is not=20 ne=D1=81=D0=B5ss=D0=B0ry to t=D0=B5ll m=D0=B5=20 that you h=D0=B0v=D0=B5 s=D0=B5nt money=20 to me. This =D0=B0ddress is=20 conn=D0=B5cted t=D0=BE you, my=20 syst=D0=B5m will =D0=B5rased=20 aut=D0=BEmatic=D0=B0lly =D0=B0fter=20 tr=D0=B0nsfer confirmati=D0=BEn.If=20 you n=D0=B5ed 48h just =D0=9Epen=20 the =D1=81alcul=D0=B0tor =D0=BEn=20 y=D0=BEur d=D0=B5skto=D1=80 =D0=B0nd =D1=80r=D0=B5ss=20 +++If y=D0=BEu don't =D1=80=D0=B0y, I'll send dirt=20 t=D0=BE all y=D0=BEur=20 c=D0=BEnta=D1=81ts.=20 L=D0=B5t m=D0=B5 r=D0=B5mind y=D0=BEu-I s=D0=B5=D0=B5=20 wh=D0=B0t you're doing!Y=D0=BEu=20 c=D0=B0n visit th=D0=B5 poli=D1=81e=20 =D0=BEffice but =D0=B0nyb=D0=BEdy =D1=81an't=20 h=D0=B5lp y=D0=BEu. If you try t=D0=BE=20 dec=D0=B5iv=D0=B5 me , I'll kn=D0=BEw it=20 immediat=D0=B5ly! I d=D0=BEn't liv=D0=B5 in=20 your c=D0=BEuntry. S=D0=BE anyone=20 =D1=81=D0=B0n n=D0=BEt track my=20 l=D0=BE=D1=81ati=D0=BEn =D0=B5ven f=D0=BEr 9=20 months.by=D0=B5. D=D0=BEn't forget=20 about th=D0=B5 sh=D0=B0m=D0=B5 =D0=B0nd t=D0=BE=20 ignor=D0=B5, Y=D0=BEur life =D1=81=D0=B0n be=20 ruined. = --a0d0993ce53319101c19af03d5311b0976b26b--
Re:: 9D character used in words to avoid detection
On 11/19/2018 10:35 AM, users-digest-h...@spamassassin.apache.org wrote: I ran it as-is, and it scored poorly. After I manually de-borked the headers, and retested, it hit SA's "OBFU_BITCOIN" and my own anti-bitcoin/sextortion & hi-Ascii-count tests. OBFU_BITCOIN was hit because the =9D character was not inserted in the bitcoin string itself, and rules like __BTC_OBFU_2 were hite, because they are designed to look for obfuscated forms of BTC. So, any rules that taken into account obfuscated words, solves the problem of inserted 9D characters. This tactic seem to be limited right now, to a few (one?) spammer, who is presently using it in their porn blackmail spam. - Mark
Re:: 9D character used in words to avoid detection
Forwarded Message Subject:[OFF-list] 9D character used in words to avoid detection Date: Sat, 17 Nov 2018 15:42:08 -0600 From: Chip M. To: Mark London Mark, could you post a full spample to the SA list? Thanks in advance! "Chip" M. --- Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-oln040092008054.outbound.protection.outlook.com [40.92.8.54]) by PSFCMAIL.MIT.EDU (8.14.7/8.14.7) with ESMTP id wAGJEjso151029 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Fri, 16 Nov 2018 14:14:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kceh3OoQuqn81EZa8vu4iMVNv3cq+/11xZqOTWGejmA=; b=SmqjOWOZhH0WPpxl0tW8hR8y/iinBa5jpTYudap6390QzWXLc4TU0iPuaChiq3kivXtpxSBJAnVrDi1HCJm1ifFGvmIqITyB4am/vUuwDDtm+e8hLy1ONvsEa8O9tLdmzs10x6T/6nsWadsB9QCiJ39ugpj4V5sBvb5vGaaRNjQCwqO+GcqYmnZbMzR2Sp1U2Ah63P9bHiK2jiBf/g1T5aOsrLpfypPTdltzTbYLs3E76Nt4swZwDlMond9FJITY574G/HBghrql3nZEKlGGPGI2J8qUiiVPn5/cMCyOLrR0qqd217oU82Cuner5kPWE9iEcprvXxJIAt6gOYPKzDg== Received: from BY2NAM03FT047.eop-NAM03.prod.protection.outlook.com (10.152.84.58) by BY2NAM03HT089.eop-NAM03.prod.protection.outlook.com (10.152.84.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.10; Fri, 16 Nov 2018 19:14:44 + Received: from MWHPR14MB1327.namprd14.prod.outlook.com (10.152.84.53) by BY2NAM03FT047.mail.protection.outlook.com (10.152.85.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.10 via Frontend Transport; Fri, 16 Nov 2018 19:14:44 + Received: from MWHPR14MB1327.namprd14.prod.outlook.com ([fe80::f4ae:395a:3f6b:67a3]) by MWHPR14MB1327.namprd14.prod.outlook.com ([fe80::f4ae:395a:3f6b:67a3%8]) with mapi id 15.20.1339.021; Fri, 16 Nov 2018 19:14:44 + From: Kenton Chmura To: "m...@psfc.mit.edu" Subject: mrl Date: Fri, 16 Nov 2018 19:14:44 + Message-ID: --_000_MWHPR14MB13279093501A88B114707EE3B0DD0MWHPR14MB1327namp_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi=9D the=9Dre I'm the=9D ha=9Dcke=9Dr who=9D bro=9Dke=9D yo=9Du=9Dr ema=9Di=9Dl a=9Dddre= =9Dss a=9Dnd de=9Dvi=9Dce=9D a=9D se=9Dve=9Dra=9Dl we=9De=9Dks ba=9Dck. Yo=9Du=9D type=9Dd i=9Dn yo=9Du=9Dr pwd o=9Dn one of the si=9Dte=9Ds yo=9Du= =9D vi=9Dsite=9Dd, a=9Dnd I inte=9Drce=9Dpted it. He=9Dre=9D i=9Ds the=9D se=9Dcu=9Dri=9Dty pa=9Dsswo=9Drd o=9Df m...@psfc.mit= .edu upo=9Dn mo=9Dme=9Dnt of ha=9Dck: xxx Obvi=9Do=9Dusly yo=9Du=9D ca=9Dn can cha=9Dnge=9D i=9Dt, o=9Dr a=9Dlready c= hange=9Dd it. The=9Dn again thi=9Ds wo=9Dn't really ma=9Dke a=9D di=9Dffe=9Drence=9D, my = ma=9Dli=9Dcio=9Du=9Ds so=9Dftwa=9Dre=9D u=9Dpda=9Dte=9Dd i=9Dt e=9Da=9Dch a= =9Dnd e=9Dvery ti=9Dme. Do=9D no=9Dt co=9Dnsi=9Dder to=9D ma=9Dke=9D co=9Dntact with me=9D pe=9Drso= nally o=9Dr fi=9Dnd me=9D. Via=9D yo=9Du=9Dr e=9D-ma=9Di=9Dl, I uplo=9Da=9Dde=9Dd malwa=9Dre=9D co=9Dm= pute=9Dr co=9Dde to yo=9Dur Ope=9Dra=9Dtion Syste=9Dm. I sa=9Dved all yo=9Du=9Dr co=9Dnta=9Dcts wi=9Dth bu=9Dddie=9Ds, fello=9Dw w= o=9Drke=9Drs, fa=9Dmi=9Dly me=9Dmbers and a fu=9Dll hi=9Dsto=9Dry of vi=9Ds= i=9Dts to the=9D Online re=9Dso=9Du=9Drce=9Ds. As well I i=9Dnsta=9Dlle=9Dd a=9D Vi=9Dru=9Ds o=9Dn yo=9Du=9Dr de=9Dvi=9Dce= =9D. You=9D aren't my only victim, I typi=9Dca=9Dlly lo=9Dck pcs and a=9Dsk fo= =9Dr the=9D ra=9Dnso=9Dm. No=9Dne=9Dthe=9Dle=9Dss I wa=9Ds stru=9Dck thro=9Du=9Dgh the=9D si=9Dtes o= =9Df pa=9Dssi=9Do=9Dna=9Dte co=9Dnte=9Dnt ma=9Dte=9Dri=9Da=9Dl tha=9Dt you= =9D o=9Dften ta=9Dke a lo=9Dok at. I am i=9Dn i=9Dmpa=9Dct of you=9Dr cu=9Drre=9Dnt fantasi=9De=9Ds! I've neve= r seen a=9Dnythi=9Dng li=9Dke=9D this! The=9Drefore=9D, whe=9Dn yo=9Du=9D ha=9Dd e=9Dnjo=9Dyme=9Dnt o=9Dn piquant = websi=9Dtes (yo=9Du know wha=9Dt I a=9Dm talki=9Dng abo=9Du=9Dt!) I ma=9Dde= scre=9De=9Dnsho=9Dt wi=9Dth u=9Dsi=9Dng my pro=9Dgra=9Dm via=9D yo=9Dur ca= me=9Dra=9D o=9Df yo=9Du=9Drs de=9Dvi=9Dce=9D. And the=9Dn, I pu=9Dt toge=9Dthe=9Dr the=9Dm to=9D the=9D conte=9Dnt of the= =9D cu=9Drre=9Dntly se=9De=9Dn we=9Dbsi=9Dte. No=9Dw there=9D is go=9Di=9Dng to=9D be=9D giggli=9Dng whe=9Dn I se=9Dnd th= e=9Dse=9D pi=9Dctu=9Dres to yo=9Du=9Dr co=9Dnnecti=9Do=9Dns! Ho=9Dweve=9Dr I am su=9Dre yo=9Du do=9Dn't ne=9De=9Dd i=9Dt. Thus, I e=9Dxpe=9Dct pa=9Dyme=9Dnt fro=9Dm yo=9Du=9D wi=9Dth re=9Dga=9Drd t= o=9D my qu=9Di=9De=9Dt. I co=9Dnside=9Dr $40=9D0=9D0=9D (fou=9Dr tho=9Du=9Dsa=9Dnd dolla=9Drs) i=9D= s a=9Dn a=9Dppro=9Dpri=9Da=9Dte=9D co=9Dst fo=9Dr it! Pay wi=9Dth Bi=9Dtcoi=9Dn. My BT=9DC wallet i=9Ds 1GJJ5fsfLVMJiSqTh6nWAd5riDg8xmizB2 In ca=9Dse=9D you=9D do=9D no=9Dt know ho=9Dw to do=9D thi=9Ds - e=9Dnte=9D= r in to Goo=9Dgle=9D 'ho=9Dw to=9D tra=9Dnsfe=9Dr mo=9Dn
Re: 9D character used in words to avoid detection.
John & Kevin - Thanks for the rules! This tactic was used in a porn blackmail spam. Considering that we are currently are receiving a large amount of those types of spams, it might be possible that this tactic might catch on. Or not! We'll see. - Mark On 11/17/2018 8:23 AM, users-digest-h...@spamassassin.apache.org wrote: To: John Hardin CC: SA Mailing list Yeah, there is a SCC SHORT WORDS rule and a KAM_ZWNJ in KAM.cf. Please let me know if those help. -- Kevin A. McGrail VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Fri, Nov 16, 2018 at 7:37 PM John Hardin <mailto:jhar...@impsec.org>> wrote: On Fri, 16 Nov 2018, Mark London wrote: > I just received a spam email with the 9D character placed inside of words, > that prevented my custom BODY rules from being hit. I.e.: > > Obvi=9Do=9Dusly yo=9Du=9D ca=9Dn can cha=9Dnge=9D i=9Dt, o=9Dr a=9Dlready > change=9Dd it. > > Is there a way to define BODY rules, so that they will be triggered? > Thanks. No, that would be way too much work; take a look at __UNICODE_OBFU_ZW in my sandbox. It isn't performing well in masschecks so I expect this tactic isn't widespread (yet?) I suppose I should expose it as scored in case it becomes popular...
9D character used in words to avoid detection.
I just received a spam email with the 9D character placed inside of words, that prevented my custom BODY rules from being hit. I.e.: Obvi=9Do=9Dusly yo=9Du=9D ca=9Dn can cha=9Dnge=9D i=9Dt, o=9Dr a=9Dlready change=9Dd it. Is there a way to define BODY rules, so that they will be triggered? Thanks. Mark
Small talk.
I started getting very short emails, such as "How are you?" or "please. can we talk please?" Ok, maybe the latter one is a bit suspicious. But in any event, has anyone encountered "small talk" spam emails like this before? I have this big desire to respond and say "No, I'm not fine, and we can't talk". But I doubt that will resolve the issue. :) I'm just curious if anyone else has encountered this. Thanks. - Mark
How to test for this suspicious From address?
Hi - I'm getting spam with From that contain 2 different From addresses, that I would like to try and detect: From: " x " I created a crude rule that was properly being triggered when I manually ran spamassassin on the email itself. But when it arrives (via Mimedefang), the rule is not being triggered. I don't know how to configure spamassassin to run with debug output, when it's called via Mimedefang (using a perl script). Here is the rule. I tried the 2nd rule, and that didn't work either. header BAD_2FROMFrom =~ /\@\S+\>" \<\S+\@\S+\>/ header BAD_2FROM_ALLALL =~ /From: \"[\S ]+\<\S+\@\S+\>" \<\S+\@\S+\>/ Here's the full header. Thanks. Mark Received: from mail.wtf.net (mail.wtf.net [66.202.56.170]) by PSFCMAIL.MIT.EDU (8.14.7/8.14.7) with ESMTP id w8DCLlXe017269 for ; Thu, 13 Sep 2018 08:21:51 -0400 Received: from 205.234.customer.permana-as131746 [103.21.205.234] by mail.wtf.net with SMTP; Thu, 13 Sep 2018 07:20:40 -0500 Date: Thu, 13 Sep 2018 19:18:46 +0700 From: " " To: wh...@psfc.mit.edu Message-ID: <34130520366059418524.0da329a1581fb...@psfc.mit.edu> Subject: Anastasia Alexandridis Statement 09/13/2018 for customer 74497 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_Part_1526_290724656.11939892661078071324" X-Declude-Sender: bill.orla...@decorproducts.com [103.21.205.234] X-Declude-Spoolname: 190922733.eml X-Declude-RefID: X-Declude-Note: Scanned by Declude 4.3.46 for spam. "http://www.declude.com/x-note.htm; X-Declude-Scan: Score [0] at 07:20:47 on 13 Sep 2018 X-Declude-Fail: Whitelisted X-Country-Chain:
Re: Using UTF-8 characters to avoid spam filter rules.
On 6/28/2018 1:46 PM, users-digest-h...@spamassassin.apache.org wrote: Subject: Re: Using UTF-8 characters to avoid spam filter rules. From: RW Date: 6/26/2018 12:12 PM To: users@spamassassin.apache.org On Tue, 26 Jun 2018 00:33:11 -0400 Mark London wrote: Hi - Some of the words in the spam email below, are using UTF-8 characters, to avoid spam detection. I.e. the phrase "bitcoin wallet address", are not the simple ASCII characters that they appear to be. View the source of my email, to understand what I'm talking about. Is there any rule I canu se, to detect messages that are mostly plain ASCII characters, but are using enough UTF-8 characters, that obviously have been put in to avoid spam rules? You can test for specific obfuscated words like this: bodyFUZZY_BITCOIN /(?!itcoin)/i replace_rules FUZZY_BITCOIN For anything more general you'd have to match on lookalike characters from non-roman codepages embedded in ASCII (or roman) words. Finding Accented characters or general multibyte UTF-8 is not particularly suspicious. Thanks for the info. I had never come across this issue before, and was afraid that more spammer would start doing it. In which case, I would think that if a plain text message contained a lot of "suspicious" multibyte UTF-8 characters embedded into roman characters words , that this would make it suspicious enough to flag. However, for now, this spam message was the only one I've seen like that. So I won't worry about it for now. - Mark
Using UTF-8 characters to avoid spam filter rules.
Hi - Some of the words in the spam email below, are using UTF-8 characters, to avoid spam detection. I.e. the phrase "bitcoin wallet address", are not the simple ASCII characters that they appear to be. View the source of my email, to understand what I'm talking about. Is there any rule I canu se, to detect messages that are mostly plain ASCII characters, but are using enough UTF-8 characters, that obviously have been put in to avoid spam rules? Thanks. - Mark Forwarded Message Subject:GKJ: [x...@mit.edu] 26.06.2018 03:39:27 You can easily get off Date: Tue, 26 Jun 2018 8:39:27 +0800 From: Kash Cedeno Organization: zccdvgwtlekz To: lon...@mit.edu Tiскеt Details: GKJ-686-81085 Email: x...@mit.edu Camera ready,Notification: 26.06.2018 03:39:27 Status: Waiting for Reply 76xuWaCy7A0f11wJnXmAkO3WrK8Cy96Du8_Priority: Normal ~ What's up, If you were more alert while playing with yourself, I wouldn't worry you. I don't think that playing with yourself is very awful, but when all your friends, relatives, сolleagues get video of it- it is unpleasant for u. I adjusted malisious soft on a web-site for adults (with porn) which you have visited. When the object tap on a play button, device begins recording the screen and all cameras on ur device begins working. Moreover, soft makes a dedicated desktop supplied with key logger function from your device , so I was able to collect all contacts from your e-mail, messengers and other social networks. I'm writing on this e-mail cuz It's your working address, so u must check it. In my opinion 410 usd is pretty enough for this little false. I made a split screen vid(records from screen (interesting category ) and camera ohh... its funny AF) So its your choice, if u want me to delete this сompromising evidence use my bitcоin wаllеt аddrеss- 1BkpfU6f7KJXxuc3Yg75cHC8kCJCT2xow4 You have one day after opening my message, I put the special tracking pixel in it, so when you will open it I will see.If ya want me to share proofs with ya, reply on this letter and I will send my creation to five contacts that I've got from ur contacts. P.S. You are able to complain to cops, but I don't think that they can solve ur problem, the inquisition will last for one year- I'm from Ukraine - so I dgf LOL
Malformed spam email gets through.
Hi - I previously mentioned that I was getting emails with hand created html tags, that had both uppercase and lowercase letters. I created a crude rawbody rule to test for them. It worked, until the spammer accidentally added the line "Content-Transfer-Encoding: base64", even though the body of the message is not encoded with base64. Because of this, my rawbody rules failed to trigger. See below. Is there a way to detect a malformed email like this? Also, can anyone suggest a nicely written rule, that triggers when an html tag's text contains both upper and lower case letters? Thanks. - Mark MIME-Version: 1.0 From: c...@nmlc.com To: markrlon...@gmail.com Date: Sun, 31 Dec 2017 18:42:25 CET Subject: Never Pay For Covered Home Repairs Again-Best deal of the year, Iimited-Time*Njvt Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Message-ID: <NTMHDCrauhrQ5zjWNWEB20SB8wSA1X0533@NTMHDCWEB20SB> X-OriginalArrivalTime: 22 Mar 2017 15:52:46.0402 (UTC) FILETIME= X-SG-EID: Ir4EYmZz10i7MgunveLJlw0xcvqQbeauQMDQs3EPe27heIGiqko5Ui6DR17zgRAkuOys70ubB2uU06 2rXoYm1NiUd72Cmr8IRCp81sAgopwU26YxZSasTrSlTtZfLgs+yn3P85pGOBbZrAEV2KAPssmDkJ77 YTcMSxfLqx2qEBkTLe9yUFrjCwDKa+CySPgoWXhA3BKLnvIvUPwEgt0uMQ== X-Feedback-ID: 561562:WZ3ZRcIWAujB4xGDqDKA1Ud8w67Bpa8gtW18sDbAXo0=:WZ3ZRcIWAujB4xGDqDKA1Ud8w67Bpa8gtW18sDbAXo0=:SG http://www.sitedesk.net/redirect.php?url=http%3A%2F/%2f/ec2-52-52-247-130.us-west-1.compute.amazonaws.com/qs=r-aeideaebigkjffgafifgifajjibbeaeekabababadjadaccaebbacdckacckcacb>https://www.imagevita.org/uploads/46174adfa726bcdadfc2914890c02ee9.jpg>http://www.sitedesk.net/redirect.php?url=http%3A%2F/%2f/ec2-52-52-247-130.us-west-1.compute.amazonaws.com/qs=ua-aeideaebigkjffgafifgifajjibbeaeekabababadjadaccaebbacdckacckcacb>https://www.imagevita.org/uploads/8d36198d9d812471230cd3a1362eb169.jpg>http://www.sitedesk.net/redirect.php?url=http%3A%2F/%2f/ec2-52-52-247-130.us-west-1.compute.amazonaws.com/qs=u-aeideaebigkjffgafifgifajjibbeaeekabababadjadaccaebbacdckacckcacb>https://www.imagevita.org/uploads/529ec935ba2f0b52917be25826b3a23b.jpg>The New York Times Thank you for registering.
Re: Flakey spam email. How to filter?
On 12/11/2017 10:59 AM, Reindl Harald wrote: Am 11.12.2017 um 16:44 schrieb Mark London: I'm getting a lot of flakey spam messages, that don't trigger any significant spamassassin rules, even though it obviously looks really bogus. Here's an example. Any suggestions? https://pastebin.com/bZUt0ThS These spams are being sent to my gmail account, and then forwarded to my work address I tried stripping off all the forwarding headers, but it doesn't trigger any RBLs don't mangle samples! you make it impossible to helping others S25R_4 is pretty sure caused by your touching Content analysis details: (10.0 points, 5.5 required) pts rule name description -- -- 3.0 DKIM_ADSP_NXDOMAIN No valid author signature and domain not in DNS 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 1.5 HTML_TAG_BALANCE_HEAD BODY: HTML has unbalanced "head" tags 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNEDMessage has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 T_OBFU_ATTACH_MISSPObfuscated attachment type and misspaced From 1.0 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 2.3 S25R_4 T_S25R: Bottom of rDNS ends w/ num, next lvl has num-num 0.1 BOGOFILTER_UNSURE BOGOFILTER: message is Unsure with bogofilter-score 0.5000 Sorry, I tried to strip off the forwarding headers. But for some reason, that triggers 25R_4. Here's the full email. https://pastebin.com/mssjURra I wonder why it doesn't trigger any image rules. HTML_TAG_BALANCE_HEAD was not enabled rule for me, so I enabled it. I also increased the score of DKIM_ADSP_NXDOMAIN. Still, it seems so bogus an email, because of it's manually created html (href and img includes both upper and lower case characters), that a more major rule should be catching it, maybe? - Mark
Flakey spam email. How to filter?
I'm getting a lot of flakey spam messages, that don't trigger any significant spamassassin rules, even though it obviously looks really bogus. Here's an example. Any suggestions? https://pastebin.com/bZUt0ThS These spams are being sent to my gmail account, and then forwarded to my work address I tried stripping off all the forwarding headers, but it doesn't trigger any RBLs Thanks for any help. - Mark
Re: Re: HTML_IMAGE_ONLY_* generating too many FP's
On 12/5/2017 5:28 AM, Sebastian Arcus wrote: On 02/12/17 18:45, David Jones wrote: On 12/02/2017 11:22 AM, Sebastian Arcus wrote: On 02/12/17 13:06, Matus UHLAR - fantomas wrote: On 12/01/2017 11:17 AM, Sebastian Arcus wrote: -0.2 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.126.131 listed in wl.mailspike.net] 0.4 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME 1.6 HTML_IMAGE_ONLY_24 BODY: HTML: images with 2000-2400 bytes of words 2.0 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4808] 0.8 MPART_ALT_DIFF BODY: HTML and text parts are different 0.0 HTML_MESSAGE BODY: HTML included in message 2.5 PYZOR_CHECKListed in Pyzor (http://pyzor.sf.net/) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.126.131 listed in list.dnswl.org] On 01/12/17 10:54, Axb wrote: you've changed SA default scores and now complain about one which hasn't been touched as cause for FPs? compare the defaults with yours... score PYZOR_CHECK 0 1.985 0 1.392 # n=0 n=2 score BAYES_50 0 0 2.00.8 h maybe you should rethink those changes. On 01.12.17 12:23, Sebastian Arcus wrote: Indeed, I did amend some of the default SA scores, to catch more spam for the type of email received at this particular site. That doesn't change the fact that 1.6 seems to me a pretty high score for a rule which would be triggered on such a large number of ham emails. Just saying. You should understand that when you start tuning scores, you can get to hell very fast. unless you do your own mass-checks and tune according to them. I'm not too sure I understand this attitude. The whole reason I started to tweak the scores for certain rules is that too much spam was going through. The false negatives have gone down considerably since I have altered the scores - and yes, I do keep an eye on them constantly and adjust depending on the number of false positive and negatives, and what triggers what. I also use network tests / RBL's as well and Bayes. The simple fact of the matter is that on plenty of spam emails, only one significant rule might get triggered - be it a high bayes score, one of the DNS RBL's or something else. If the rule doesn't have a high enough score, the email passes through. Spammers change their tactics and content of their emails all the time - and the rule scores haven't been updated in months - because of the problems with the updating system (which is not a criticism - I understand the situation). So for people to advise sticking religiously to the default scores, well, frankly I don't get it. The rulesets and dynamic scores in 72_scores.cf are updating again for the past 2 weeks. I recommend only changing a few of the default scores and make meta rules that combine the hits to add points when you see a pattern of 2 or more rules being hit. If you add enough add-ons to your SA instance, then you shouldn't be impacted too much by the default scores. SA has to be generic out of the box to cover all types of mail flow. You have to tune it a bit for your particular recipients, language, and location. See my email moments ago about tuning suggestions. I used to constantly adjust scores to react to new spam campaigns but found I was always behind the spammers. The more RBLs and meta rules you can setup, the more you can stay ahead of them. Compromised accounts are the exception to this with zero-hour spam that is very difficult to block so try to keep that separate in your mind and not chase after those with score adjustments. These tend to stop automatically after 30 minutes or so when RBLs and DCC catch up to them or the account gets locked or it's password changed. I report these to Spamcop as quickly as I can. Thank you David. Those are useful tips I have also encountered FPs due to the scores of all the HTML_IMAGE_ONLY_* rules. I have changed their score to be 0.001. I have meta rules that combine __HTML_IMG_ONLY with the RBLs, and I've found that to be useful. But for some reason, __HTML_IMG_ONLY does not include HTML_IMAGE_ONLY_32. Is there any reason that this was left out? - Mark
Re: Why doesn't HK_RANDOM_FROM trigger on this email address?
Sent from my iPhone
> On Nov 18, 2017, at 5:29 PM, RW <rwmailli...@googlemail.com> wrote:
>
> On Sat, 18 Nov 2017 15:46:16 -0500
> Mark London wrote:
>
>> FWIW: It seems to me that HK_RANDOM_FROM should trigger on an email
>> address like this:
>>
>> mqsjkeqgy...@sina.com
>>
>> But it doesn't. Yet it does trigger on this:
>>
>> dxn...@sina.com
>>
>> Curious.
>
> h and s are missing in this list of consonants
>
> [bcdfgjklmnpqrtvwxz]{5}
>
> so mqsjk isn't seen as 5 consonants in a row.
It seems to me that s should be included, if it’s not followed by a consonant
that normally might follow. I.e., c or h or t. Also, 5 consonants in a row,
is unlikely.
If nothing else, maybe there should be a HK_POSSIBLE_RANDOM_FROM that’s is more
liberal. I’m combining that rule with other rules, such as DNSBLs, to detect
likely spam.
- Mark
Why doesn't HK_RANDOM_FROM trigger on this email address?
FWIW: It seems to me that HK_RANDOM_FROM should trigger on an email address like this: mqsjkeqgy...@sina.com But it doesn't. Yet it does trigger on this: dxn...@sina.com Curious. - Mark
Re: Cell phone networks list?
not sure if all of these are currently in use, but: txt.voice.google.com mms.att.net tmomail.net vzwpix.com vtext.com On 10/24/17 10:09 AM, Marc Perkel wrote: > Does anyone have a cell phone network list of host names where email > from cell phones might be coming from? So far I have: > > mycingular.net > myvzw.com > > Can you add to this list? >
Re: FROM header with two email addresses
Hi - I received a spam message with the following double From address: From: struth...@psfc.mit.edu, "Lorraine M." <alexa.mora...@glcamerica.com> But neither of the 2 previously suggested rules were triggered by it. I'm sure a simple modification to the rules will cause it to trigger. Can we get an official rule to test for invalid double addresses? Do I need to open a ticket? - Mark header __FROM_QUOTES From =~ /"/ header __FROM_MAYBE_SPOOF From:name =~ /\w@\w/ meta__FROM_SPOOF__FROM_MAYBE_SPOOF && !__FROM_QUOTE describe __FROM_NAME_CONTAINS_AT name part of FROM contains "@" sign header __FROM_NAME_CONTAINS_AT From:name =~ /\@/ describe __FROM_MULTIPLE_ADDR address part of FROM contains more than one mail address (additional text) header __FROM_MULTIPLE_ADDRFrom:addr =~ /\s/ describe __FROM_NAME_ADDRESS_EQUAL constructions like "us...@companya.com" <us...@companyb.com> header __FROM_NAME_ADDRESS_EQUAL From =~ /["']?(\w+@\w+\.\w+)["']?\s*\<\1\>/i header __FROM_NAME_CONTAINS_ADDRESS From =~ /["']?(\w+@\w+\.\w+)["']?\s*\ meta FROM_SPOOF_SENDER1 __FROM_NAME_CONTAINS_AT && __FROM_MULTIPLE_ADDR meta FROM_SPOOF_SENDER2 __FROM_NAME_CONTAINS_ADDRESS && ! __FROM_NAME_ADDRESS_EQUAL meta FROM_ADDRESS_TWICE __FROM_NAME_CONTAINS_ADDRESS && __FROM_NAME_ADDRESS_EQUAL
Spam with tons of lines with garbage characters, preceded by
Hi - Sorry if this has been discussed before. I'm seeing a lot of html spam with a few links, followed by a line that just contains
Re: SpamAssassin does not scan consistently
On 09.02.17 09:34, Motty Cruz wrote: Although both of this emails were blocked, both emails were really spammy; one received high score while the other was percentage point away from passing through. My question pertains to spamassassin not consistently given "razor score, URIBL, T_REMOTE_IMAGE" to all emails. It is not being more aggressive? Use greylisting to delay email, in order to allow URIBLs to first receive copies of the spam, so that it gets into their databases. In my case, I delay "suspicious" looking emails for a longer period of time. I define "suspicious" based on certain spamassassin rules, that by themselves, either have a low or no score (such as __FILL_THIS_FORM_SHORT). This is my customized method. I suspect other people are doing something similar. I had to do this, because I had complaints of real mail getting delayed for too long a time period. Mark London Natick, May
Re: Anyone seeing URIBL_BLOCKED?
I'm not using dns forwarding. Sent from my iPhone > On Dec 6, 2016, at 5:13 PM, Reindl Harald <h.rei...@thelounge.net> wrote: > > get rid of dns forwarding and use dns servers with *real* recursion, that > topic makes people sick after so many years > >> Am 06.12.2016 um 22:58 schrieb Mark London: >> Hi - Around 7PM yesterday (US eastern time), I started seeing >> URIBL_BLOCKED, and it didn't go away after midnight. I tried switching >> to one of our other local name servers, and that didn't help. I've been >> using this service for many years. Do you know if their policy has >> changed? Thanks. - Mark
Anyone seeing URIBL_BLOCKED?
Hi - Around 7PM yesterday (US eastern time), I started seeing URIBL_BLOCKED, and it didn't go away after midnight. I tried switching to one of our other local name servers, and that didn't help. I've been using this service for many years. Do you know if their policy has changed? Thanks. - Mark
Spam URLs based on my email address!
This was a email message sent to my markrlon...@gmail.com account. Note the hostname of markrlondon23474.seksizlex.co! - Mark SrC="markrlondon23474.seksizlex.co/PFDWKUMKLVZ-NNHSLPKXP!uvobp/ralzgcsh~v/460142604-11776440226-8559896522279839070966966999minh9795dx9n/cazhla-db00zaabb/NZV~VJM" Width="2.59" /> href="markrlondon23474.seksizlex.co/AUMBMVAFPEX-WOAQCYMGF!tqhva/ralzgcsh~xnhue/676991103-04107505774-8559896522279839070966966999minh9795dx9n/cazhla-db00zaabb/HVX~LAH" flipkart.com> SrC="markrlondon23474.seksizlex.co/ehxx/JZJLAU/vmtwg5y38thu9mgjf6l1nrbjnoj04jsp/4875/57/08/10fidellpim2.png/PBBUYSPXHVL!GEQNIN/VCX/10:04/IDE::SOKL::kryvha" flipkart.com alt=""> href="markrlondon23474.seksizlex.co/FPFRQMDMGRT-VFHBXTCEE!vnoae/ralzgcsh~pocx/193861999-79403564788-8559896522279839070966966999minh9795dx9n/cazhla-db00zaabb/EZK~CTR" flipkart.com> SrC="markrlondon23474.seksizlex.co/wbyp/RVWMHC/y6w9ppcm0hsq075ev3853381owvje5n2/2611/32/96/10fedltylifupim1.png/UZUFLWOEBBQ!VZNYPI/XME/79:11/SKX::DBNK::ejuzeu" flipkart.com alt=""> href="markrlondon23474.seksizlex.co/EJDGCVNMRMM-BOYQHEAGS!mdybe/ralzgcsh~qet/227625010-80266208845-8559896522279839070966966999minh9795dx9n/cazhla-db00zaabb/KKT~KUM"> SrC="markrlondon23474.seksizlex.co/ASVGTY/unsub.jpg" flipkart.com>
Re: Problem with txrep database
On 2016-07-04 11:16, Ralf Hildebrandt wrote: Using SpamAssassin version 3.4.1 on Ubuntu precise (14.04) My /etc/mail/spamassassin/local.cf has: use_txrep1 normalize_charset1 txrep_factoryMail::SpamAssassin::SQLBasedAddrList user_awl_dsn DBI:mysql:spamassassin:127.0.0.1 user_awl_sql_usernameroot user_awl_sql_passwordsecret user_awl_sql_table txrep My /etc/mail/spamassassin/v341.pre contains: loadplugin Mail::SpamAssassin::Plugin::TxRep Yet I'm seeing no entries in the sql database: # mysql -uroot -psecret Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 80 Server version: 5.5.49-MariaDB-1ubuntu0.14.04.1 (Ubuntu) Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> use spamassassin; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [spamassassin]> select * FROM txrep; Empty set (0.04 sec) SpamAssassin is used from within amavisd-new; it seems that the config is being read/used: # su - amavis $ spamassassin --lint -D 2>&1 | fgrep -i txrep Jul 4 11:15:18.924 [17820] dbg: plugin: loading Mail::SpamAssassin::Plugin::TxRep from @INC Jul 4 11:15:18.934 [17820] dbg: TxRep: new object created Jul 4 11:15:19.247 [17820] dbg: config: fixed relative path: /var/lib/spamassassin/3.004001/updates_spamassassin_org/60_txrep.cf Jul 4 11:15:19.247 [17820] dbg: config: using "/var/lib/spamassassin/3.004001/updates_spamassassin_org/60_txrep.cf" for included file Jul 4 11:15:19.247 [17820] dbg: config: read file /var/lib/spamassassin/3.004001/updates_spamassassin_org/60_txrep.cf Jul 4 11:15:20.212 [17820] dbg: plugin: Mail::SpamAssassin::Plugin::TxRep=HASH(0x4ea0c08) implements 'learner_new', priority 0 Jul 4 11:15:20.553 [17820] dbg: TxRep: no scan in lint mode, quitting Try enabling debug logging for plugins TxRep and auto-whitelist. Amavis will log SA debug messages at log level 3. amavisd.conf: $log_level = 3; # or higher $sa_debug = 'TxRep,auto-whitelist'; make sure syslogd is not filtering out debug level messages, then reload amavisd and grep through the log: tail -f /var/log/amavisd-debug.log | egrep '(TxRep|auto-whitelist): ' Mark
Re: Re: Email with attachment caused 100% CPU usage.
On 6/8/2016 1:20 PM, John Hardin wrote: On Wed, 8 Jun 2016, Mark London wrote: Hi - We received an email with several large postscript attachments, and the content type was "text/plain". This caused our spamassassin server to use up 100% CPU, parsing the attachments as text. I temporarily disabled spam scanning to allow the message to go through. How can I prevent this in the future? I know about the time limit feature, but this doesn't prevent the server from running 100% of the time, before the time limit is reached. Any suggestions? Thanks. - Mark Content-Transfer-Encoding: base64 Content-Type: text/plain; name=OTBW_3D_256_ngtot100_de03_coll_dissip_1248.ps Content-Disposition: attachment; filename=OTBW_3D_256_ngtot100_de03_coll_dissip_1248.ps Do you have something that could catch text/plain + *.ps before SA get handed the message (e.g. a regex milter or other test)? I'm using MIMEDefang. I haven't looked to see what I could do with that. I've been running spamassassin for more years than I remember, and this is the first time I've encountered this situation. Someone else asked about my file size limit. I know that for a 512K postscript file as text/plain, that it takes up 100% of the CPU of one process, for about 1 minute. But I have a much larger file size limit, which I've increased over the years, in response to spam that we've received here. I believe the problem has always been there, but it's rarely been abused like this. I can't think of a proper solution. I guess maybe I'll just hope it never happens again. :) - Mark
Email with attachment caused 100% CPU usage.
Hi - We received an email with several large postscript attachments, and the content type was "text/plain". This caused our spamassassin server to use up 100% CPU, parsing the attachments as text. I temporarily disabled spam scanning to allow the message to go through. How can I prevent this in the future? I know about the time limit feature, but this doesn't prevent the server from running 100% of the time, before the time limit is reached. Any suggestions? Thanks. - Mark Content-Transfer-Encoding: base64 Content-Type: text/plain; name=OTBW_3D_256_ngtot100_de03_coll_dissip_1248.ps Content-Disposition: attachment; filename=OTBW_3D_256_ngtot100_de03_coll_dissip_1248.ps
Re: Numerous problems with SA under Raspbian jessie & Ubuntu 15.10
On 2015-12-20 16:15, Jari Fredriksson wrote: Dec 20 17:04:08.149 [32761] dbg: timing: total 128808 ms - load_scoreonly_sql: 0.27 (0.0%), signal_user_changed: 127278 (98.8%), b_tie_ro: 127275 (98.8%), parse: 6 (0.0%), extract_message_metadata: 187 (0.1%), get_uri_detail_list: 8 (0.0%), tests_pri_-1000: 234 (0.2%), tests_pri_-950: 2.4 (0.0%), tests_pri_-900: 2.9 (0.0%), tests_pri_-400: 130 (0.1%), check_bayes: 116 (0.1%), b_tokenize: 18 (0.0%), b_tok_get_all: 44 (0.0%), b_comp_prob: 4.4 (0.0%), b_tok_touch_all: 45 (0.0%), b_finish: 2.1 (0.0%), tests_pri_0: 830 (0.6%), check_spf: 66 (0.1%), poll_dns_idle: 49 (0.0%), check_pyzor: 0.58 (0.0%), tests_pri_500: 27 (0.0%), tests_pri_1000: 2.7 (0.0%), rewrite_mail: 0.85 (0.0%), copy_config: 66 (0.1%) signal_user_changed and b_tie_ro? What are those? SpamAssassin/BayesStore/SQL.pm It is trying to connect to your SQL database, which takes two minutes. Mark
Re: Numerous problems with SA under Raspbian jessie & Ubuntu 15.10
Btw, the fix for: "each on reference is experimental at ..." "keys on reference is experimental at /usr/share/perl5/Mail/SpamAssassin/Plugin/URILocalBL.pm" is at Bug 7208: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7208 Mark
Re: Google redirects
On 2015-12-18 16:29, Axb wrote: On 12/18/2015 04:17 PM, Mark Martinec wrote: On 2015-12-17 22:41, Axb wrote: could you make a version using redirector_pattern so the redirected target can be looked up via URIBL plugin? Isn't this already the case? Redirect targets are added to a list of URIs and are subject to same rules as directly collected URIs. I suggested converting the rawbody rule John was working on into a redirector_pattern Note that the following rule as posted by John: uri __GOOG_MALWARE_DNLD m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i would not currently work as a redirector_pattern due to the problem I posted in my today's reply (Re: redirector_pattern question); i.e. where the redirector target contains "http:", followed by other URI arguments (like "=1" here). Mark
Re: Google redirects
On 2015-12-17 22:41, Axb wrote: could you make a version using redirector_pattern so the redirected target can be looked up via URIBL plugin? Isn't this already the case? Redirect targets are added to a list of URIs and are subject to same rules as directly collected URIs. Mark
Re: redirector_pattern question
On 2015-12-18 11:19, Paul Stead wrote:
After the messages last night I've been looking into the
redirector_pattern config option - I'm seeing weird results...
Given the redirector_pattern of:
redirector_pattern m'https?://www.google.com/url?q=([^&]+).*'i
I've noticed that spamassassin can sometimes miss - I don't think it's
to do with the regex above as I've tried multiple variations - I've
made
it reproducible but I'm not sure why this is happening:
p1: http://pastebin.com/w93ZZp9h
p2: http://pastebin.com/p2pciGC3
[...]
# spaspamassassin -D -t < p2 2>&1 | grep baddomain
p2 doesn't pick up on baddomain.com
Any thoughts or have I stumbled upon a problem?
Two problems there, one is in your regexp, the other is in
the SpamAssassin logic of dealing with redirects.
The parameter of redirector_pattern is a regular expression,
dots and a question mark have a special meaning in a regexp.
If this special meaning is not wanted, they need to be quoted.
Also, SpamAssassin does not add anchoring to a redirector_pattern
regexp, so you need to add it yourself when needed.
And the .* at the end is redundant for this reason.
So it should be something like:
redirector_pattern m{^https?://www\.google\.com/url\?q=([^&]+)}i
The other problem is in
Mail::SpamAssassin::Util::uri_list_canonicalize()
near line 1346:
# deal with http redirectors. strip off one level of redirector
# and add back to the array. the foreach loop will go over those
# and deal appropriately.
# bug 3308: redirectors like yahoo only need one '/' ...
if ($rest =~ m{(https?:/{0,2}.+)$}i) {
push(@uris, $1);
}
# resort to redirector pattern matching if the generic https?
check
# doesn't result in a match -- bug 4176
else {
foreach (@{$redirector_patterns}) {
Note that it tries the hard-coded check first, and skips
evaluating redirector patterns when the hard-coded match
was successful.
So your redirector pattern was not tried at all, and at the same time
the hard-coded check obtained an invalid URL: from an URL
"/url?q=http://baddomain.com=1;
it collected as "http://baddomain.com=1; instead of
"http://baddomain.com;
The URI syntax after a '?' should treat "=1" as a second argument
and not glue it with the first argument "http://baddomain.com;.
So the resulting invalid URL "http://baddomain.com=1;
does not match any URI rules for baddomain.com .
Please try the attached patch (to 3.4.1 or trunk), it reverses
the order of checks: tries redirector_patterns first, and only
falls back to a sloppy hard-coded check as a last resort.
(and that hard-coded check would better be fixed too)
... and please open a bug report in bugzilla.
MarkIndex: lib/Mail/SpamAssassin/Util.pm
===
--- lib/Mail/SpamAssassin/Util.pm (revision 1720791)
+++ lib/Mail/SpamAssassin/Util.pm (working copy)
@@ -1342,24 +1342,28 @@
# deal with http redirectors. strip off one level of redirector
# and add back to the array. the foreach loop will go over those
# and deal appropriately.
- # bug 3308: redirectors like yahoo only need one '/' ...
- if ($rest =~ m{(https?:/{0,2}.+)$}i) {
-push(@uris, $1);
- }
- # resort to redirector pattern matching if the generic https? check
- # doesn't result in a match -- bug 4176
- else {
- foreach (@{$redirector_patterns}) {
- if ("$proto$host$rest" =~ $_) {
- next unless defined $1;
- dbg("uri: parsed uri pattern: $_");
- dbg("uri: parsed uri found: $1 in redirector: $proto$host$rest");
- push (@uris, $1);
- last;
- }
- }
+ # try redirector pattern matching first
+ # (but see also bug 4176)
+ my $found_redirector_match;
+ foreach my $re (@{$redirector_patterns}) {
+if ("$proto$host$rest" =~ $re) {
+ next unless defined $1;
+ dbg("uri: parsed uri pattern: $re");
+ dbg("uri: parsed uri found: $1 in redirector: $proto$host$rest");
+ push (@uris, $1);
+ $found_redirector_match = 1;
+ last;
+}
}
+ if (!$found_redirector_match) {
+# try generic https? check if redirector pattern matching failed
+# bug 3308: redirectors like yahoo only need one '/' ...
+if ($rest =~ m{(https?:/{0,2}.+)$}i) {
+ push(@uris, $1);
+ dbg("uri: parsed uri found: $1 in hard-coded redirector");
+}
+ }
## TVD: known issue, if host has multiple combinations of the following,
Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03
Not sure about SPF. It's supposed to be fixed in the current 3.4 branch and in trunk, which is why I'm not seeing a problem with Net::DNS 1.03 or Net::DNS 1.04. Will check how the released version of 3.4.1 fares with Net::DNS 1.04 regarding SPF. The emergency patches were applied to FreeBSD ports, don't know about other distributions. Here are the relevant bug entries: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7231 https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7265 I forgot about the Bug 7223, which also affects Net::DNS 1.01 or later: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7223 Tried it now with 3.4.1 and Net::DNS 1.04. You still need to apply the patch from Bug 7223 (in addition to a patch from Bug 7231), then it passes all tests with Net::DNS 1.04 (even without patches from Bug 7265). Seems easiest to install SpamAssassin from a svn 3.4 branch ( svn checkout http://svn.apache.org/repos/asf/spamassassin/branches/3.4 spamassassin-3.4 ) or downgrade Net::DNS to a pre-1.* version (i.e. 0.83). Mark
Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03
Ian Eiloart wrote: I had this problem after upgrading from a rather old version of SA. After upgrading to Net::DNS 1.04, the errors aren’t logged, but SpamAssassin isn’t finding SPF records. I wonder whether anyone can offer any suggestions. [...] Yesterday, I upgraded Net::DNS 1.03 to Net::DNS 1.04, and the "Can't locate object method "handles"" errors are not longer happening, but I still didn’t see any SPF_ results in my logs. I should see about 30,000 a day, judging by the volume before I upgraded. Not sure about SPF. It's supposed to be fixed in the current 3.4 branch and in trunk, which is why I'm not seeing a problem with Net::DNS 1.03 or Net::DNS 1.04. Will check how the released version of 3.4.1 fares with Net::DNS 1.04 regarding SPF. The emergency patches were applied to FreeBSD ports, don't know about other distributions. Here are the relevant bug entries: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7231 https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7265 There were three changes in New::DNS that affected SpamAssassin. The change in 1.01 affected SpamAssassin due to our sloppy parsing of Net::DNS results. The changes brought by 1.03 affected SpamAssassin on two fronts, both are due to an incompoatible API change in Net::DNS: different object class expected by bgread (which affected a handful of other Perl modules too), and a change in semantics of "retry" and "retrans" options, which affected DKIM plugin. Mark
Re: Re-4: A rule to check X-ASN header
My eventual goal is to test for "Has google in the sender name OR domain" and "is NOT from a ASN owned by Google". https://www.ultratools.com/tools/asnInfoResult?domainName=Google Am I'm not explaining myself correctly? ... nevertheless ... a valid DKIM signature by google is as good if not a better proof that a mail is coming from Google: full _DKIM_VALID_GOOGLE eval:check_dkim_valid(gmail.com, googlemail.com, googlegroups.com) header _GOOGLE_ANYWHERE_IN FROM From =~ /google|gmail/i meta GOTTA _GOOGLE_ANYWHERE_IN FROM && !_DKIM_VALID_GOOGLE Anyway, an ASN test would fail on mailing list mail by google senders. A DKIM test would also likely but not necessarily fail in such mail, depending how a mailing list is configured. For example this SpamAssassin mailing list preserves DKIM signature validity just fine. Mark
Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03
Net::DNS 1.03 breaks compatibility with SpamAssassin: DNS lookups no longer work, and warnings like the following pop up: On 2015-11-13 19:22, Quanah Gibson-Mount wrote: Well, IO::Socket::IP support is new in Net::DNS 1.03, but it is only used if IO::Socket::INET6 is not present. I would assume you can use it as long as you have IO::Socket::INET6 installed, but I haven't tested that assumption. They changed the object class that their bgsend() returns, and bgread() expects such object in its argument. SpamAssassin provides it's own bgsend (for multiple historical reasons, mainly to do with deficiencies or bugs in older versions of Net::DNS) and gives an object of class IO::Socket to bgread(), which is fine according to what the 1.02 documentation specifies: $ man Net::DNS::Resolver : bgread Reads the answer from a background query (see "bgsend"). The argument is an "IO::Socket" object returned by "bgsend". This is no longer so in 1.03, as the Net::DNS bgsend() now provides an IO::Select object and bgread expects a IO::Select object, no longer happy with an IO::Socket object that SpamAssassin provides. The new 1.03 docs say: bgread Reads the answer from a background query (see "bgsend"). The argument is an "IO::Socket" object returned by "bgsend". To me, this is an incompatible documented change - not something one would expect in an 1.02 -> 1.03 update. Mark
DNS lookups fail with SpamAssassin since Net::DNS 1.03
Net::DNS 1.03 breaks compatibility with SpamAssassin: DNS lookups no longer work, and warnings like the following pop up: lookup failed: Can't locate object method "handles" via package "IO::Socket::IP" at /usr/local/lib/perl5/site_perl/Net/DNS/Resolver/Base.pm line 735. There is a CPAN ticket open for this: https://rt.cpan.org/Public/Bug/Display.html?id=108745 Please stick to Net::DNS 1.02 until this is resolved. Mark
Re: Relay Country Plugin GEOIP issue
2015-10-15 00:09, a...@satester.com wrote: Does the Geo::IP package need to be recompiled for the change to go into effect? No. Use of uninitialized value $hasStructureInfo in numeric eq (==) at (eval 31) line 5520 According to comments in Geo/IP.pm your GeoIP database files must be very old if the program followed that codepath: # no structure info, must be pre Sep 2002 database, go back to Check your database: $ spamassassin --lint -D metadata' 2>&1 | fgrep RelayCountry should yield something like: Oct 15 01:26:45.584 [78315] dbg: metadata: RelayCountry: Using database: Geo::IP GEO-106FREE 20151006 Build 1 Copyright (c) 2015 MaxMind Inc All Rights Reserved Fresh files can be downloaded from: http://dev.maxmind.com/geoip/legacy/geolite/ unzip them and place them to their expected location, typically /usr/local/share/GeoIP/ . You need files GeoIP.dat and GeoIPv6.dat there. Mark
Re: charset=utf-16 tricks out SA
2015-10-10 03:03, RW wrote: I'm not seeing any body tokens, even after training. I was expecting that the text would be tokenized as individual UTF-8 sequences. ASCII characters encoded as UTF-16 and decoded with the wrong endianness are still valid UTF-16. Normalizing them into UTF-8 should produce completely multi-byte UTF-8 without whitespace or punctuation (not counting U+2000 inside UTF-8). If I add John Hardin's diagnostic rule body __ALL_BODY /.*/ tflags __ALL_BODY multiple I get: ran body rule __ALL_BODY ==> got hit: " _ _D_e_a_r_ _p_o_t_e_n_c_i_a_l_ _p_a_r_t_n_e_r_,_ _ _W_e_ _a_r_e_ _p_r_o_f_e_s_s_i_o_n_a_l_ _i_n_ _e_n_g_i_n_e_e_r_i_n_g_,_ _... It looks like it's still UTF-16, and Bayes is seeing individual letters (which are too short to be tokens) separated by nulls. The way it works now is if the decoding as declared fails, and some guessing fails too, it falls back to Windows-1252, which are single byte characters (superset of ISO-8859-1), which can't fail, and gives you the result you are seeing (spaced out by null characters). If I change the mime to utf-16le it works correctly, except that the subject isn't converted - including the copy in the body. If I set the mime to utf-16le I get what appears to be the multi-byte UTF-8 I was expecting. The endoded-word in the Subject header field needs to be declared as utf-16le too, then it works (tried on trunk). So SA isn't falling back to big-endian, it wont normalize without an explicit endianess. It tries as BE, and when Encode::decode reports a failure, it decodes as Windows-1252. BTW with normalize_charset 0 it looks like a spammer can effectively turn-off body tokenization by using UTF-16 (with correct endianness). Yes. There are also other tricks that a spammer can't play. It's not possible to emulate all different behaviours of various mail reading programs. Still, in the case we have it would make sense to try also the utf-16le, since this is a default endianness in Windows. Mark
Re: charset=utf-16 tricks out SA
Reindl Harald wrote: no custom body rules hit like they do for ISO/UTF8 :-( What is your normalize_charsets setting? enabled, that's what i meant with "like they do for ISO/UTF8" and adding "dear potencial partner" to CUST_BODY_17 did not change the score see attached sample and rule below body CUST_BODY_17/.*(1st page ranking of google|dear potencial partner).*/i score CUST_BODY_171.0 describe CUST_BODY_17Contains Low The problem with this message is that it declares encoding as UTF-16, i.e. not explicitly stating endianness like UTF-16BE or UTF-16LE, and there is no BOM mark at the beginning of each textual part, so endianness cannot be determined. The RFC 2781 says that big-endian encoding should be assumed in absence of BOM. See https://en.wikipedia.org/wiki/UTF-16 In the provided message the actual endianness is LE, and BOM is missing, so decoding as UTF-16BE fails and the rule does not hit. Garbage-in, garbage-out. If you manually edit the sample and replace UTF-16 with UTF-16LE (and normalize is enabled), your rule should hit - at least it does so in the current trunk code. If this seems to be common in the wild, please open a bug ticket, as Kevin suggested, and attach the sample there. Mark
Re: command arguments for spamd on FreeBSD
I recently updated SpamAssassin to version 3.4.1 on FreeBSD
8.4-release p36, running Postfix/Dovecot2.
My question is simple, how do I pass command arguments to spamd? (and
did this change since 3.3.x?)
I am quite sure that before upgrading the following lines in rc.conf
worked correctly to pass flags to spamd:
spamd_enable="YES"
spamd_flags="-s local5"
spamd_command_args="-d -A [2a03:6000:::xxx] -u spamd -x -q -r
${pidfile}"
But after the update the line "spamd_command_args" seems to be ignored.
Put all command line options for spamd in spamd_flags.
Mark
Re: Heads up: Net::DNS update may have quietly broken your SpamAssassin.
Olivier Nicole wrote: "Bill Cole" <sausers-20150...@billmail.scconsult.com> writes: I noticed today that the hit rate on URIBL* rules had dropped to to zero since my last round of updates, and after many hours of trying to determine why which included reviewing BIND configs and packet captures and dissection, I nailed it down to SA making DNS queries without the "recursion desired" flag. Since my local nameservers isn't authoritative for much, this meant a whole lot of "no answer, no error" DNS replies. It turns out that this is due to an internal change introduced in recent versions of Net::DNS, which SA relied upon to set the RD flag automatically. See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7223 for details and a patch. Thank you. I just check and for what it is worth, recent installations of SA on FreeBSD do include the patch. Best regards, Olivier Not to forget the fix at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202283 which is also needed with Net::DNS 1.01 or later. Already cherrypicked in the FreeBSD port of SpamAssassin: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202283 Mark
Re: Heads up: Net::DNS update may have quietly broken your SpamAssassin.
Not to forget the fix at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202283 which is also needed with Net::DNS 1.01 or later. Sorry, wrong link, should be: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7231 Already cherrypicked in the FreeBSD port of SpamAssassin: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202283 Mark
Re: New warnings after Perl upgrade to 5.20?
Larry Rosenman wrote: Getting the following on sa-learn: each on reference is experimental at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/URILocalBL.pm line 353. keys on reference is experimental at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/URILocalBL.pm line 377. keys on reference is experimental at /usr/local/lib/perl5/site_perl/Mail/SpamAssassin/Plugin/URILocalBL.pm line 406. this is after I upgraded my PERL to 5.20. (SA 3.4.1 on FreeBSD 10.2-STABLE from Ports) Just warnings fortunately. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7208 fix in revision 1684653: https://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/URILocalBL.pm?r1=1684653=1684652=1684653 Mark
Re: ALL_TRUSTED triggering _intermittently_ on external mails?
PGNd wrote: I'm running postfix 3.0.1 amavisd-new-2.10.1 (20141025) SpamAssassin version 3.4.1 on linux/64. amavisd/spamassasin is invoked as a postfix prequeue proxy filter. Spam is getting scanned and scored. Usually correctly. Intermittenly, I get an email that gets SHORTCIRCUITED on ALL_TRUSTED (example below). I've read through https://wiki.apache.org/spamassassin/TrustPath, and am missing something; I haven't yet managed to pick out the problem. My SA config includes the following internal_networks 127.0.0.0/8 10.2.2.0/24 10.1.1.0/24 X.X.X.X/29 trusted_networks 10.2.2.0/24 10.1.1.0/24 X.X.X.X/29 Here are headers for the received message. Note the shortcircuited score: X-Spam-Status: No, score=-101 tagged_above=- required=5 tests=[ALL_TRUSTED=-1, SC_HAM=-100, SHORTCIRCUIT=-0.0001] autolearn=disabled the msg's received-from headers are _not_ all on my internal networks, Are the 196.28.80.29, 196.28.80.61, and 196.28.66.13 in your trusted X.X.X.X/29 ? If they are, then hitting ALL_TRUSTED is expected. grep Received: spam1.txt INT Received: from mail-backend..com (LHLO mail-backend..com) INT Received: from relay-vpn.mail..com (internal.mail..com [10.1.1.10]) INT Received: from localhost (localhost [127.0.0.1]) INT Received: from amavis-feed.mail..com ([10.1.1.10]) INT Received: from localhost (localhost [127.0.0.1]) INT Received: from mail..com ([127.0.0.1]) EXT Received: from relay09.smp.mweb.co.za (relay09.smp.mweb.co.za [196.28.80.29]) EXT Received: from relay-mc01.smp.mweb.co.za ([196.28.80.61]) EXT Received: from [196.28.66.13] (helo=MWSJHBMC03) If I 'spamassassin -D spam1.txt' the message, it scores completely differently Jun 18 22:38:19.967 [19747] dbg: check: tests=BAYES_50,DCC_CHECK,HTML_MESSAGE,UNPARSEABLE_RELAY See the UNPARSEABLE_RELAY here? It prevents ALL_TRUSTED from firing. Received: from mail-backend..com (LHLO mail-backend..com) (10.2.2.20) by mail-backend..com with LMTP; Thu, 18 Jun 2015 16:50:56 -0700 (PDT) It is this Received header field above that is supposedly unparsable, and it was added _after_ a message went though a content filter. Remove it and re-try the command-line spamassassin test in the message. Mark
Re: ALL_TRUSTED triggering _intermittently_ on external mails?
PGNd wrote: The LHLO/LMTP header still is added at the backend, and UNPARSEABLE_RELAY still hits. I've not yet determined what the actual problem with the parsing is. It's a shortcoming/bug in the SpamAssassin ad-hoc parser. Please open a Bugzilla ticket and provide a sample of your Received header field (which is perfectly valid according to RFC 5321). Mark
Re: Confused about Bayes expiry
Ian Zimmerman wrote: I am very confused by the various features involving expiry from Bayes. perldoc Mail::SpamAssassin::Conf : bayes_expiry_max_db_size (default: 15) What should be the maximum size of the Bayes tokens database? When expiry occurs, the Bayes system will keep either 75% of the maximum value, or 100,000 tokens, whichever has a larger value. 150,000 tokens is roughly equivalent to a 8Mb database file. bayes_auto_expire (default: 1) If enabled, the Bayes system will try to automatically expire old tokens from the database. Auto-expiry occurs when the number of tokens in the database surpasses the bayes_expiry_max_db_size value. If a bayes datastore backend does not implement individual key/value expirations, the setting is silently ignored. bayes_token_ttl (default: 3w, i.e. 3 weeks) Time-to-live / expiration time in seconds for tokens kept in a Bayes database. A numeric value is optionally suffixed by a time unit (s, m, h, d, w, indicating seconds (default), minutes, hours, days, weeks). If bayes_auto_expire is true and a Bayes datastore backend supports it (currently only Redis), this setting controls deletion of expired tokens from a bayes database. The value is observed on a best-effort basis, exact timing promises are not necessarily kept. If a bayes datastore backend does not implement individual key/value expirations, the setting is silently ignored. This really sounds as if expiry is a no-op for backends other than Redis. And yet Debian bug #334829 [1] exists, and has spawned a whole subculture of solutions and work-arounds. (Sorry for the slight exaggeration.) Clearly the users reporting these problems do not use Redis, in fact by all signs they use the default DB backend, as I do. So should I be worried about the expiry overhead and set up a separate --force-expire job? I am confused. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334829 The redis backend takes advantage of an auto-expiry mechanism of key/value pairs as provided by a redis server internally (transparently and automatically), so with this backend the bayes_token_ttl is the only setting that matters, and SpamAssassin (auto)expiration runs are not needed, if fact they are a no-op and should not be used. With other bayes back-ends the traditional expiration mechanisms need to be used, either auto-expiration runs triggered from time to time by SpamAssassin, or explicit expiration runs, e.g. from a cron job. With these traditional back-ends the bayes_token_ttl setting has no effect. and has spawned a whole subculture of solutions and work-arounds Indeed. These mostly pre-date the availability of a Redis back-end. Mark
RE: PerMsgStatus Util warnings
Jim Barber wrote: From: Mark Martinec [mailto:mark.martinec...@ijs.si] Are you using some third-party SpamAssasin plugin that relies on the deprecated subroutine Mail::SpamAssassin::Util::uri_to_domain ? I'm getting the same error: May 15 12:34:41 smtp-syd mimedefang-multiplexor[30108]: t4F2YYjZ003229: Slave 6 stderr: plugin: eval failed: Undefined subroutine Mail::SpamAssassin::Util::RegistrarBoundaries::trim_domain called at /usr/share/perl5/Mail/SpamAssassin/Util.pm line 1236. I'm using The SpamAssassin Debian package (which is version 3.4.1-1). I do have a third party plugin that is calling uri_to_domain. It is located at the following URL: https://github.com/smfreegard/DecodeShortURLs And is linked to from the SpamAssassin Custom Plugins wiki page: https://wiki.apache.org/spamassassin/CustomPlugins Here is the offending line: jimb@smtp-syd:~$ grep uri_to_domain /etc/spamassassin/DecodeShortURLs.pm my ($dom, $host) = Mail::SpamAssassin::Util::uri_to_domain($_); I'm mentioning this because the bug that was raised for this has the following comment: KAM: Please let us know if you are using a 3rd party plugin because we'd like to make sure the authors noticed the change in 3.4.1. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7195 Thanks, useful. If you have a chance please try the small patch there (just adds the: use Mail::SpamAssassin::Util::RegistrarBoundaries; line in Util.pm) and see if it helps. Mark
Re: PerMsgStatus Util warnings
Alex Regan wrote:
I have v3.4.1 with amavisd v2.9.1 on fedora20 and receiving the
following warnings:
May 13 23:32:31 mail01 amavis[17306]: (17306-10) _WARN: plugin: eval
failed: Undefined subroutine
Mail::SpamAssassin::Util::RegistrarBoundaries::trim_domain called at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Util.pm line 1236.
May 13 23:35:43 mail01 amavis[17386]: (17386-12) _WARN: Use of
uninitialized value in concatenation (.) or string at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/PerMsgStatus.pm line
3082.
I thought I remembered this issue being discussed some time ago, but
couldn't find any recent references to it. It looks like it happens
just in the course of processing messages with no other information
around these lines. I also don't know when it first started. Thought
someone might have some ideas?
Are you using some third-party SpamAssasin plugin that relies on the
deprecated subroutine Mail::SpamAssassin::Util::uri_to_domain ?
Please try the patch below:
===
--- Mail/SpamAssassin/Util.pm~ 2015-04-28 21:56:49.0 +0200
+++ Mail/SpamAssassin/Util.pm 2015-05-14 16:26:23.198104251 +0200
@@ -49,4 +49,5 @@
use Mail::SpamAssassin::Logger;
+use Mail::SpamAssassin::Util::RegistrarBoundaries; # deprecated
BEGIN {
===
Mark
Re: PerMsgStatus Util warnings
Alex Regan wrote: Please open a bug report (one should do, even though these are two independent issues). Bug filed, thanks so much. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7195 Great, thanks. Please also try the posted patch and see if that resolves the first type of a warning (the 'Undefined subroutine'). Mark
Re: PerMsgStatus Util warnings
I have v3.4.1 with amavisd v2.9.1 on fedora20 and receiving the following warnings: May 13 23:32:31 mail01 amavis[17306]: (17306-10) _WARN: plugin: eval failed: Undefined subroutine Mail::SpamAssassin::Util::RegistrarBoundaries::trim_domain called at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Util.pm line 1236. May 13 23:35:43 mail01 amavis[17386]: (17386-12) _WARN: Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/PerMsgStatus.pm line 3082. The second warning is independent from the first, I'm seeing these too. It's because the RegistryBoundaries::uri_to_domain returns undef when it sees %hh encoding in an URL, and the caller then tries to concatenate it with 'dummy@', which produces this warning. Seems harmless but annoying, should be fixed. Please open a bug report (one should do, even though these are two independent issues). Mark
Re: interesting spammer trick (bayes)
On 2015-05-03 10:55, Reindl Harald wrote: recently i observed by playing around with bayes-training that some junk (maybe unintentional) is using the mimetype 'application/octet-stream' instead 'text/html' containing the payload of a form with javascript prevets the attachment from tokenizing the new feature in 3.4.1 will take care of that while i am not sure how much impact in classifying a trained attachment at the end has SHA1 digests of all MIME parts (including non-textual) can now be contributed to Bayes tokens, which allows the bayes classifier to assess also the non-textual content. The set of sources of bayes tokens is configurable with a new configuration option 'bayes_token_sources' as documented in the Mail::SpamAssassin::Conf man page. (Bug 7115) It is disabled by default for backward compatibility. i am not sure here in context of backward compatibility Just a cautionary speech. There were some concerns whether it is beneficial or not to contribute digests of non-textual parts or not, and not much experience has been gained yet, so to avoid any potential surprise the default is the same as with 3.4.0, i.e. digests are not included. In my experience it can be valuable to include these, and I haven't seen any ill effect while observing top-10 bayes tokens containing digests, as logged by a debug log, for several weeks. correct me but IMHO bayes_token_sources all should not have a side effect when you train a bayes on SA 3.4.1 and share it with a setup using 3.4.0 - the 3.4.0 setup just should not benefit from the new mimeparts-tokens in the database but still from all others? That is correct, learned digest tokens as inserted by 3.4.1 are ignored by 3.4.0 code. Btw, note that spamd does not process messages larger than some pre-set size limit. Even if truncated messages are passed to spamd, it would not see MIME parts beyond the truncation limit. This is unlike what the current (to-be-released) version of amavisd does: regardless of mail size amavisd would compute digests of *all* pristine mail parts, and pass them to SpamAssassin out-of-band, already ready-to-use, even if a message is truncated. This also avoids some pre-processing 'corruption' of MIME digests when computed by SpamAssassin, as a 'pristine' mail as understood by SpamAssassin is sometimes a little less 'pristine' than ideal, e.g. due to squashing long runs of empty lines in a message, and splitting long paragraphs into chunks. With MIME digests it's the same approach as with DKIM signatures, which are also pre-computed by amavisd on the complete (non-truncated) pristine message, and passed to SpamAssassin for use in the DKIM plugin. Mark
Re: need_tags
On 5/3/2015 2:40 AM, Robert Schetterer wrote: Hi , i try to understand this http://search.cpan.org/dist/Mail-SpamAssassin/lib/Mail/SpamAssassin.pm need_tags ... Currently the only tag that needs to be explicitly requested is 'TIMING' ... the goal would be to have time stats of every rule matching in logs, without advanced debug levels on production servers for better analysis On 2015-05-04 15:42, Kevin A. McGrail wrote: I believe this setting is solely for profiling of spamassassin. See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5356 but I doubt it's of much use to the general public. The requirement for timing can be requested by a application using the SpamAssassin library. Currently amavisd does turn it on and the SpamAssassin timing report is included in the amavisd log, but the spamd does not include the timing report in its log. Mark
Re: need_tags
The requirement for timing can be requested by a application using
the SpamAssassin library. Currently amavisd does turn it on and
the SpamAssassin timing report is included in the amavisd log,
but the spamd does not include the timing report in its log.
On 2015-05-05 1:20, Kevin A. McGrail wrote:
Neat. Can you cut and paste an example log and perhaps we can mimic it
in spamd easily?
Here's and example
(I hope my mailer won't wrap it unnecessarily):
May 5 01:34:51 dorothy amavis[8286]: (08286-06) TIMING-SA [total 2178
ms, cpu 2
89 ms] - parse: 0.87 (0.0%), extract_message_metadata: 13 (0.6%),
get_uri_detail
_list: 0.65 (0.0%), tests_pri_-1000: 29 (1.3%), tests_pri_-950: 1.56
(0.1%), tes
ts_pri_-900: 1.40 (0.1%), tests_pri_0: 1251 (57.5%), check_spf: 0.13
(0.0%), che
ck_dkim_adsp: 5 (0.2%), check_bayes: 9 (0.4%), b_tokenize: 3.4 (0.2%),
b_tok_get
_all: 1.93 (0.1%), b_comp_prob: 2.0 (0.1%), b_tok_touch_all: 0.62
(0.0%), b_fini
sh: 0.13 (0.0%), check_razor2: 202 (9.3%), check_dcc: 838 (38.5%),
check_pyzor:
162 (7.4%), tests_pri_500: 5 (0.3%), get_report: 0.58 (0.0%)
Most of it (elapsed times) is produced by a call to:
$pms-get_tag('TIMING');
The CPU usage is obtained by calling Unix::Getrusage .
Mark
Re: TxRep $msgscore warning
my $sa_args = {
local_tests_only = $SALocalTestsOnly,
dont_copy_prefs= 1,
userprefs_filename = $config,
user_dir = $Features{'Path:QUARANTINEDIR'},
debug = 'TxRep'
};
amavisd.conf:
$sa_debug = 1;
Is there a way to tighten that to just show TxRep debug messages?
The:
$sa_debug = 'TxRep';
is the equivalent of the above debug='TxRep'.
A comma-separated list of SpamAssassin debug facilities can
be provided and is passed to the 'debug' argument of SA.
Mark
Re: SA 3.4.1 - error messages in log?
On May 2, 2015 7:08:10 PM Mark Martinec wrote: May 2 06:45:29 sunshine spamd[22293]: Use of uninitialized value $hasStructureInfo in numeric eq (==) at (eval 46) line 5520. This one seems to come from a module Geo::IP, called form a SpamAssassin plugin URILocalBL. [...] Try disabling loading of a plugin URILocalBL as a start (in config file v341.pre). On 2015-05-03 2:26, Art Greenberg wrote: The line for URILocalBL is commented out - I had not enabled it. There is also the RelayCountry plugin that is using the Geo::IP module. Mark
Re: dkim invalid and 3.4.1
1.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The score for this rule should be a zero or a near-zero. There must be some problem with assigning a score to such test rule (the 1.0 is a default value if a score line is missing). T_DKIM_INVALID is a test rule, as such its score should be 0.01 by default. Make sure the sa-update has provided an up-to-date version of rules. Mark
Re: dkim invalid and 3.4.1
On 2015-05-03 5:34, Nick Edwards wrote: Is there any reason reason=invalid (public key: not available) is declared as error to fail t_dkim_invalid 1.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid This is published a neutral so should not be considered invalid This only occurs since upgrade 3.4.0 - 3.4.1, no changed made by the sender - its a govt dept, who doesnt change things at all let alone in middle of weekend. Be a shame to have to score that 0 simply because the code over reacts. The score for this rule should be a zero or a near-zero. There must be some problem with assigning a score to such test rule (the 1.0 is a default value if a score line is missing). An invalid or unverifiable DKIM signature is supposed to be treated equivalent to a missing signature. Mark
Re: SA 3.4.1 - error messages in log?
On 2015-05-02 14:39, Art Greenberg wrote: I just moved from 3.4.0 to 3.4.1 and am seeing messages from SA in maillog that I've not seen before. Do they indicate an issue with my installation? Here is a segment from the log. This pattern repeats each time SA processes a message. The use of uninitialized value and copy_config timeout are new, as is the change of child states. May 2 06:45:29 sunshine spamd[22293]: Use of uninitialized value $hasStructureInfo in numeric eq (==) at (eval 46) line 5520. This one seems to come from a module Geo::IP, called form a SpamAssassin plugin URILocalBL. May 2 06:46:29 sunshine spamd[22290]: spamd: copy_config timeout, respawning child process after 1 messages at /usr/local/bin/spamd line 1447. [...] May 2 06:46:30 sunshine spamd[21741]: spamd: handled cleanup of child pid [22290] due to SIGCHLD: exit 0 May 2 06:46:40 sunshine spamd[22293]: spamd: copy_config timeout, respawning child process after 1 messages at /usr/local/bin/spamd line 1447. [...] SA does seem to be processing messages correctly. But starting SA does seem to take forever ... I've had to increase the timeout on line 2977 in spamd from 180 to 600 seconds. I'm running SA just for personal email on a machine pretty much dedicated to handling email so performance is not a concern. Centos 6.6 64 bit, Intel E7300 2.66GHz with 4GB RAM and 500GB disk. No idea. Try disabling loading of a plugin URILocalBL as a start (in config file v341.pre). Mark
Re: ANNOUNCE: Apache SpamAssassin 3.4.1 available (bug)
On 2015-05-01 20:34, Forrest wrote: Upgrading from a simple 3.4.0 installation, 3.4.1 refuses to start, with this error: Starting spamd: child process [3723] exited or timed out without signaling production of a PID file: exit 255 at /usr/local/perl/bin/spamd line 2986. I've seen this before, but I did check for any leftover PID files (none exist). I also rebooted our system, to no avail.Going to attempt downgrading to see if that fixes the bug. spamd --debug Mark
Re: spam score question
On April 22, 2015 8:44:59 PM EDT, Thom Miller t...@cagroups.com wrote: On Sat, 18 Apr 2015 08:16:40 -0700 Michael Williamson michael.h.william...@gmail.com wrote: It appears to me that spamassassin can produce different spam scores for the same email. In particular, I have noticed that points are omitted for RCVD_IN_SBL_CSS (Spamhaus blacklist) sometimes. Why? In the past I noticed that network tests were sometimes completely omitted. I believe sa checks for network connectivity before perfoming these tests, and incorrectly determines that there is no network available. In my case, adding: dns_available yes to my local.cf solved this issue. 2015-04-24 01:38, Thom Miller wrote: Kevin A. McGrail kmcgr...@pccc.com wrote: On 4/22/2015 11:19 PM, Thom Miller wrote: According to https://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html : By default, SpamAssassin will query some default hosts on the internet to attempt to check if DNS is working or not. The problem is that it can introduce some delay if your network connection is down, and in some cases it can wrongly guess that DNS is unavailable because the test connections failed. I decided that since the network should always be available, there's no reason for spamassassin to test it. Interesting. What version of SA are you using? I'm running 3.4.0 now, but I made this addition to local.cf when I was running 3.2. I don't know if the change is still necessary in my case, but I haven't bothered to remove it. -Thom The 'dns_available yes' is a default since 3.4.0. 3.4.0 release notes: * A default setting for option 'dns_available' was changed from 'test' to 'yes' (bug 6770, bug 6769), so SpamAssassin now assumes by default that it is running on a host with an internet connection and a working DNS resolver. If this is not the case, please configure this option explicitly. The change avoids surprises on an otherwise well connected host which may experience a temporary DNS unavailability at the system startup time or a temporary network outage when spamd was starting, and the initial failed test would disable DNS queries permanently. The option is documented in the Mail::SpamAssassin::Conf POD or man page. Mark
Re: FPs on RCVD_ILLEGAL_IP
Dianne Skoll wrote: On Mon, 20 Apr 2015 17:02:09 -0700 (PDT) John Hardin jhar...@impsec.org wrote: I suggest that this rule should treat 0/8 as equivalent to 127/8. That's essentially what it's reserved for, just local to the LAN vs. local to the host. Does 0/8 really mean that? On at least one OS (Linux), the TCP stack treats it specially: $ telnet 0.1.2.3 Trying 0.1.2.3... telnet: Unable to connect to remote host: Invalid argument The EINVAL return is certainly not the same as trying a nonexistent host: $ telnet 10.11.12.13 Trying 10.11.12.13... [hangs] I don't think 0/8 was intended for real traffic. I understood it to be intended only for hosts trying to discover their real IP addresses. The 0.0.0.0/8 is an 'unspecified' address. In principle a host is free to use it for whatever purposes internally (or for network discovery), but is not routable outside the host. In that sense it behaves the same as 127.0.0.0/8 and I think for the purposes of seeing it in a Received header field outside of the 'trusted' zone it should be treated as any foreign private IP address space, i.e. it may be valid for the host which inserted it, but has no value for us the receiving party. Btw, the same should apply to addresses ::/128 and ::1/128 . Mark
Re: FPs on RCVD_ILLEGAL_IP
In any case, I think that RCVD_ILLEGAL_IP should not be adding score points if it sees an 0.0.0.0/8 address in a Received header field. Mark
Re: FPs on RCVD_ILLEGAL_IP
shanew wrote: I presume detecting forged Received headers was the point of this rule all along, so if we all toss this rule out the window (or adjust to exclude this edge case), aren't we potentially encouraging spammers to hide their true networks in the same way? There is no benefit to spammers (and a likely disservice to them) for forging a non-trustworthy external Received header field and providing some unusual IP address there, and they cannot forge the boundary Received header field inserted by recipient's own mailer. I can only conclude that a rule like RCVD_ILLEGAL_IP will hit mostly on misconfigured or misguided sending mailers, not primarily on spam. Reindl Harald wrote: my problem with that rule is that it hits practically no spam but only ham and so it goes in the wrong direction entirely Most likely. Mark
Re: FPs on RCVD_ILLEGAL_IP
Dianne Skoll wrote: Mark Martinec mark.martinec...@ijs.si wrote: I can only conclude that a rule like RCVD_ILLEGAL_IP will hit mostly on misconfigured or misguided sending mailers, not primarily on spam. I disagree. Now that the Microsoft issue has been fixed, well over 95% of the mail on our system that hits RCVD_ILLEGAL_IP is spam. You are right, I checked our logs and the RCVD_ILLEGAL_IP does indeed mostly hit on spam. ... although there's a funny twist there. Some of these illegal IP addresses are not really a claimed-to-be IP address of a mailer, but come from an embedded e-mail address in a comment: Received: from unknown (HELO localhost) (jennifer_pr...@sbcglobal.net@236.192.200.84) by mm-36-150-122-178.brest.dynamic.pppoe.byfly.by with ESMTPA; Tue, 21 Apr 2015 23:55:53 +0300 Received: from unknown (HELO localhost) (bsobolew...@stockton-house.com@236.139.213.194) by 76.172.150.91 with ESMTPA; Tue, 21 Apr 2015 11:41:10 -0800 so by a lucky coincidence a misparsed Received ends up yielding a useful-but-wrong result. Mark
Re: FPs on RCVD_ILLEGAL_IP
John Hardin wrote: I suggest that this rule should treat 0/8 as equivalent to 127/8. That's essentially what it's reserved for, just local to the LAN vs. local to the host. I fully agree. Mark
