Re: another extortion email check
On 5/2/20 1:47 PM, Loren Wilton wrote: The compromised password is already in plain text in the subject of the message; there isn't much point in hiding it other than embarassment. What if the email server with the list of plain text passwords is compromised and said list of plain text passwords is released to a wide audience? The list of previous compromised passwords could have been very private (known corporate hack or something like that) and not released to a wide audience. Now, your list of plain text passwords on the email server is the source of a larger and more public release. Why have that list of plain text passwords /anywhere/ if you don't have to? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: another extortion email check
That exact string occurs in a Vade Security header, X-ME-VSCause, added by Fastmail on a completely unrelated legitimate email I received. I think it's more like an obfuscated information header for Vade's own use. I guess I'm not surprised. I would say then that it is a useless header as a spam or scam marker. Personally I'll stick with the easy method of a subject rule looking for the offending password, or hopefully ex-password. Loren
Re: Question about the 'URIBL_BLOCKED' rule
Man thanks to those who responded. I was mainly wondering how the inability to do blacklist checks would impact the overall ability of SpamAssassin to detect spam. Given the responses, I'll go in a different direction. I'll move the site to a VPS, where I can have more control over SpamAssassin and DNS configuration. Thanks! Tom On 5/2/20 3:25 AM, Jari Fredriksson wrote: > I have too had a problem of this in my masscheck box. It is a cloud VM > in Google Cloud and they do like to provide a /etc/resolv.conf for > their own DNS which has been next to impossible to overcome. I do > replace it in the beginning of my masscheck process with my own but to > no avail. > > I now figured out I can add this to auto-mass-check.cf and going to > see how it works. > > spam@gauntlet ~ $ grep dns gcloud/auto-mass-check.sh > echo "dns_server 127.0.0.1" >> spamassassin/user_prefs > > br. jarif > > On 30.4.2020 22.28, Richard Doyle wrote: >> First result on Google: >> http://cweiske.de/tagebuch/uribl_blocked.htm >> >> Short version: URIBL will block you if you use any of the big DNS >> providers, such as 8.8.8.8. >> >> >> On 4/30/20 11:59 AM, Tom Williams wrote: >>> Hi! I'm new to this mailing list, but not new to SpamAssassin. I've >>> used it on and off for a number years. :) Recently, (within the past >>> 6 months or so) I enabled it for email in a shared web hosting >>> environment (we host with InMotionHosting). Anyway, due to the >>> volume of >>> email traffic the server receives, I see a *lot* of 'URIBL_BLOCKED' >>> entries in the SpamAssassin header injected in the headers of incoming >>> mail. If our server can't use URIBL to check mail, will that have an >>> adverse or negative impact on SpamAssassin's ability to detect/identify >>> spam? Our host is running SpamAssassin 3.0 (shudders, I know it's >>> ancient). >>> >>> Thanks in advance! >>> >>> Tom >>>
Missing optional modules
[spamassassin-3.4.4 + FreeBSD 12.1-RELEASE-p4]
Dear list members,
Using this version I get the following warning lines when I update:
May 2 12:00:06.917 [82826] dbg: diag: [...] optional module not installed:
Geo::IP ('require' failed)
May 2 12:00:06.917 [82826] dbg: diag: [...] optional module not installed:
IP::Country::DB_File ('require' failed)
Can someone tell me which packages I should install to solve this issue? I
already installed all Geo_IP and Country related packages, but SA still misses
the required modules.
Thanks, Jos
-- With both feet on the ground you can't make any step forward
Re: another extortion email check
On Sat, 2 May 2020 12:47:12 -0700 Loren Wilton wrote: > Well, if you want to do it the hard way there may be a way. > > I notice that three recient examples I have all failed DKIM check. > They also all have a very long header line that appears to have been > inserted either by outlook.com or the originating spamware: > X-VadeSecure-Cause. This has a very long hashed or possiby base-64 > string. While this seems to be part of the outlook.com spam checking > info, for all three messages I looked at, the first line (at least) > of this cryptic blob was identical. That likely means the message > bodies are identical. You could do a match for that and a meta to > check that and dkim fail. > > In my case I could maybe do something like: > > header _UNSECURE_CAUSE X-VadeSecure-Cause =~ > /gggruggvucftvghtrhhoucdtuddrgeduhedrieehgdefkecutefuodetggdotefrodftvfcurfhroh/ That exact string occurs in a Vade Security header, X-ME-VSCause, added by Fastmail on a completely unrelated legitimate email I received. I think it's more like an obfuscated information header for Vade's own use.
Re: another extortion email check
Well, if you want to do it the hard way there may be a way. I notice that three recient examples I have all failed DKIM check. They also all have a very long header line that appears to have been inserted either by outlook.com or the originating spamware: X-VadeSecure-Cause. This has a very long hashed or possiby base-64 string. While this seems to be part of the outlook.com spam checking info, for all three messages I looked at, the first line (at least) of this cryptic blob was identical. That likely means the message bodies are identical. You could do a match for that and a meta to check that and dkim fail. In my case I could maybe do something like: header _UNSECURE_CAUSE X-VadeSecure-Cause =~ /gggruggvucftvghtrhhoucdtuddrgeduhedrieehgdefkecutefuodetggdotefrodftvfcurfhroh/ header _AUTH_FAIL X-Authentication-Results =~ /dkim=\"fail\"/ header _SUB_ONE Subject =~ /\s/ meta PASSWORD_SCAM _UNSECURE_CAUSE && _AUTH_FAIL && _SUB_ONE score PASSWORD_SCAM 10 This strikes me as a lot of work and probably pretty fragile, and unnecesary. The compromised password is already in plain text in the subject of the message; there isn't much point in hiding it other than embarassment. Loren
Re: another extortion email check
On 5/1/20 1:55 PM, Loren Wilton wrote: You should be able to catch these with a single custom rule along the lines of header STOLEN_PASSWORD Subject =~ /old_password/ score STOLEN_PASSWORD 10 I'd pondered doing such. But I dislike the fact that the (compromised) password is stored in clear text and wonder about collision with other people using the same password (or strings of characters). Is there any way to compare hashed strings of text? E.g. take each word from a message (header or body), hash it and look for a match of the hashed password? I feel like storing any password in clear text, previously compromised or not, is a Bad Idea™. I would also want to have some way to associate the (hashed) password with a specific account to avoid collisions for other accounts that might not have been compromised. I don't know if it would be able to create the granularity that I want with a meta-rule. Something that matches the account name (or some other similar identifier) and then check the hashed password. I also don't know that I would want the overhead of hashing every word in messages unless they were otherwise suspicious enough to warrant such in depth scrutiny. Note: Everywhere I say "hash", I would really like to see salted and hashed. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Question about the 'URIBL_BLOCKED' rule
On Sat, 2 May 2020 15:59:27 +0300 Jari Fredriksson wrote: > On 2.5.2020 13.30, Reindl Harald wrote: > > and why don't you just replace /etc/resolv.conf and fire up "chattr > > +i /etc/resolv.conf" like everyone else does for years to keep it > > untouched (that's even a ducomentaed way to prevent it overwritten > > by dhcp clients) > > > > there is no point using a shared dns from whatever provider and > > it's a shame that most people are still so bound to it that they > > often fuckup even tehir own named/unbound setup with forwarders > > Thanks! I have used Linux since 1994 but was not aware of that. I'll > try it next. You shouldn't need to do that as you can configure the DNS cache in your settings. My understanding is that masschecks are supposed to reuse network results from X-Spam-Status. Presumably the URIBL_BLOCKED warning is about lookups that occurred during the original scan rather than during the masscheck. Any network tests repeated during the masscheck would tend to corrupt the results. If you have dns_server set during scans and you are getting URIBL_BLOCKED then you have either found a bug, your DNS is diverted, or your IP address itself is blocked for some reason.
Re: another extortion email check
Yes, noticed that as well and considered making it simple with that rule. Probably best thing to do anyway. Thank you both. -AJ On 5/1/2020 5:08 PM, John Hardin wrote: On Fri, 1 May 2020, Loren Wilton wrote: Please help, apparently this person "knows everything about me" :) I got a rash of these a year or two ago, and have started getting a few more reciently. I haven't looked at the body of the recient ones, so don't know if they are still using the standard text. However, the identiying feature is that the subject is a single word, which is the stolen password. You should be able to catch these with a single custom rule along the lines of header STOLEN_PASSWORD Subject =~ /old_password/ score STOLEN_PASSWORD 10 That's what I do.
Re: Question about the 'URIBL_BLOCKED' rule
On 2.5.2020 13.30, Reindl Harald wrote: and why don't you just replace /etc/resolv.conf and fire up "chattr +i /etc/resolv.conf" like everyone else does for years to keep it untouched (that's even a ducomentaed way to prevent it overwritten by dhcp clients) there is no point using a shared dns from whatever provider and it's a shame that most people are still so bound to it that they often fuckup even tehir own named/unbound setup with forwarders Thanks! I have used Linux since 1994 but was not aware of that. I'll try it next. br. jarif
Re: Question about the 'URIBL_BLOCKED' rule
Still! Syncing weekly_mass_check check: dns_block_rule URIBL_BLOCKED hit, creating/home/jarif/.spamassassin/dnsblock_multi.uribl.com (This means dnsbl blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny multi.uribl.com" to disable queries) 12:34:19 up 1:34, 0 users, load average: 32.21, 32.29, 32.17 rsync -Pcqz ham-net-jarif.log spam-net-jarif.log*munged*/ 12:34:43 up 1:34, 0 users, load average: 21.57, 29.78, 31.34 Bummer. br. jarif On 2.5.2020 13.25, Jari Fredriksson wrote: I have too had a problem of this in my masscheck box. It is a cloud VM in Google Cloud and they do like to provide a /etc/resolv.conf for their own DNS which has been next to impossible to overcome. I do replace it in the beginning of my masscheck process with my own but to no avail. I now figured out I can add this to auto-mass-check.cf and going to see how it works. spam@gauntlet ~ $ grep dns gcloud/auto-mass-check.sh echo "dns_server 127.0.0.1" >> spamassassin/user_prefs br. jarif On 30.4.2020 22.28, Richard Doyle wrote: First result on Google: http://cweiske.de/tagebuch/uribl_blocked.htm Short version: URIBL will block you if you use any of the big DNS providers, such as 8.8.8.8. On 4/30/20 11:59 AM, Tom Williams wrote: Hi! I'm new to this mailing list, but not new to SpamAssassin. I've used it on and off for a number years. :) Recently, (within the past 6 months or so) I enabled it for email in a shared web hosting environment (we host with InMotionHosting). Anyway, due to the volume of email traffic the server receives, I see a *lot* of 'URIBL_BLOCKED' entries in the SpamAssassin header injected in the headers of incoming mail. If our server can't use URIBL to check mail, will that have an adverse or negative impact on SpamAssassin's ability to detect/identify spam? Our host is running SpamAssassin 3.0 (shudders, I know it's ancient). Thanks in advance! Tom
Re: Question about the 'URIBL_BLOCKED' rule
I have too had a problem of this in my masscheck box. It is a cloud VM in Google Cloud and they do like to provide a /etc/resolv.conf for their own DNS which has been next to impossible to overcome. I do replace it in the beginning of my masscheck process with my own but to no avail. I now figured out I can add this to auto-mass-check.cf and going to see how it works. spam@gauntlet ~ $ grep dns gcloud/auto-mass-check.sh echo "dns_server 127.0.0.1" >> spamassassin/user_prefs br. jarif On 30.4.2020 22.28, Richard Doyle wrote: First result on Google: http://cweiske.de/tagebuch/uribl_blocked.htm Short version: URIBL will block you if you use any of the big DNS providers, such as 8.8.8.8. On 4/30/20 11:59 AM, Tom Williams wrote: Hi! I'm new to this mailing list, but not new to SpamAssassin. I've used it on and off for a number years. :) Recently, (within the past 6 months or so) I enabled it for email in a shared web hosting environment (we host with InMotionHosting). Anyway, due to the volume of email traffic the server receives, I see a *lot* of 'URIBL_BLOCKED' entries in the SpamAssassin header injected in the headers of incoming mail. If our server can't use URIBL to check mail, will that have an adverse or negative impact on SpamAssassin's ability to detect/identify spam? Our host is running SpamAssassin 3.0 (shudders, I know it's ancient). Thanks in advance! Tom
