Mailing List Archive

July 14, 2020 6:07 PM, "Kevin A. McGrail" <kmcgrail@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.

</2¢>






M. Omer GOLGELI

I agree with you about the idea of turning off everything and just
delivering 100% commented configuration files.. I believe SA is a
framework that must have walls & paint added to make it a house. Others
want it ready to go as a pre-fab house aka a drop-in spam filter. As a
project, the majority supports the drop-in model so I support the will of
the PMC. The DNSBlocklist inclusion policy from 2011 has served us well
with a lot of users and very few complaints. But if you think of edits it
might need, we can always improve it. DNS Blocklists and the free for some
model really help the drop in spam filter be effective.

Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Tue, Jul 14, 2020 at 12:08 PM M. Omer GOLGELI <omer@chronos.com.tr>
wrote:

> July 14, 2020 6:07 PM, "Kevin A. McGrail" <kmcgrail@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.
>
> </2¢>
>
>
>
>
>
>
> M. Omer GOLGELI
>

On 14 Jul 2020, at 9:53, Kevin A. McGrail wrote:

> I agree with you about the idea of turning off everything and just
> delivering 100% commented configuration files.. I believe SA is a
> framework that must have walls & paint added to make it a house.
> Others
> want it ready to go as a pre-fab house aka a drop-in spam filter. As
> a
> project, the majority supports the drop-in model so I support the will
> of
> the PMC. The DNSBlocklist inclusion policy from 2011 has served us
> well
> with a lot of users and very few complaints. But if you think of
> edits it
> might need, we can always improve it. DNS Blocklists and the free for
> some
> model really help the drop in spam filter be effective.

Are there any sort of numbers regarding how are the SA instances being
installed? Is it mostly for distros? Direct installs?

SA could ship the walls & paint as you describe, and leave to the
distros the activation of such features they think their users will
need, perhaps?

In my case, it is helpful to pull SA from a Debian package and have it
ready to go, with a reasonably complete configuration I can tweak.
Starting from an empty config would be more complex to my average use
case.

Best regards

-lem

On 7/14/2020 1:04 PM, Luis E. Muñoz wrote:
> Are there any sort of numbers regarding how are the SA instances being
> installed? Is it mostly for distros? Direct installs?
No.
> SA could ship the walls & paint as you describe, and leave to the
> distros the activation of such features they think their users will
> need, perhaps?
I've suggested this and been overruled.  I think it's a dead issue.
> In my case, it is helpful to pull SA from a Debian package and have it
> ready to go, with a reasonably complete configuration I can tweak.
> Starting from an empty config would be more complex to my average use
> case.

I think you are doing what a lot of people do.  And the distros that
stay up to date on releases, it's awesome.  Some of them backport
forever and it doesn't work very well.

Regards,

KAM

--
Kevin A. McGrail
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

> On Jul 14, 2020, at 12:08 PM, M. Omer GOLGELI <omer@chronos.com.tr> wrote:
>
> July 14, 2020 6:07 PM, "Kevin A. McGrail" <kmcgrail@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

I think documenting the simple way to disable it makes sense, yes. Which
command do you do that worked for you and I can look at adding it to a
3.4.5.pre file.
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Tue, Jul 14, 2020 at 1:34 PM Charles Sprickman <spork@bway.net> wrote:

>
>
> > On Jul 14, 2020, at 12:08 PM, M. Omer GOLGELI <omer@chronos.com.tr>
> wrote:
> >
> > July 14, 2020 6:07 PM, "Kevin A. McGrail" <kmcgrail@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
>
>

On Tue, 2020-07-14 at 12:53 -0400, Kevin A. McGrail wrote:
> I agree with you about the idea of turning off everything and just
> delivering 100% commented configuration files.. I believe SA is a
> framework that must have walls & paint added to make it a
> house. Others want it ready to go as a pre-fab house aka a drop-in
> spam filter. As a project, the majority supports the drop-in model so
> I support the will of the PMC. The DNSBlocklist inclusion policy from
> 2011 has served us well with a lot of users and very few
> complaints. But if you think of edits it might need, we can always
> improve it. DNS Blocklists and the free for some model really help
> the drop in spam filter be effective.
>
Maybe all that's needed is to better emphasize the point that that free
use of RBLs, whose use by SA is configured on by default, require the
user to have their own non-forwarding DNS installed and explain why.

This should go in:
- the online docs in the SA website
- SA manpages
- the standard SA configuration file included in the SA package

This info should include lots of black (hashmarks, asterisks etc). The
main thing is to put these warnings were they can't be missed - and some
people can miss almost anything.

