https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #32 from Henrik Krohns ---
(In reply to Kevin A. McGrail from comment #31)
> Hah, I was just about to ask. Do you have it described in the UPGRADE and
> release notes?
It's mentioned in UPGRADE and of course the option is
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #31 from Kevin A. McGrail ---
Hah, I was just about to ask. Do you have it described in the UPGRADE and
release notes?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
Henrik Krohns changed:
What|Removed |Added
Target Milestone|Undefined |4.0.0
--- Comment #30 from Henrik
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
Henrik Krohns changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #28 from Henrik Krohns ---
Takes ages to follow and understand all the code and processing paths. :-(
The concept is now __global_state_dir__/dnsblock_$domain
I have no idea why t/cross_user_config_leak.t break. Things are
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #27 from Henrik Krohns ---
(In reply to RW from comment #25)
ssage?
>
> No, this is what happens when spamd works with unix users, as it might on a
> login server.
Ok I see what my problem was. Of course my spamd was running
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #26 from Henrik Krohns ---
Add __writable_state_dir__ to find the best place to share global state data
SendingSpamAssassin/AsyncLoop.pm
SendingSpamAssassin/Conf.pm
SendingSpamAssassin/PerMsgStatus.pm
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #25 from RW ---
(In reply to Henrik Krohns from comment #24)
> Are you suggesting that there are installations where users are not using
> spamc/spamd, but instead use standalone /usr/bin/spamassassin for every
> message?
No,
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #24 from Henrik Krohns ---
(In reply to RW from comment #22)
> (In reply to Henrik Krohns from comment #20)
>
> > unless someone has thousand users having
> > their own statedirs.
>
> That was my point.
It would be more
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #23 from AXB ---
why not place it where the install places local.cf ?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #22 from RW ---
(In reply to Henrik Krohns from comment #20)
> unless someone has thousand users having
> their own statedirs.
That was my point.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #21 from Henrik Krohns ---
Actually there's the __local_state_dir__ (/var/lib/spamassassin)
__local_state_dir__/__version__/updates_spamassassin_org
I kind of glanced at it, but though it might not always be writable. Spamd
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #20 from Henrik Krohns ---
Btw it's configurable..
userstate_dir
The new user's storage directory. (equivalent to C<~/.spamassassin>.)
There some virtual user stuff that I have no idea about. Maybe have to check
that too.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #19 from Henrik Krohns ---
(In reply to RW from comment #18)
> (In reply to Henrik Krohns from comment #16)
> > Block status is maintained across all processes by empty statefile
> > in
> > userstate directory
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
RW changed:
What|Removed |Added
CC||rwmailli...@googlemail.com
--- Comment #18
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #17 from AXB ---
(In reply to Henrik Krohns from comment #16)
> Well it took a while to come up with an "optimal" solution. Hopefully you
> will like this.
>
> Sendinglib/Mail/SpamAssassin/AsyncLoop.pm
> Sending
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #16 from Henrik Krohns ---
Well it took a while to come up with an "optimal" solution. Hopefully you will
like this.
Sendinglib/Mail/SpamAssassin/AsyncLoop.pm
Sendinglib/Mail/SpamAssassin/Conf.pm
Sending
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #14 from D. Stussy software+spamassas...@kd6lvw.ampr.org
2012-01-19 19:30:18 UTC ---
RFC 6471 was published recently. It has some things we may want to consider in
determining the status of a DNS based list:
Section 3.3:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #13 from Matthias Leisi matth...@leisi.net 2011-12-22 10:32:43
UTC ---
I did some additional tests on how best to block abusive query sources. Best
is defined as three goals:
1) Reduce the overall traffic on parent
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #12 from Darxus dar...@chaosreigns.com 2011-12-18 17:00:38 UTC ---
The reason for the special result code, as indicated in the posting referenced
above, is that REFUSED rcode will result in triple the amount of queries in
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
Matthias Leisi matth...@leisi.net changed:
What|Removed |Added
CC|
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
Darxus dar...@chaosreigns.com changed:
What|Removed |Added
CC|
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
Kevin A. McGrail kmcgr...@pccc.com changed:
What|Removed |Added
CC|
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #3 from Michael Parker park...@pobox.com 2011-12-15 15:55:08 UTC
---
I'm -1 on this idea unless you can figure out how to make it a plugin that is
disabled by default. You're solving a problem for a VERY SMALL percentage of
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #4 from Kevin A. McGrail kmcgr...@pccc.com 2011-12-15 15:57:09
UTC ---
(In reply to comment #3)
I'm -1 on this idea unless you can figure out how to make it a plugin that is
disabled by default. You're solving a problem
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
Henrik Krohns h...@hege.li changed:
What|Removed |Added
CC||h...@hege.li
---
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #6 from Henrik Krohns h...@hege.li 2011-12-15 17:22:17 UTC ---
(In reply to comment #5)
Proposed config block_disable would need to refer to identifier instead of a
rule name.
Correction.. since uribl etc doesn't have an
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
D. Stussy software+spamassas...@kd6lvw.ampr.org changed:
What|Removed |Added
CC|
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #8 from Kevin A. McGrail kmcgr...@pccc.com 2011-12-15 23:28:17
UTC ---
(In reply to comment #7)
In my opinion, blocked should ALSO trigger upon the affirmative receiving of
an A record OUTSIDE of 127.0.0.0/8, regardless of
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #9 from D. Stussy software+spamassas...@kd6lvw.ampr.org
2011-12-16 00:41:23 UTC ---
I get this part. We should make URIBL.pm and EvalDNS.pm flag ignore responses
outside of 127.0.0.1[sic] and possibly even trigger BLOCKED.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #10 from Kevin A. McGrail kmcgr...@pccc.com 2011-12-16 00:52:01
UTC ---
(In reply to comment #9)
I get this part. We should make URIBL.pm and EvalDNS.pm flag ignore
responses
outside of 127.0.0.1[sic] and possibly even
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #11 from D. Stussy software+spamassas...@kd6lvw.ampr.org
2011-12-16 01:51:18 UTC ---
So you want to trigger blocked for anything outside of 127.0.0/24 or 127/8?
Yes - to 127/8 (127.0.0.0/255.0.0.0). RFC 5782 permits
32 matches
Mail list logo
