Re: Today's Google Docs phish
On Fri, 5 May 2017 22:02:56 -0400 Alex wrote: > Am I understanding correctly that redirector_pattern breaks up the one > encoded URI into multiple URIs that are available for rules to be > written using them, instead of ? > > In other words, if I were to write a uri rule that includes > www.googleapis.com, it would match in this case? How does it differ > had I not had a redirector pattern and just wrote a rule matching the > pattern directly? The point is that all URI based rules can run against the URI extracted by the redirector rule. For example the target domain might be in a URI blocklist or use a TLD that you penalize.
Re: Today's Google Docs phish
Hi,
>> >>> I found a local version which maybe did the trick
>> >>>
>> >>> redirector_pattern
>> >>>
>> >>> m'^https?:/*(?:\w+\.)?google(?:\.\w{2,3}){1,2}/url\?.*?(?<=[?&])q=(.*?)(?:$|[&\#])'i
>> >>
>
>> Yes, but I don't understand how that equates to an eventual score.
>
> I haven't used these, but by the look of it it's trying to identify
> the encoded URI so that other rules can see it.
>
>> Perhaps I don't understand regex's well enough, but I don't understand
>> what it does with the redirector site portion and the target portion.
>
> In rules you often see ?: used in brackets to prevent the matching
> text being captured as this makes it more efficient, e.g. (?:\w+\.)
> in the above. Towards the end of the pattern is (.*?) which is
> used to capture the target uri.
>
> .*? is like .*, but matches the shortest run of characters it can,
> rather than the longest.
Am I understanding correctly that redirector_pattern breaks up the one
encoded URI into multiple URIs that are available for rules to be
written using them, instead of ?
In other words, if I were to write a uri rule that includes
www.googleapis.com, it would match in this case? How does it differ
had I not had a redirector pattern and just wrote a rule matching the
pattern directly?
May 5 21:32:22.768 [5533] dbg: uri: parsed uri found:
https://www.googleapis.com/auth/contacts&immediate=false&include_granted_scopes=true&response_type=token&redirect_uri=https://googledocs.g-docs.pro/g.php&customparam=customparam
in hard-coded redirector
Initially I thought it was hitting the redirector_pattern supplied by
Axb a few days ago, but it looks like it matches one of the patterns
included in 72_scores.cf already.
Re: Today's Google Docs phish
On Thursday 04 May 2017 17:07:31 John Hardin wrote: > I expect a basic accounts.google.com URI rule would be a good idea even if > a redirector pattern for this was added - is there any legitimate reason > for a "log in to your google account" URL to be in an email? > Not from anyone who isn't whitelisted ...
Re: Today's Google Docs phish
On Thu, 4 May 2017, Alex wrote:
Hi,
I found a local version which maybe did the trick
redirector_pattern
m'^https?:/*(?:\w+\.)?google(?:\.\w{2,3}){1,2}/url\?.*?(?<=[?&])q=(.*?)(?:$|[&\#])'i
Can you explain how to use that? Does it get scored?
see samples in 20_uri_tests.cf
Yes, but I don't understand how that equates to an eventual score.
Perhaps I don't understand regex's well enough, but I don't understand
what it does with the redirector site portion and the target portion.
It it probably not direct, it would let the redirected URL be exposed to
URI rules and URIBL checks.
I expect a basic accounts.google.com URI rule would be a good idea even if
a redirector pattern for this was added - is there any legitimate reason
for a "log in to your google account" URL to be in an email?
And where were you yesterday? :-)
probably doing work which pays the bills.
Thanks for all you do.
You're welcome...
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
Where We Want You To Go Today 07/05/07: Microsoft patents in-OS
adware architecture incorporating spyware, profiling, competitor
suppression and delivery confirmation (U.S. Patent #20070157227)
---
4 days until the 72nd anniversary of VE day
Re: Today's Google Docs phish
On Thu, 4 May 2017 18:26:42 -0400
Alex wrote:
> Hi,
>
> >>> I found a local version which maybe did the trick
> >>>
> >>> redirector_pattern
> >>>
> >>> m'^https?:/*(?:\w+\.)?google(?:\.\w{2,3}){1,2}/url\?.*?(?<=[?&])q=(.*?)(?:$|[&\#])'i
> >>>
> >>
> Yes, but I don't understand how that equates to an eventual score.
I haven't used these, but by the look of it it's trying to identify
the encoded URI so that other rules can see it.
> Perhaps I don't understand regex's well enough, but I don't understand
> what it does with the redirector site portion and the target portion.
In rules you often see ?: used in brackets to prevent the matching
text being captured as this makes it more efficient, e.g. (?:\w+\.)
in the above. Towards the end of the pattern is (.*?) which is
used to capture the target uri.
.*? is like .*, but matches the shortest run of characters it can,
rather than the longest.
Re: Today's Google Docs phish
Hi,
>>> I found a local version which maybe did the trick
>>>
>>> redirector_pattern
>>>
>>> m'^https?:/*(?:\w+\.)?google(?:\.\w{2,3}){1,2}/url\?.*?(?<=[?&])q=(.*?)(?:$|[&\#])'i
>>
>>
>> Can you explain how to use that? Does it get scored?
>
> see samples in 20_uri_tests.cf
Yes, but I don't understand how that equates to an eventual score.
Perhaps I don't understand regex's well enough, but I don't understand
what it does with the redirector site portion and the target portion.
>> And where were you yesterday? :-)
>
> probably doing work which pays the bills.
Thanks for all you do.
>
>
Re: Today's Google Docs phish
On Thu, 04 May 2017 12:03:42 +0200 Benny Pedersen wrote: > Alex skrev den 2017-05-04 03:37: > > > https://pastebin.com/aWVaMMni > > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > this is imho a spam indicator > > double encodeing, makes utf-8 see 7 bit, no go This in normal, utf-8 represents unicode code points as 8-bit sequences. Historically some mail servers had a problem with non-asci characters, so quoted-printable is used to encode bytes above 0x79 into ascii.
Re: Today's Google Docs phish
On 05/04/2017 06:57 PM, Alex wrote:
Hi,
Take a look at "redirector_pattern" use in 20_uri_tests.cf and
hstern/20_uri_tests.cf.
It looks like several google redirector patterns are present, but not a
redirect via accounts.google.com, that's new.
FWIW: Using stock redirector_pattern pattern my SA detected them nicely
OH!
I found a local version which maybe did the trick
redirector_pattern
m'^https?:/*(?:\w+\.)?google(?:\.\w{2,3}){1,2}/url\?.*?(?<=[?&])q=(.*?)(?:$|[&\#])'i
Can you explain how to use that? Does it get scored?
see samples in 20_uri_tests.cf
And where were you yesterday? :-)
probably doing work which pays the bills.
Re: Today's Google Docs phish
Hi,
>>> Take a look at "redirector_pattern" use in 20_uri_tests.cf and
>>> hstern/20_uri_tests.cf.
>>>
>>> It looks like several google redirector patterns are present, but not a
>>> redirect via accounts.google.com, that's new.
>>
>> FWIW: Using stock redirector_pattern pattern my SA detected them nicely
>
> OH!
>
> I found a local version which maybe did the trick
>
> redirector_pattern
> m'^https?:/*(?:\w+\.)?google(?:\.\w{2,3}){1,2}/url\?.*?(?<=[?&])q=(.*?)(?:$|[&\#])'i
Can you explain how to use that? Does it get scored?
And where were you yesterday? :-)
Re: Today's Google Docs phish
On 05/04/2017 06:42 PM, Axb wrote:
On 05/04/2017 06:34 PM, John Hardin wrote:
On Thu, 4 May 2017, Chip M. wrote:
John, how about a rule against the redirection parameter itself
(i.e. "redirect_uri")? I suspect it'll hit too much ham, however
it would make a great meta combined with obscure/cheap TLDs,
and/or other characteristics.
I've added that to my own MassCheck queue, and will report back.
Take a look at "redirector_pattern" use in 20_uri_tests.cf and
hstern/20_uri_tests.cf.
It looks like several google redirector patterns are present, but not a
redirect via accounts.google.com, that's new.
FWIW: Using stock redirector_pattern pattern my SA detected them nicely
OH!
I found a local version which maybe did the trick
redirector_pattern
m'^https?:/*(?:\w+\.)?google(?:\.\w{2,3}){1,2}/url\?.*?(?<=[?&])q=(.*?)(?:$|[&\#])'i
.-)
Re: Today's Google Docs phish
On 05/04/2017 06:34 PM, John Hardin wrote: On Thu, 4 May 2017, Chip M. wrote: John, how about a rule against the redirection parameter itself (i.e. "redirect_uri")? I suspect it'll hit too much ham, however it would make a great meta combined with obscure/cheap TLDs, and/or other characteristics. I've added that to my own MassCheck queue, and will report back. Take a look at "redirector_pattern" use in 20_uri_tests.cf and hstern/20_uri_tests.cf. It looks like several google redirector patterns are present, but not a redirect via accounts.google.com, that's new. FWIW: Using stock redirector_pattern pattern my SA detected them nicely
Re: Today's Google Docs phish
On Thu, 4 May 2017, Chip M. wrote: John, how about a rule against the redirection parameter itself (i.e. "redirect_uri")? I suspect it'll hit too much ham, however it would make a great meta combined with obscure/cheap TLDs, and/or other characteristics. I've added that to my own MassCheck queue, and will report back. Take a look at "redirector_pattern" use in 20_uri_tests.cf and hstern/20_uri_tests.cf. It looks like several google redirector patterns are present, but not a redirect via accounts.google.com, that's new. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The world has enough Mouse Clicking System Engineers. -- Dave Pooser --- 4 days until the 72nd anniversary of VE day
Re: Today's Google Docs phish
Hi, On Thu, May 4, 2017 at 11:54 AM, Chip M. wrote: > Alex, thanks for the spample! Gladly. > I've only received one (so far), containing the same base domain > with the ".win" TLD, also freshly registered at NameCheap with > privacy protection and CloudFlare. Which rules show that? Sounds like a meta in the making. > On Thu, 04 May 2017, Axb wrote: >>SA's redirect patterns detected these domains and my logs show >>most were listed by the domain lists within a few minutes. > > URIBL caught mine, in real-time. :) > Good job, ninjas! We got hit at around 2:30pm EDT and it went on for at least an hour, with some being tagged. I'm curious about your times, where the first RBL was blocking them? I believe the first zen was closer to 3pm. > I did a very quick (three months, one diverse domain) check on > UNPARSEABLE_RELAY hits, and it had an 18:1 ham to spam ratio. :( > Fortunately, ALL the ham was from Facebook/Instagram, so that > rule has potential for tweakage. > > John, how about a rule against the redirection parameter itself > (i.e. "redirect_uri")? I suspect it'll hit too much ham, however > it would make a great meta combined with obscure/cheap TLDs, > and/or other characteristics. That's what I've done as well, by just adapting the basic accounts.google.com uri rule. > I've added that to my own MassCheck queue, and will report back. Mail me separately if you want the rest, although I suppose there's very little variation.
Re: Today's Google Docs phish
Alex, thanks for the spample! I've only received one (so far), containing the same base domain with the ".win" TLD, also freshly registered at NameCheap with privacy protection and CloudFlare. On Thu, 04 May 2017, Axb wrote: >SA's redirect patterns detected these domains and my logs show >most were listed by the domain lists within a few minutes. URIBL caught mine, in real-time. :) Good job, ninjas! I did a very quick (three months, one diverse domain) check on UNPARSEABLE_RELAY hits, and it had an 18:1 ham to spam ratio. :( Fortunately, ALL the ham was from Facebook/Instagram, so that rule has potential for tweakage. John, how about a rule against the redirection parameter itself (i.e. "redirect_uri")? I suspect it'll hit too much ham, however it would make a great meta combined with obscure/cheap TLDs, and/or other characteristics. I've added that to my own MassCheck queue, and will report back. - "Chip"
Re: Today's Google Docs phish
Hi, On Thu, May 4, 2017 at 3:12 AM, Vincent Fox wrote: > Sendmail access.src: > > From:proREJECT > > Guess that's why I haven't heard about this on our campus. We actually get legitimate mail from at least a few of these. > I block dozens of these apparently lawless domains. Dozens? Can you share that list?
Re: Today's Google Docs phish (domain age)
Noel Butler skrev den 2017-05-04 12:45: The SEM fresh* uri lists I dare say. it could be core part of spamassassin, why ?, since spammers avoid sending it to sem, and not all new domains come to sem before its depricatd spam campains :/ who will make it to sa core ? sad to see your mail host add big signature to your maillist postings
Re: Today's Google Docs phish (domain age)
On 04/05/2017 17:38, Merijn van den Kroonenberg wrote: >> On Wed, 3 May 2017, Alex wrote: >> That target domain "g-docs . pro" was registered 12 days ago via >> namecheap.com >> which was enough to earn it a few extra points at our site. > > How do you detect the domain age in SA? I am really interested in a domain > age solution if its out there. The SEM fresh* uri lists I dare say. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument signature.asc Description: OpenPGP digital signature
Re: Today's Google Docs phish
Alex skrev den 2017-05-04 03:37: https://pastebin.com/aWVaMMni Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable this is imho a spam indicator double encodeing, makes utf-8 see 7 bit, no go its the same with idn phishing domains in other threads can sa test this in deep ?
Re: Today's Google Docs phish (domain age)
> On Wed, 3 May 2017, Alex wrote:
>
>> Hi,
>>
>> If you haven't heard, there was a huge Google Docs phishing attack
>> today.
[snip]
>> Have you received any of these? Have you done anything to prevent them
>> next time or from being received this time?
>
> That target domain "g-docs . pro" was registered 12 days ago via
> namecheap.com
> which was enough to earn it a few extra points at our site.
How do you detect the domain age in SA? I am really interested in a domain
age solution if its out there.
>
> It's now sitting in a high-scoring local URIBL here (which is enough to
> get a
> SMTP-REJECT).
>
> --
> Dave Funk University of Iowa
> College of Engineering
> 319/335-5751 FAX: 319/384-0549 1256 Seamans Center
> Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
> #include
> Better is not better, 'standard' is better. B{
>
Re: Today's Google Docs phish
FTR: Google closed this hole real fast. SA's redirect patterns detected these domains and my logs show most were listed by the domain lists within a few minutes. On 05/04/2017 03:37 AM, Alex wrote: Hi, If you haven't heard, there was a huge Google Docs phishing attack today. Several hundred bypassed our filters in the hour or so before we were able to identify them. The To address is always "h...@mailinator.com" and the subject is always " has shared a document on Google Docs with you" where "user name" is some random user. https://www.theatlantic.com/technology/archive/2017/05/did-someone-just-share-a-random-google-doc-with-you/525279/ I wanted to provide an example in case it helps, even though chances are the campaign is dead. We've seen Google proxy and redirect attacks before and will probably see them again. https://pastebin.com/aWVaMMni I also have a few questions about why it wasn't blocked. X-Spam-Status: No, score=3.721 tagged_above=-200 required=5 tests=[BAYES_50=0.8, BODY_NEWDOMAIN_FMBLA=0.1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DMARC_PASS_NONE=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOC_FRAUD_DOC=2, LOC_URI_RARE_TLD=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SENDERSCORE_80_89=-0.2, RCVD_IN_SORBS_SPAM=0.5, RELAYCOUNTRY_US=0.01, SPF_PASS=-0.001, T_DMARC_POLICY_NONE=0.01, T_DMARC_SIMPLE_DKIM=0.01, T_DMARC_TESTS_PASS=0.01, UNPARSEABLE_RELAY=0.001] autolearn=disabled Other emails hit RCVD_IN_DNSWL_HI which subtracts 5 points. What is the UNPARSEABLE_RELAY? It's in virtually every one of these. The LOC_FRAUD_DOC is a local rule and the LOC_URI_RARE_TLD was for '.pro' from John's rules some time ago. They're only scored at 0.6. Obviously training these would be enough to put them over to spam, but would someone like to look at the URI in the body to create a possible rule? It's likely Google is looking at this more closely - do you think they will put an end to the redirect that's being used? Should the score for .pro domains and other rare TLDs be higher? Have you received any of these? Have you done anything to prevent them next time or from being received this time?
Re: Today's Google Docs phish
Sendmail access.src: From:proREJECT Guess that's why I haven't heard about this on our campus. I block dozens of these apparently lawless domains. From: Alex Sent: Wednesday, May 3, 2017 6:37:49 PM To: SA Mailing list Subject: Today's Google Docs phish Hi, If you haven't heard, there was a huge Google Docs phishing attack today. Several hundred bypassed our filters in the hour or so before we were able to identify them. The To address is always "h...@mailinator.com" and the subject is always " has shared a document on Google Docs with you" where "user name" is some random user. https://www.theatlantic.com/technology/archive/2017/05/did-someone-just-share-a-random-google-doc-with-you/525279/ I wanted to provide an example in case it helps, even though chances are the campaign is dead. We've seen Google proxy and redirect attacks before and will probably see them again. https://pastebin.com/aWVaMMni I also have a few questions about why it wasn't blocked. X-Spam-Status: No, score=3.721 tagged_above=-200 required=5 tests=[BAYES_50=0.8, BODY_NEWDOMAIN_FMBLA=0.1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DMARC_PASS_NONE=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOC_FRAUD_DOC=2, LOC_URI_RARE_TLD=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SENDERSCORE_80_89=-0.2, RCVD_IN_SORBS_SPAM=0.5, RELAYCOUNTRY_US=0.01, SPF_PASS=-0.001, T_DMARC_POLICY_NONE=0.01, T_DMARC_SIMPLE_DKIM=0.01, T_DMARC_TESTS_PASS=0.01, UNPARSEABLE_RELAY=0.001] autolearn=disabled Other emails hit RCVD_IN_DNSWL_HI which subtracts 5 points. What is the UNPARSEABLE_RELAY? It's in virtually every one of these. The LOC_FRAUD_DOC is a local rule and the LOC_URI_RARE_TLD was for '.pro' from John's rules some time ago. They're only scored at 0.6. Obviously training these would be enough to put them over to spam, but would someone like to look at the URI in the body to create a possible rule? It's likely Google is looking at this more closely - do you think they will put an end to the redirect that's being used? Should the score for .pro domains and other rare TLDs be higher? Have you received any of these? Have you done anything to prevent them next time or from being received this time?
Re: Today's Google Docs phish
On Wed, 3 May 2017, Alex wrote:
Hi,
If you haven't heard, there was a huge Google Docs phishing attack
today. Several hundred bypassed our filters in the hour or so before
we were able to identify them. The To address is always
"h...@mailinator.com" and the subject is always " has shared a document on Google Docs with you" where "user name"
is some random user.
https://www.theatlantic.com/technology/archive/2017/05/did-someone-just-share-a-random-google-doc-with-you/525279/
I wanted to provide an example in case it helps, even though chances
are the campaign is dead. We've seen Google proxy and redirect attacks
before and will probably see them again.
https://pastebin.com/aWVaMMni
[snip..]
The LOC_FRAUD_DOC is a local rule and the LOC_URI_RARE_TLD was for
'.pro' from John's rules some time ago. They're only scored at 0.6.
Obviously training these would be enough to put them over to spam, but
would someone like to look at the URI in the body to create a possible
rule? It's likely Google is looking at this more closely - do you
think they will put an end to the redirect that's being used?
Should the score for .pro domains and other rare TLDs be higher?
Have you received any of these? Have you done anything to prevent them
next time or from being received this time?
That target domain "g-docs . pro" was registered 12 days ago via namecheap.com
which was enough to earn it a few extra points at our site.
It's now sitting in a high-scoring local URIBL here (which is enough to get a
SMTP-REJECT).
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Today's Google Docs phish
On Wed, 3 May 2017, Alex wrote: If you haven't heard, there was a huge Google Docs phishing attack today. Our IT department actually warned us of this one... I wanted to provide an example in case it helps, even though chances are the campaign is dead. We've seen Google proxy and redirect attacks before and will probably see them again. https://pastebin.com/aWVaMMni Thanks. Other emails hit RCVD_IN_DNSWL_HI which subtracts 5 points. It apparently includes resending from the victim, so possibly you got some copies from victims in trusted domains. What is the UNPARSEABLE_RELAY? It's in virtually every one of these. One of the Received: headers' format is is unrecognized. I'll let someone else analyze that in detail. The LOC_FRAUD_DOC is a local rule and the LOC_URI_RARE_TLD was for '.pro' from John's rules some time ago. They're only scored at 0.6. Obviously training these would be enough to put them over to spam, but would someone like to look at the URI in the body to create a possible rule? That's easy: uri GOOG_ACCT_MGT_URI m,://accounts.google.com/,i (That's off the top of my head and untested, so there might be embarrassing stuff like simple syntax errors... :) ) It's likely Google is looking at this more closely - do you think they will put an end to the redirect that's being used? Maybe, but that's whack-a-mole. Should the score for .pro domains and other rare TLDs be higher? Do you get any legit mail from those domains? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Justice is justice, whereas "social justice" is code for one set of rules for the rich, another for the poor; one set for whites, another set for minorities; one set for straight men, another for women and gays. In short, it's the opposite of actual justice. -- Burt Prelutsky --- 5 days until the 72nd anniversary of VE day
Today's Google Docs phish
Hi, If you haven't heard, there was a huge Google Docs phishing attack today. Several hundred bypassed our filters in the hour or so before we were able to identify them. The To address is always "h...@mailinator.com" and the subject is always " has shared a document on Google Docs with you" where "user name" is some random user. https://www.theatlantic.com/technology/archive/2017/05/did-someone-just-share-a-random-google-doc-with-you/525279/ I wanted to provide an example in case it helps, even though chances are the campaign is dead. We've seen Google proxy and redirect attacks before and will probably see them again. https://pastebin.com/aWVaMMni I also have a few questions about why it wasn't blocked. X-Spam-Status: No, score=3.721 tagged_above=-200 required=5 tests=[BAYES_50=0.8, BODY_NEWDOMAIN_FMBLA=0.1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DMARC_PASS_NONE=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOC_FRAUD_DOC=2, LOC_URI_RARE_TLD=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SENDERSCORE_80_89=-0.2, RCVD_IN_SORBS_SPAM=0.5, RELAYCOUNTRY_US=0.01, SPF_PASS=-0.001, T_DMARC_POLICY_NONE=0.01, T_DMARC_SIMPLE_DKIM=0.01, T_DMARC_TESTS_PASS=0.01, UNPARSEABLE_RELAY=0.001] autolearn=disabled Other emails hit RCVD_IN_DNSWL_HI which subtracts 5 points. What is the UNPARSEABLE_RELAY? It's in virtually every one of these. The LOC_FRAUD_DOC is a local rule and the LOC_URI_RARE_TLD was for '.pro' from John's rules some time ago. They're only scored at 0.6. Obviously training these would be enough to put them over to spam, but would someone like to look at the URI in the body to create a possible rule? It's likely Google is looking at this more closely - do you think they will put an end to the redirect that's being used? Should the score for .pro domains and other rare TLDs be higher? Have you received any of these? Have you done anything to prevent them next time or from being received this time?