As an added bonus, the SA installation package might include basic
config files for popular DNSes, say bind and unbound, that let it
support SA out of the box by simply:
(a) installing one of the supported DNS packages
(b) putting the supplied configuration where the DNS expects to find
it.

If the SA user wants their DNS to do more, they can read its docs and
add their own tweaks.

But the important point is to have SA docs say, in places that a new
user can't miss that "If you want free use of the default RBLs then
INSTALL YOUR OWN NON-FORWARDING DNS.

Martin


> Regards,
> KAM
> --
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
>
> On Tue, Jul 14, 2020 at 12:08 PM M. Omer GOLGELI <omer@chronos.com.tr>
> wrote:
>
> > July 14, 2020 6:07 PM, "Kevin A. McGrail" <kmcgrail@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.
> >
> > </2¢>
> >
> >
> >
> >
> >
> >
> > M. Omer GOLGELI
> >

Well, that is documented quite expressly here:
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/CachingNameserver

A pointer to the wiki might be useful in the config files as well as the
docs. Suggestions of which files?
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Tue, Jul 14, 2020 at 3:46 PM Martin Gregorie <martin@gregorie.org> wrote:

> On Tue, 2020-07-14 at 12:53 -0400, Kevin A. McGrail wrote:
> > I agree with you about the idea of turning off everything and just
> > delivering 100% commented configuration files.. I believe SA is a
> > framework that must have walls & paint added to make it a
> > house. Others want it ready to go as a pre-fab house aka a drop-in
> > spam filter. As a project, the majority supports the drop-in model so
> > I support the will of the PMC. The DNSBlocklist inclusion policy from
> > 2011 has served us well with a lot of users and very few
> > complaints. But if you think of edits it might need, we can always
> > improve it. DNS Blocklists and the free for some model really help
> > the drop in spam filter be effective.
> >
> Maybe all that's needed is to better emphasize the point that that free
> use of RBLs, whose use by SA is configured on by default, require the
> user to have their own non-forwarding DNS installed and explain why.
>
> This should go in:
> - the online docs in the SA website
> - SA manpages
> - the standard SA configuration file included in the SA package
>
> This info should include lots of black (hashmarks, asterisks etc). The
> main thing is to put these warnings were they can't be missed - and some
> people can miss almost anything.
>
> As an added bonus, the SA installation package might include basic
> config files for popular DNSes, say bind and unbound, that let it
> support SA out of the box by simply:
> (a) installing one of the supported DNS packages
> (b) putting the supplied configuration where the DNS expects to find
> it.
>
> If the SA user wants their DNS to do more, they can read its docs and
> add their own tweaks.
>
> But the important point is to have SA docs say, in places that a new
> user can't miss that "If you want free use of the default RBLs then
> INSTALL YOUR OWN NON-FORWARDING DNS.
>
> Martin
>
>
> > Regards,
> > KAM
> > --
> > Kevin A. McGrail
> > Member, Apache Software Foundation
> > Chair Emeritus Apache SpamAssassin Project
> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> >
> >
> > On Tue, Jul 14, 2020 at 12:08 PM M. Omer GOLGELI <omer@chronos.com.tr>
> > wrote:
> >
> > > July 14, 2020 6:07 PM, "Kevin A. McGrail" <kmcgrail@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.
> > >
> > > </2¢>
> > >
> > >
> > >
> > >
> > >
> > >
> > > M. Omer GOLGELI
> > >
>
>

On Tuesday 14 July 2020 at 21:46:11, Martin Gregorie wrote:

> This info should include lots of black (hashmarks, asterisks etc).

You should be careful of the language you use these days, especially on this
list.

Yes, I am being sarcastic about what you wrote, but I'm also being serious
about the apparent power of the language police.


Antony.

--
A user interface is like a joke.
If you have to explain it, it means it doesn't work.

Please reply to the list;
please *don't* CC me.

On Tue, 2020-07-14 at 22:59 +0200, Antony Stone wrote:
> On Tuesday 14 July 2020 at 21:46:11, Martin Gregorie wrote:
>
> > This info should include lots of black (hashmarks, asterisks etc).
>
> You should be careful of the language you use these days, especially
> on this
> list.
>
> Yes, I am being sarcastic about what you wrote, but I'm also being
> serious
> about the apparent power of the language police.
>
I don't underestimate the power of the thought police (McCarthy was the
standout example of *THAT*) or their, sometimes wilful, ignorance. You
know what I meant, but if I'd written something like "include big blocks
of attention-getting high-density characters", might that be interpreted
as an attack on the comprehensionally challenged?

