On 27/06/2011 5:35 PM, Axb wrote:
On 2011-06-27 23:28, Warren Togami Jr. wrote:
On 6/27/2011 11:22 AM, dar...@chaosreigns.com wrote:
Who has the access to do an emergency sa-update? Is it only Daryl?
AFAIK only Daryl knows how to do it. The last time I tried to follow
documented procedure I
On 27/06/2011 7:08 PM, Warren Togami Jr. wrote:
On 6/27/2011 1:01 PM, Kevin A. McGrail wrote:
How often does auto-push happen?
According to http://wiki.apache.org/spamassassin/SaUpdateBackend, it
occurs nightly at 0830 UTC approximately 9.5 hours from now. Checking
the actual file appears to
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6549
Adam Katz changed:
What|Removed |Added
CC||antis...@khopis.com
--- Comment #2
On 6/27/2011 1:01 PM, Kevin A. McGrail wrote:
How often does auto-push happen?
According to http://wiki.apache.org/spamassassin/SaUpdateBackend, it
occurs nightly at 0830 UTC approximately 9.5 hours from now. Checking
the actual file appears to concur.
Looking at updatesd's crontab shows ther
That's how the March 2011 trouble happened.
I think the March trouble occurred because nopublish was removed and
#testrules added and then #testrules didn't work as expected. The
code definitely does not agree with what others appear to think it
should do.
FYI, according to http://wiki.apach
How often does auto-push happen?
According to http://wiki.apache.org/spamassassin/SaUpdateBackend, it
occurs nightly at 0830 UTC approximately 9.5 hours from now. Checking
the actual file appears to concur.
Looking at updatesd's crontab shows there might be a second script that
runs at 085
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6527
--- Comment #5 from Kevin A. McGrail 2011-06-27 22:48:43
UTC ---
(In reply to comment #2)
> Additional problems:
>
> 1 - 70_sandbox.cf is not correct from the fixes in 6297 which leave rules out
> of masscheck
>
> 2 - remnants of rule
We have 211 published T_ prefix rules and 16 other rules that depend on
T_ rules.
Where T_ rules should be published or run is something in this bug
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6527
I think they are development only as you can see in my comment #2. I
support not p
On 6/27/2011 12:37 PM, Kevin A. McGrail wrote:
I can accept everything else you wrote, but we should push a new rule
update ASAP to eliminate the SEM DNS queries and also remove SOUGHT.
Whether this is called "emergency" or not it doesn't matter.
I do not show SOUGHT in Channel 1139459.
Ah,
I can
accept everything else you wrote, but we should push a new rule
update ASAP to eliminate the SEM DNS queries and also remove
SOUGHT. Whether this is called "emergency" or not it doesn't
matter.
I do not show SOUGHT in Channel 1139459.
On 6/20/2011 4:41 AM, Yet Another Ninja wrote:
I was assuming that rules named T_* would be in "testing" mode and
would not be plublished in daily snapshots.
After installing a snapshot I see stuff like
,T_RCVD_IN_SEMBLACK,T_SURBL_MULTI1,T_SURBL_MULTI2,T_URIBL_BLACK_OVERLAP,T_URIBL_SEM,T_URIBL_
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6560
Kevin A. McGrail changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6220
Kevin A. McGrail changed:
What|Removed |Added
CC||kmcgr...@pccc.com
--- Commen
On 6/27/2011 12:21 PM, Kevin A. McGrail wrote:
BTW, r1104058 rules were generated prior to June 11th when jm
completely removed JM_SOUGHT_FRAUD* and __SEEK_FRAUD* in order to
eliminate the sa-update channel ordering issue. As we are pushing an
emergency rule update anyway, we should take this opp
On 6/27/2011 5:43 PM, Blaine Fleming wrote:
On 6/27/2011 3:26 PM, Warren Togami Jr. wrote:
http://www.spamtips.org/2011/06/emergency-sem-rules-mistaken-enabled.html
And now it is back again, except as T_ rules, which is just as bad
because it is causing an unexpected flood of DNS traffic to SEM.
On 6/27/2011 6:03 PM, Warren Togami Jr. wrote:
On 6/27/2011 11:52 AM, Kevin A. McGrail wrote:
It's back as a T_rule because someone removed(?) the nopublish flag.
SEM was supposed to be a net nopublish rule.
So the publication as T_RULE is not a bug in the code but "correct"
behavior because t
Not sure which bug to post this to or if it's fully relevant, but here's
a quick grep of the current 3.3.1 sa-updates tarball:
% host -ttxt 1.3.3.updates.spamassassin.org.
1.3.3.updates.spamassassin.org descriptive text "1139740"
% host -ttxt mirrors.updates.spamassassin.org.
mirrors.updates.spa
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6560
--- Comment #11 from Warren Togami 2011-06-27 22:09:03 UTC
---
(In reply to comment #10)
>
> As they were flagged as T_ which is what the cf file said to do, I wouldn't
> have flagged it as wrong. A few DNS queries don't bug me and it
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6560
Kevin A. McGrail changed:
What|Removed |Added
CC||kmcgr...@pccc.com
--- Commen
On 6/27/2011 11:52 AM, Kevin A. McGrail wrote:
It's back as a T_rule because someone removed(?) the nopublish flag.
SEM was supposed to be a net nopublish rule.
So the publication as T_RULE is not a bug in the code but "correct"
behavior because the sandbox is missing the nopublish flag because
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6560
Darxus changed:
What|Removed |Added
CC||dar...@chaosreigns.com
--- Comment #9
We were testing SEM in weekly masscheck for 2+ years now, which has
been entirely fine.
If we have been testing it for two years, isn't it time to cease the
tests? What are we hoping to gain? FYI, I don't mind that the information
http://www.spamtips.org/2011/03/sem-rules-mistakenly-enabled
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6297
Kevin A. McGrail changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6527
--- Comment #4 from Kevin A. McGrail 2011-06-27 21:50:08
UTC ---
> #testrules and "tflags nopublish" are two separate parameters. It seems
> #testrules in this case was only partially successful.
#testrules was completely succesful
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6297
Warren Togami changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIX
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6527
--- Comment #3 from Warren Togami 2011-06-27 21:47:24 UTC
---
(In reply to comment #2)
> Additional problems:
>
> 1 - 70_sandbox.cf is not correct from the fixes in 6297 which leave rules out
> of masscheck
>
> 2 - remnants of rules t
On 6/27/2011 3:26 PM, Warren Togami Jr. wrote:
> http://www.spamtips.org/2011/06/emergency-sem-rules-mistaken-enabled.html
> And now it is back again, except as T_ rules, which is just as bad
> because it is causing an unexpected flood of DNS traffic to SEM.
>
> We need an emergency rule update to
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6527
Kevin A. McGrail changed:
What|Removed |Added
CC||kmcgr...@pccc.com
--- Commen
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6297
Kevin A. McGrail changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 2011-06-27 23:28, Warren Togami Jr. wrote:
On 6/27/2011 11:22 AM, dar...@chaosreigns.com wrote:
Who has the access to do an emergency sa-update? Is it only Daryl?
AFAIK only Daryl knows how to do it. The last time I tried to follow
documented procedure I seriously screwed something up.
Wa
On 6/27/2011 11:22 AM, dar...@chaosreigns.com wrote:
Who has the access to do an emergency sa-update? Is it only Daryl?
AFAIK only Daryl knows how to do it. The last time I tried to follow
documented procedure I seriously screwed something up.
Warren
On 6/27/2011 11:15 AM, Kevin A. McGrail wrote:
Yes, it is incorrect behavior because while it isn't adding anything of
significance to the score it is still querying my public servers. I
don't think asking people to put another set of rules in to disable
rules that never should have been pushed
On 06/27, Blaine Fleming wrote:
> > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6560
> That requires an account and the account creation page states that it
> should be activated within three days. I'm really not feeling up to
> taking another week of abuse if I can avoid it.
Yup, I
Yes, it is incorrect behavior because while it isn't adding anything of
significance to the score it is still querying my public servers. I
don't think asking people to put another set of rules in to disable
rules that never should have been pushed is acceptable.
This is the second time it has
On 6/27/2011 10:39 AM, Kevin A. McGrail wrote:
In short, this sounds like things are working and unless Blaine is
seeing a rule being published that isn't T_*, we don't have an issue.
Things are not working properly, and unfortunately we need to do an
emergency sa-update push.
score T_RCVD_
On 2011-06-27 23:00, Blaine Fleming wrote:
On 6/27/2011 2:39 PM, Kevin A. McGrail wrote:
Sorry for posting to both dev and users but it looks like the SEM
lists have been pushed into production rules again and are showing up
in 72_active.cf under 3.3.1. This happened around 23:00 (GMT-4) last
On 6/27/2011 11:00 AM, Blaine Fleming wrote:
On 6/27/2011 2:39 PM, Kevin A. McGrail wrote:
Sorry for posting to both dev and users but it looks like the SEM
lists have been pushed into production rules again and are showing up
in 72_active.cf under 3.3.1. This happened around 23:00 (GMT-4) la
On 6/27/2011 2:39 PM, Kevin A. McGrail wrote:
>
>> Sorry for posting to both dev and users but it looks like the SEM
>> lists have been pushed into production rules again and are showing up
>> in 72_active.cf under 3.3.1. This happened around 23:00 (GMT-4) last
>> night. Someone fix that?
> Howe
On 6/27/2011 2:36 PM, dar...@chaosreigns.com wrote:
> On 06/27, Blaine Fleming wrote:
>> Sorry for posting to both dev and users but it looks like the SEM
>> lists have been pushed into production rules again and are showing up
>> in 72_active.cf under 3.3.1. This happened around 23:00 (GMT-4) las
Sorry for posting to both dev and users but it looks like the SEM
lists have been pushed into production rules again and are showing up
in 72_active.cf under 3.3.1. This happened around 23:00 (GMT-4) last
night. Someone fix that?
Thanks Blaine, There is a go
On 06/27, Blaine Fleming wrote:
> Sorry for posting to both dev and users but it looks like the SEM
> lists have been pushed into production rules again and are showing up
> in 72_active.cf under 3.3.1. This happened around 23:00 (GMT-4) last
> night. Someone fix that?
The (apparently never clos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry for posting to both dev and users but it looks like the SEM
lists have been pushed into production rules again and are showing up
in 72_active.cf under 3.3.1. This happened around 23:00 (GMT-4) last
night. Someone fix that?
- --Blaine
-B
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6614
Giampaolo Tomassoni changed:
What|Removed |Added
CC||giampa...@tomassoni.biz
-
43 matches
Mail list logo
