On 7/30/2014 4:49 PM, John Hardin wrote:
On Wed, 30 Jul 2014, Kevin A. McGrail wrote:
On 7/30/2014 12:15 PM, John Hardin wrote:
> According to the wiki, "rules without an explicit "tflags
publish" line > are never published", >
https://wiki.apache.org/spamassassin/SaUpdateBackend
...whic
On Wed, 30 Jul 2014, Kevin A. McGrail wrote:
On 7/30/2014 12:15 PM, John Hardin wrote:
> According to the wiki, "rules without an explicit "tflags publish" line
> are never published",
> https://wiki.apache.org/spamassassin/SaUpdateBackend
...which isn't actually how it behaves, as there
On 07/30/2014 09:04 PM, Kevin A. McGrail wrote:
On 7/30/2014 12:15 PM, John Hardin wrote:
According to the wiki, "rules without an explicit "tflags publish"
line are never published",
https://wiki.apache.org/spamassassin/SaUpdateBackend
...which isn't actually how it behaves, as there are quit
On 7/30/2014 4:11 PM, Axb wrote:
On 07/30/2014 09:04 PM, Kevin A. McGrail wrote:
On 7/30/2014 12:15 PM, John Hardin wrote:
According to the wiki, "rules without an explicit "tflags publish"
line are never published",
https://wiki.apache.org/spamassassin/SaUpdateBackend
...which isn't actually
On 7/30/2014 12:15 PM, John Hardin wrote:
According to the wiki, "rules without an explicit "tflags publish"
line are never published",
https://wiki.apache.org/spamassassin/SaUpdateBackend
...which isn't actually how it behaves, as there are quite a few rules
in my sandbox that don't have "tf
On Wed, 30 Jul 2014, Kevin A. McGrail wrote:
On 7/30/2014 11:45 AM, Axb wrote:
--- 20_misc_testing.cf(revision 1614687)
+++ 20_misc_testing.cf(revision 1614688)
@@ -1572,5 +1572,6 @@
uriURI_IP_UNSUB m;^[a-z]+://(?:\d+\.){3}\d+/.*unsubscribe;i
describe URI_IP_
On Wed, 30 Jul 2014, Axb wrote:
--- 20_misc_testing.cf (revision 1614687)
+++ 20_misc_testing.cf (revision 1614688)
@@ -1572,5 +1572,6 @@
uriURI_IP_UNSUB m;^[a-z]+://(?:\d+\.){3}\d+/.*unsubscribe;i
describe URI_IP_UNSUB IP-address unsubscribe URI
+tflags URI_IP_U
On 07/30/2014 05:55 PM, Kevin A. McGrail wrote:
On 7/30/2014 11:45 AM, Axb wrote:
--- 20_misc_testing.cf(revision 1614687)
+++ 20_misc_testing.cf(revision 1614688)
@@ -1572,5 +1572,6 @@
uriURI_IP_UNSUB m;^[a-z]+://(?:\d+\.){3}\d+/.*unsubscribe;i
describe URI_IP_UNS
On 7/30/2014 11:45 AM, Axb wrote:
--- 20_misc_testing.cf(revision 1614687)
+++ 20_misc_testing.cf(revision 1614688)
@@ -1572,5 +1572,6 @@
uriURI_IP_UNSUB m;^[a-z]+://(?:\d+\.){3}\d+/.*unsubscribe;i
describe URI_IP_UNSUB IP-address unsubscribe URI
+tflags
--- 20_misc_testing.cf (revision 1614687)
+++ 20_misc_testing.cf (revision 1614688)
@@ -1572,5 +1572,6 @@
uriURI_IP_UNSUB
m;^[a-z]+://(?:\d+\.){3}\d+/.*unsubscribe;i
describe URI_IP_UNSUB IP-address unsubscribe URI
+tflags URI_IP_UNSUB publish
http://ru
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7063
--- Comment #45 from Kevin A. McGrail ---
Per bug 7068 comment 6, the eval for this rule doesn't require the name of the
rule.
Removing that and improving the documentation.
svn commit -m 'Cleaned up documentation and removed rule nam
On Wed, 30 Jul 2014, Axb wrote:
The concept of this rule just tells me that it's wrong..
meta __TO_NO_BRKTS_MSFT __TO_NO_ARROWS_R && !__TO_UNDISCLOSED &&
(__ANY_OUTLOOK_MUA || __MIMEOLE_MS)
As I said, it's based on the assumption that MSFT codes to standards, i.e.
their tools *w
On 07/30/2014 05:17 PM, John Hardin wrote:
On Wed, 30 Jul 2014, Axb wrote:
Received: from DUB004-OMC4S34.hotmail.com (dub004-omc4s34.hotmail.com
[157.55.2.109])
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
This is what something like an "undisclosed recipients" looks like.
Do you hav
On 07/30/2014 05:05 PM, Kevin A. McGrail wrote:
On 7/30/2014 10:58 AM, Axb wrote:
On 07/30/2014 04:52 PM, Kevin A. McGrail wrote:
On 7/30/2014 10:50 AM, Axb wrote:
The concept of this rule just tells me that it's wrong..
meta __TO_NO_BRKTS_MSFT __TO_NO_ARROWS_R &&
!__TO_UNDISCLOSE
On Wed, 30 Jul 2014, Axb wrote:
Received: from DUB004-OMC4S34.hotmail.com (dub004-omc4s34.hotmail.com
[157.55.2.109])
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
This is what something like an "undisclosed recipients" looks like.
Do you have a sample of the headers, especially the T
On 7/30/2014 10:58 AM, Axb wrote:
On 07/30/2014 04:52 PM, Kevin A. McGrail wrote:
On 7/30/2014 10:50 AM, Axb wrote:
The concept of this rule just tells me that it's wrong..
meta __TO_NO_BRKTS_MSFT __TO_NO_ARROWS_R &&
!__TO_UNDISCLOSED && (__ANY_OUTLOOK_MUA || __MIMEOLE_MS)
welcome
On 07/30/2014 04:52 PM, Kevin A. McGrail wrote:
On 7/30/2014 10:50 AM, Axb wrote:
The concept of this rule just tells me that it's wrong..
meta __TO_NO_BRKTS_MSFT __TO_NO_ARROWS_R &&
!__TO_UNDISCLOSED && (__ANY_OUTLOOK_MUA || __MIMEOLE_MS)
welcome to 2014
"X-Mailer: Microsoft Wind
On 7/30/2014 10:50 AM, Axb wrote:
The concept of this rule just tells me that it's wrong..
meta __TO_NO_BRKTS_MSFT __TO_NO_ARROWS_R &&
!__TO_UNDISCLOSED && (__ANY_OUTLOOK_MUA || __MIMEOLE_MS)
welcome to 2014
"X-Mailer: Microsoft Windows Live Mail"
where is the exception for that
The concept of this rule just tells me that it's wrong..
meta __TO_NO_BRKTS_MSFT __TO_NO_ARROWS_R &&
!__TO_UNDISCLOSED && (__ANY_OUTLOOK_MUA || __MIMEOLE_MS)
welcome to 2014
"X-Mailer: Microsoft Windows Live Mail"
where is the exception for that? .-)
and if you add it so what? e
On 7/30/2014 10:03 AM, Axb wrote:
Well I show zero hits and so does your masscheck. I'd like to get a
sample to work on a reverse check that identifies Good messages.
even more patchwork? I don't like overworked metas with tons of
cycle/memory chewing dependencies.
You already solved the iss
On 07/30/2014 03:41 PM, Kevin A. McGrail wrote:
On 7/30/2014 9:19 AM, Axb wrote:
On 07/30/2014 02:57 PM, Kevin A. McGrail wrote:
Hmm,
Spotchecking Ruleqa doesn't show this misfiring at all:
http://ruleqa.spamassassin.org/20140729-r1614286-n/TO_NO_BRKTS_MSFT/detail
I have also got zero hits
On 7/30/2014 9:19 AM, Axb wrote:
On 07/30/2014 02:57 PM, Kevin A. McGrail wrote:
Hmm,
Spotchecking Ruleqa doesn't show this misfiring at all:
http://ruleqa.spamassassin.org/20140729-r1614286-n/TO_NO_BRKTS_MSFT/detail
I have also got zero hits in my ham corpora.
Suggest adding hit to your
On 07/30/2014 02:57 PM, Kevin A. McGrail wrote:
Hmm,
Spotchecking Ruleqa doesn't show this misfiring at all:
http://ruleqa.spamassassin.org/20140729-r1614286-n/TO_NO_BRKTS_MSFT/detail
I have also got zero hits in my ham corpora.
Suggest adding hit to your ham corpora and we check on it tomorr
Hmm,
Spotchecking Ruleqa doesn't show this misfiring at all:
http://ruleqa.spamassassin.org/20140729-r1614286-n/TO_NO_BRKTS_MSFT/detail
I have also got zero hits in my ham corpora.
Suggest adding hit to your ham corpora and we check on it tomorrow.
Regards,
KAM
Received: from DUB004-OMC4S34.hotmail.com (dub004-omc4s34.hotmail.com
[157.55.2.109])
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
This is what something like an "undisclosed recipients" looks like.
Imo, this rule scored with 3.5 should be purged. It's a waste of cycles
SpamAssassin version 3.3.0 has not had a rule update since 2014-07-28.
SpamAssassin version 3.3.1 has not had a rule update since 2014-07-28.
SpamAssassin version 3.3.2 has not had a rule update since 2014-07-28.
20140729: Spam or ham is below threshold of 150,000:
http://ruleqa.spamassassin.or
26 matches
Mail list logo