Martin

On Tue, 14 Jul 2020 20:46:11 +0100
Martin Gregorie wrote:

> On Tue, 2020-07-14 at 12:53 -0400, Kevin A. McGrail wrote:
> > I agree with you about the idea of turning off everything and just
> > delivering 100% commented configuration files.. I believe SA is a
> > framework that must have walls & paint added to make it a
> > house. Others want it ready to go as a pre-fab house aka a drop-in
> > spam filter. As a project, the majority supports the drop-in model
> > so I support the will of the PMC. The DNSBlocklist inclusion
> > policy from 2011 has served us well with a lot of users and very few
> > complaints. But if you think of edits it might need, we can always
> > improve it. DNS Blocklists and the free for some model really help
> > the drop in spam filter be effective.
> >
> Maybe all that's needed is to better emphasize the point that that
> free use of RBLs, whose use by SA is configured on by default,
> require the user to have their own non-forwarding DNS installed and
> explain why.

That's a very different issue, and not a reason to have spamhaus off by
default.

The thread is about commercial users that are large enough to reach the
spamhaus limits with recursive lookups, but lack expertise in spam
filtering and SpamAssassin configuration.

Having 100% commented configuration files is only a solution if the
intent is to drive such organizations out of providing email altogether.

On Tuesday 14 July 2020 at 23:23:29, Martin Gregorie wrote:

> On Tue, 2020-07-14 at 22:59 +0200, Antony Stone wrote:
> > On Tuesday 14 July 2020 at 21:46:11, Martin Gregorie wrote:
> > > This info should include lots of black (hashmarks, asterisks etc).
> >
> > You should be careful of the language you use these days, especially
> > on this list.
> >
> > Yes, I am being sarcastic about what you wrote, but I'm also being
> > serious about the apparent power of the language police.
>
> I don't underestimate the power of the thought police (McCarthy was the
> standout example of *THAT*) or their, sometimes wilful, ignorance. You
> know what I meant, but if I'd written something like "include big blocks
> of attention-getting high-density characters", might that be interpreted
> as an attack on the comprehensionally challenged?

1. Yes, and those sectors of society defending the mentally deficient might be
somewhere back in the queue waiting their turn to have a bit of a go at us for
talking like this

2. My comment was not aimed at you in any way at all - it was an observation
to other people on this list about a different discussion thread which you may
have noticed in recent days (which, ironically enough, does include big blocks
of attention-getting high-density characters in its subject line).


Antony.

--
https://tools.ietf.org/html/rfc6890 - providing 16 million IPv4 addresses for
talking to yourself.

Please reply to the list;
please *don't* CC me.

Congrats on derailing another post needlessly.





M. Omer GOLGELI



July 15, 2020 12:41 AM, "Antony Stone" <Antony.Stone@spamassassin.open.source.it> wrote:

> On Tuesday 14 July 2020 at 23:23:29, Martin Gregorie wrote:
>
>> On Tue, 2020-07-14 at 22:59 +0200, Antony Stone wrote:
>> On Tuesday 14 July 2020 at 21:46:11, Martin Gregorie wrote:
>>> This info should include lots of black (hashmarks, asterisks etc).
>>
>> You should be careful of the language you use these days, especially
>> on this list.
>>
>> Yes, I am being sarcastic about what you wrote, but I'm also being
>> serious about the apparent power of the language police.
>>
>> I don't underestimate the power of the thought police (McCarthy was the
>> standout example of *THAT*) or their, sometimes wilful, ignorance. You
>> know what I meant, but if I'd written something like "include big blocks
>> of attention-getting high-density characters", might that be interpreted
>> as an attack on the comprehensionally challenged?
>
> 1. Yes, and those sectors of society defending the mentally deficient might be
> somewhere back in the queue waiting their turn to have a bit of a go at us for
> talking like this
>
> 2. My comment was not aimed at you in any way at all - it was an observation
> to other people on this list about a different discussion thread which you may
> have noticed in recent days (which, ironically enough, does include big blocks
> of attention-getting high-density characters in its subject line).
>
> Antony.
>
> --
> https://tools.ietf.org/html/rfc6890 - providing 16 million IPv4 addresses for
> talking to yourself.
>
> Please reply to the list;
> please *don't* CC me.

On Tue, 2020-07-14 at 16:32 -0400, Kevin A. McGrail wrote:
> Well, that is documented quite expressly here:
> https://cwiki.apache.org/confluence/display/SPAMASSASSIN/CachingNameserver
>
> A pointer to the wiki might be useful in the config files as well as
> the
> docs. Suggestions of which files?

