> On Jul 14, 2020, at 12:08 PM, M. Omer GOLGELI <o...@chronos.com.tr> wrote:
>
> July 14, 2020 6:07 PM, "Kevin A. McGrail" <kmcgr...@apache.org> wrote:
>
>> The question you ask is exactly why we have the DNSBL Inclusion policy and
>> require the free for
>> some model.
>>
>> We might need to kick up the need for the BLOCKED rule with instructions in
>> that description on how
>> to disable the rules. What are your thoughts on that?
>>
>
> Don't get me wrong, I use them in the scoring process as well and I'm glad to
> use them along with a few others as I'm not that hard bent on keeping
> everything free.
>
> And if I hit the limits somehow, I'll either pay for them or turn them off.
>
> But there will always be people that doesn't want it.
> Or those who wouldn't want to see their OSS software relies on commercial
> products.
> Or there will be those who does this non-commercially.
> Or there will be people who installed it as part of their OSS mail product
> and doesn't know that there's such a limit etc.
>
> So for that matter, maybe these can be left for the admins decision to enable
> them after installation.
> Or all users should be made aware of these limitations in a better manner and
> clearly for each semi-commercial RBL used.
Since the consensus is that this is kind of a “turn it loose out of the box”
situation, I think a nice compromise would be huge commented chunks around
settings that would disable any commercial services that will start sending
nastygrams if you are outside of their (sometimes complex and kind of opaque
“free” use case).
I do so wish some of those folks would take spamtraps in trade. We see spam
from sources even the most expensive lists don’t see for at least 15-20 minutes
- valuable data, IMHO. :)
Charles
>
> </2¢>
>
>
>
>
>
>
> M. Omer GOLGELI