local.cf is the obvious one.

Also: init.pre v330.pre and maybe v340.pre

I'm suggesting those because the new user MUST modify them (local.cf)
and the others because they would seem to be controlling modules that
issue DNS-like queries that a new user might consider killing off.

I also think that supplying simple boilerplate config files for bind and
unbound that cause them to simply issue non-forwarded DNS queries would
be a good idea because configuring bind for the first time is non-
trivial. I would have found configuring it quite difficult without
buying the O'Reilly 'locust' book "DNS and Bind".

I haven't used unbound so have no idea how easy it would be to set up to
support just non-forwarded queries.


Martin

On 14 Jul 2020, at 15:46, Martin Gregorie wrote:

> But the important point is to have SA docs say, in places that a new
> user can't miss that "If you want free use of the default RBLs then
> INSTALL YOUR OWN NON-FORWARDING DNS.

I believe that this underestimates the capacity of users to ignore
documentation and the capacity of package maintainers to actively
obscure standard documentation of 3rd-party software.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

On 14 Jul 2020, at 18:16, Martin Gregorie wrote:

> On Tue, 2020-07-14 at 16:32 -0400, Kevin A. McGrail wrote:
>> Well, that is documented quite expressly here:
>> https://cwiki.apache.org/confluence/display/SPAMASSASSIN/CachingNameserver
>>
>> A pointer to the wiki might be useful in the config files as well as
>> the
>> docs. Suggestions of which files?
>
> local.cf is the obvious one.
>
> Also: init.pre v330.pre and maybe v340.pre
>
> I'm suggesting those because the new user MUST modify them (local.cf)
> and the others because they would seem to be controlling modules that
> issue DNS-like queries that a new user might consider killing off.
>
> I also think that supplying simple boilerplate config files for bind
> and
> unbound that cause them to simply issue non-forwarded DNS queries
> would
> be a good idea because configuring bind for the first time is non-
> trivial. I would have found configuring it quite difficult without
> buying the O'Reilly 'locust' book "DNS and Bind".

-1

There are far too many ways that people have BIND already installed and
configured for a 3rd-party package to be able to safely provide a full
named.conf that will work for >90% of users who have modified their
configurations away from the defaults.

As noted on the page that Kevin cited, the default configuration for
BIND, Unbound, and the PDNS Resolver as packaged for the dominant Linux
distros is correct for a non-forwarding caching resolver. For BIND and
Unbound, this is also true on FreeBSD. For macOS, there is no 'standard
package' but the MacPorts packages for both BIND and Unbound do the
right thing with the default variants.

> I haven't used unbound so have no idea how easy it would be to set up
> to
> support just non-forwarded queries.

Everywhere that I have used it, Unbound has been configured thus when
installed from the standard system package where one exists.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

On Tue, 2020-07-14 at 18:39 -0400, Bill Cole wrote:
>
> There are far too many ways that people have BIND already installed
> and configured for a 3rd-party package to be able to safely provide a
> full named.conf that will work for 90% of users who have modified
> their configurations away from the defaults.
>
Fair enough, but I wasn't on about them.

What I WAS on about is the steady flow of folks who install SA and then
post on this list about problems resulting from using a shared DNF and
their consequent receipt of getting a letter from RBL providers
suggesting that service could be restored by application of cash.

THOSE are the newish SA users who are unlikely to have a non-forwarding
DNS installed and might well be helped by prominent messages in the SA
config files they will certainly be editing and that I'm suggesting
should contain unmissable messages about the need for having a non-
forwarding DNS setup.

The others who need cluestick treatment are any companies selling home
servers with SA installed and either no DNS installed or a forwarding
DNS as part of the package.

> As noted on the page that Kevin cited, the default configuration for
> BIND, Unbound, and the PDNS Resolver as packaged for the dominant
> Linux distros is correct for a non-forwarding caching resolver. For
> BIND and Unbound, this is also true on FreeBSD. For macOS, there is no
> 'standard package' but the MacPorts packages for both BIND and Unbound
> do the right thing with the default variants.
>
> Everywhere that I have used it, Unbound has been configured thus when
> installed from the standard system package where one exists.
>
Fair enough: job done then.

We can now declare the surprised punter with a forwarding DNS who sent
this list an e-mail saying that RBL service has been cut off until cash
is sent is now officially extinct as a subspecies, never to be heard
from again.

Martin

> A pointer to the wiki might be useful in the config files as well as

> > the
> > docs. Suggestions of which files?
>
> local.cf is the obvious one.
>

Might not be a bad choice. I've never even looked at a stock local.cf from
the project in 20 years though. Need to do a vanilla install and see what
is in there and where it is generated.
What about the docs? Where would you look for this nugget of information
as a user?

Also: init.pre v330.pre and maybe v340.pre
>

Well those pre files are pretty specific for new features in those
versions.

Kevin A. McGrail skrev den 2020-07-15 04:57:

> Might not be a bad choice.

+1

> I've never even looked at a stock local.cf

and you are pmc member, hmm

> [1] from the project in 20 years though.

time flies

> Need to do a vanilla install
> and see what is in there and where it is generated.

local.cf is not generated, its just a file from spamasassin that is
installed

> What about the docs?

perldoc Mail::SpamAssassin::Conf is a good start :=)

> Where would you look for this nugget of
> information as a user?

if user is system user its pure perldoc, if its virtual user there is no
docs

>> Also: init.pre v330.pre and maybe v340.pre
>
> Well those pre files are pretty specific for new features in those
> versions.

yes dont break it

> Links:
> ------
> [1] http://local.cf

my silly webmail :-)

CF is a tld so it rendered as a valid url, could possible find a
extension that is not a url, no ?, it will not break as much as white or
black or even orange chokolate from Ritter :=)

>On Tue, 2020-07-14 at 12:53 -0400, Kevin A. McGrail wrote:
>> I agree with you about the idea of turning off everything and just
>> delivering 100% commented configuration files.. I believe SA is a
>> framework that must have walls & paint added to make it a
>> house. Others want it ready to go as a pre-fab house aka a drop-in
>> spam filter. As a project, the majority supports the drop-in model so
>> I support the will of the PMC. The DNSBlocklist inclusion policy from
>> 2011 has served us well with a lot of users and very few
>> complaints. But if you think of edits it might need, we can always
>> improve it. DNS Blocklists and the free for some model really help
>> the drop in spam filter be effective.

On 14.07.20 20:46, Martin Gregorie wrote:
>Maybe all that's needed is to better emphasize the point that that free
>use of RBLs, whose use by SA is configured on by default, require the
>user to have their own non-forwarding DNS installed and explain why.

maybe a dns_query_restriction directive should be mentioned,

maybe it should be pre-configured by default, but commented with
explanation.


--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Atheism is a non-prophet organization.

On 14/07/20 19:33, Charles Sprickman wrote:

> 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. :)

Well, we do have a "data sharing" program and are open to discussion of
trading services for spamtraps/live traffic. We are especially
interested in non US email traffic.

If you or anyone else think that they have valuable data to share,
please contact me offlist with details and I'll escalate to the relevant
people

--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/

On Tue, 2020-07-14 at 22:57 -0400, Kevin A. McGrail wrote:
> > A pointer to the wiki might be useful in the config files as well as
> > > the
> > > docs. Suggestions of which files?
> >
> > local.cf is the obvious one.
> >
>
> Might not be a bad choice. I've never even looked at a stock local.cf
> from the project in 20 years though. Need to do a vanilla install and
> see what is in there and where it is generated.

> What about the docs? Where would you look for this nugget of
> information as a user?
>
As a long-time UNIX/Linux developer I'd naturally look in the
Spamassassin manpage, but I suspect a non-developer may not unless
they're a power user. I'd also guess that others, including Mac and
Windows users, would be looking for Help|About from a GUI app
(nonapplicable here of course) or, failing that, to point a web browser
at http://spamassassin.apache.org/

I think the best place to put warnings and advice about exceeding free
usage RBL limits are:

In the manpage:
- the manpage, which only needs a single line saying something like:
"Free RBL use limits: URL" added to its WEBSITES section

On the Spamassassin website:
- The top-level README
- The Start Using page in the Wiki
- the FAQ page.

All these can link to a common page that describes low volume free use
policies of Spamhaus and others RBL providers and how NOT using a local
non-forwarding DNS can cause the user to get unexpected subscription
requests from them.

BTW, the page "https://www.spamtips.org/p/about-spamtipsorg.html -
Configuration tips and tricks to maximize the effectiveness of
SpamAssassin", which is linked to from the 'Docs' page seems to have
vanished though the www.spamtips.org website is up and running.

> Also: init.pre v330.pre and maybe v340.pre
>
> Well those pre files are pretty specific for new features in those
> versions.
>
Fair point - I only included them because they load what look to be
relevant plugins for this discussion. However, a note there may well
propagate to future SA versions because typical developer version
forking.

Anyway, I hope these comments are useful.

Martin