You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Philipp Ewald <ph...@digionline.de> on 2020/07/10 11:20:17 UTC
spamhaus enabled by default
Hey everyone,
we got a nice mail from spamhaus.
We have used their DNS Query's.
Important is that we thought we have disabled them by:
score __RCVD_IN_ZEN 0
But tcpdump says we make dns querys to spamhaus, but the result got ignored.
I have removed the configuration lines in /usr/share/spamassassin but after update the configuration comes back.
How do i disable them right? and why got this behavior changed?
kind regard
Philipp Ewald
--
Philipp Ewald
Administrator
DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
AG Köln HRB 27711, St.-Nr. 5215 5811 0640
Geschäftsführer: Werner Grafenhain
Informationen zum Datenschutz: www.digionline.de/ds
Re: spamhaus enabled by default
Posted by "Kevin A. McGrail" <km...@apache.org>.
Here's the policy:
https://cwiki.apache.org/confluence/display/spamassassin/DnsBlocklistsInclusionPolicy
On 7/10/2020 7:43 AM, Axb wrote:
> On 7/10/20 1:40 PM, Philipp Ewald wrote:
>>> in local.cf add:
>>>
>>> dns_query_restriction deny spamhaus.org
>>>
>>> that should fix the problem and survive SA updates
>>
>> Many Thank! now it's work.
>>
>> but why is this enabled by default?
>
> because, under fair use, it's free for all.
>
> Most smaller sites have no problem unless they use third party DNS
> resolvers which are blocked.
> if you're local resolver is forwarding to some ISP's resolver then you
> also get blocked.
>
>>
>> Am 10.07.20 um 13:23 schrieb Axb:
>>> On 7/10/20 1:20 PM, Philipp Ewald wrote:
>>>> Hey everyone,
>>>>
>>>> we got a nice mail from spamhaus.
>>>> We have used their DNS Query's.
>>>>
>>>> Important is that we thought we have disabled them by:
>>>> score __RCVD_IN_ZEN 0
>>>>
>>>> But tcpdump says we make dns querys to spamhaus, but the result got
>>>> ignored.
>>>
>>> you forgot that DBL rules also query Spamhaus
>>>
>>>> I have removed the configuration lines in /usr/share/spamassassin
>>>> but after update the configuration comes back.
>>>>
>>>> How do i disable them right? and why got this behavior changed?
>>>
>>> in local.cf add:
>>>
>>> dns_query_restriction deny spamhaus.org
>>>
>>> that should fix the problem and survive SA updates
>>>
>>> h2h
>>
>
>
--
Kevin A. McGrail
KMcGrail@Apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: spamhaus enabled by default
Posted by Benny Pedersen <me...@junc.eu>.
Philipp Ewald skrev den 2020-07-10 18:23:
> Thank you for the update!
> Last time we used spamhaus this was not given.
checking logs everyday ?
i am kidding aswell
Re: spamhaus enabled by default
Posted by Philipp Ewald <ph...@digionline.de>.
Thank you for the update!
Last time we used spamhaus this was not given.
Am 10.07.20 um 18:07 schrieb Riccardo Alfieri:
> Hi,
>
> sorry but this will never happen. We are not going to use a "list the world" response to queries from anyone. There are dedicated return codes for that (already included in SpamAssassin): https://www.spamhaus.org/news/article/788/spamhaus-dnsbl-return-codes-technical-update
--
Philipp Ewald
Administrator
DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
Telefon: +49 221 6500-532, Fax: +49 221 6500-690, E-Mail: philipp.ewald@digionline.de
AG Köln HRB 27711, St.-Nr. 5215 5811 0640
Geschäftsführer: Werner Grafenhain
Informationen zum Datenschutz: www.digionline.de/ds
Re: spamhaus enabled by default
Posted by Riccardo Alfieri <ri...@spamteq.com>.
On 10/07/20 18:01, Philipp Ewald wrote:
> Am 10.07.20 um 13:54 schrieb Kevin A. McGrail:
>> Here's the policy:
>> https://cwiki.apache.org/confluence/display/spamassassin/DnsBlocklistsInclusionPolicy
>>
>
> This was active since 2018?
>
> Maybe it would be better to ask if your are commercial or not... AFIK
> you got problem if your running spamhaus and have no license so any
> mail got marked as SPAM (or got hit SMAPMHAUS rule on any domain?)
>
Hi,
sorry but this will never happen. We are not going to use a "list the
world" response to queries from anyone. There are dedicated return codes
for that (already included in SpamAssassin):
https://www.spamhaus.org/news/article/788/spamhaus-dnsbl-return-codes-technical-update
--
Best regards,
Riccardo Alfieri
Spamhaus Technology
https://www.spamhaustech.com/
Re: spamhaus enabled by default
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>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.
Re: spamhaus enabled by default
Posted by Charles Sprickman <sp...@bway.net>.
> On Jul 11, 2020, at 6:33 AM, Riccardo Alfieri <ri...@spamteq.com> wrote:
>
> On 10/07/20 22:51, Charles Sprickman wrote:
>
>>
>> That’s unrealistic. Many ISPs these days that aren’t the “big boys” with dedicated staff for every facet of ISP operations, they are one and two man shops running WISPs in rural areas or developing countries. It’s not the 90’s anymore. It’s a terrible default, even home users should have to take an effort to enable a commercial service.
> I'm not going to make comments about running an ISP without a basic knowledge of email/hosting/networking
Wow, nice sales pitch my man! I will definitely recommend they sign up.
>> And spamhaus should just replace the sales pitch email with instructions on how to comment their stuff out if they don’t want small ISPs (a small business, actually!) to use it. :)
>
> Excuse me but isn't it at least "fair" that, if you use a service provided by others for commercial purposes, you pay for that service that contributes to your income?
Then it shouldn’t be free for “small businesses”. Having spam-free mailboxes will enhance their ability to conduct business, no? Or does your product not provide value.
> And I don't know where you got a quote of "hundreds of dollars per month" for 1000 mailboxes, but it's not really the case if you use DQS.
No idea what DQS is, nor do I care. The quote was from a sales rep. But the Spamhaus pitch was laughably expensive for less than 1,000 mailboxes - much more than they make on those mailboxes.
C
>
> --
> Best regards,
> Riccardo Alfieri
>
> Spamhaus Technology
> https://www.spamhaustech.com/
>
Re: spamhaus enabled by default
Posted by "@lbutlr" <kr...@kreme.com>.
On 11 Jul 2020, at 04:33, Riccardo Alfieri <ri...@spamteq.com> wrote:
> And I don't know where you got a quote of "hundreds of dollars per month" for 1000 mailboxes, but it's not really the case if you use DQS.
Maybe they thought the yearly cost was monthly?
(Last I checked, DQS stars at $250/yr)
--
The other cats just think he's a tosser. --Neil Gaiman
Re: spamhaus enabled by default
Posted by "Kevin A. McGrail" <km...@apache.org>.
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 <sp...@bway.net> wrote:
>
>
> > On Jul 14, 2020, at 12:08 PM, M. Omer GOLGELI <om...@chronos.com.tr>
> wrote:
> >
> > July 14, 2020 6:07 PM, "Kevin A. McGrail" <km...@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
>
>
Re: spamhaus enabled by default
Posted by Riccardo Alfieri <ri...@spamteq.com>.
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/
Re: spamhaus enabled by default
Posted by Charles Sprickman <sp...@bway.net>.
> On Jul 14, 2020, at 12:08 PM, M. Omer GOLGELI <om...@chronos.com.tr> wrote:
>
> July 14, 2020 6:07 PM, "Kevin A. McGrail" <km...@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
Re: spamhaus enabled by default
Posted by "M. Omer GOLGELI" <om...@chronos.com.tr>.
Congrats on derailing another post needlessly.
M. Omer GOLGELI
July 15, 2020 12:41 AM, "Antony Stone" <An...@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.
Re: spamhaus enabled by default
Posted by Antony Stone <An...@spamassassin.open.source.it>.
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.
Re: spamhaus enabled by default
Posted by Martin Gregorie <ma...@gregorie.org>.
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
Re: spamhaus enabled by default
Posted by Antony Stone <An...@spamassassin.open.source.it>.
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.
Re: spamhaus enabled by default
Posted by "Kevin A. McGrail" <km...@apache.org>.
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
Re: spamhaus enabled by default
Posted by "Luis E. Muñoz" <sa...@lem.click>.
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
Re: spamhaus enabled by default
Posted by Martin Gregorie <ma...@gregorie.org>.
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
Re: spamhaus enabled by default
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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)
Re: spamhaus enabled by default
Posted by Martin Gregorie <ma...@gregorie.org>.
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
Re: spamhaus enabled by default
Posted by Benny Pedersen <me...@junc.eu>.
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 :=)
Re: spamhaus enabled by default
Posted by "Kevin A. McGrail" <km...@apache.org>.
> 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.
Re: spamhaus enabled by default
Posted by Martin Gregorie <ma...@gregorie.org>.
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
Re: spamhaus enabled by default
Posted by "Kevin A. McGrail" <km...@apache.org>.
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 <ma...@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 <om...@chronos.com.tr>
> > wrote:
> >
> > > July 14, 2020 6:07 PM, "Kevin A. McGrail" <km...@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
> > >
>
>
Re: spamhaus enabled by default
Posted by RW <rw...@googlemail.com>.
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.
Re: spamhaus enabled by default
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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)
Re: spamhaus enabled by default
Posted by Martin Gregorie <ma...@gregorie.org>.
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 <om...@chronos.com.tr>
> wrote:
>
> > July 14, 2020 6:07 PM, "Kevin A. McGrail" <km...@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
> >
Re: spamhaus enabled by default
Posted by "Kevin A. McGrail" <km...@apache.org>.
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 <om...@chronos.com.tr>
wrote:
> July 14, 2020 6:07 PM, "Kevin A. McGrail" <km...@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
>
Re: spamhaus enabled by default
Posted by "M. Omer GOLGELI" <om...@chronos.com.tr>.
July 14, 2020 6:07 PM, "Kevin A. McGrail" <km...@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
Re: spamhaus enabled by default
Posted by "Kevin A. McGrail" <km...@apache.org>.
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?
--
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 10:55 AM M. Omer GOLGELI <om...@chronos.com.tr>
wrote:
> July 11, 2020 1:33 PM, "Riccardo Alfieri" <ri...@spamteq.com>
> wrote:
>
> > Excuse me but isn't it at least "fair" that, if you use a service
> provided by others for commercial
> > purposes, you pay for that service that contributes to your income?
>
> It is fair.
>
> Unless you have been unknowingly using it and weren't aware of the limits.
>
> But maybe this kind of RBLs shouldn't be on by default due to their
> commercial nature and must be left to the user to activate after
> installation.
>
>
>
>
>
> M. Omer GOLGELI
>
Re: spamhaus enabled by default
Posted by Benny Pedersen <me...@junc.eu>.
M. Omer GOLGELI skrev den 2020-07-14 16:55:
> It is fair.
+1
> Unless you have been unknowingly using it and weren't aware of the
> limits.
+1
> But maybe this kind of RBLs shouldn't be on by default due to their
> commercial nature and must be left to the user to activate after
> installation.
why is any plugins turned on by default ?
spamassassin could make all disabled by default, only enable check
plugin to make --lint testing, hurra sa wont work, scream :=====)))))
Re: spamhaus enabled by default
Posted by "M. Omer GOLGELI" <om...@chronos.com.tr>.
July 11, 2020 1:33 PM, "Riccardo Alfieri" <ri...@spamteq.com> wrote:
> Excuse me but isn't it at least "fair" that, if you use a service provided by others for commercial
> purposes, you pay for that service that contributes to your income?
It is fair.
Unless you have been unknowingly using it and weren't aware of the limits.
But maybe this kind of RBLs shouldn't be on by default due to their commercial nature and must be left to the user to activate after installation.
M. Omer GOLGELI
Re: spamhaus enabled by default
Posted by Riccardo Alfieri <ri...@spamteq.com>.
On 10/07/20 22:51, Charles Sprickman wrote:
>
> That’s unrealistic. Many ISPs these days that aren’t the “big boys” with dedicated staff for every facet of ISP operations, they are one and two man shops running WISPs in rural areas or developing countries. It’s not the 90’s anymore. It’s a terrible default, even home users should have to take an effort to enable a commercial service.
I'm not going to make comments about running an ISP without a basic
knowledge of email/hosting/networking
> And spamhaus should just replace the sales pitch email with instructions on how to comment their stuff out if they don’t want small ISPs (a small business, actually!) to use it. :)
Excuse me but isn't it at least "fair" that, if you use a service
provided by others for commercial purposes, you pay for that service
that contributes to your income?
And I don't know where you got a quote of "hundreds of dollars per
month" for 1000 mailboxes, but it's not really the case if you use DQS.
--
Best regards,
Riccardo Alfieri
Spamhaus Technology
https://www.spamhaustech.com/
Re: spamhaus enabled by default
Posted by Charles Sprickman <sp...@bway.net>.
> On Jul 10, 2020, at 7:56 PM, RW <rw...@googlemail.com> wrote:
>
> On Fri, 10 Jul 2020 18:25:33 -0400
> Charles Sprickman wrote:
>
>
>> Also I just dug up the letter and the wording used was “commercial
>> use”. There was no mention of what the volume was or what the limit
>> would be.
>>
>
> The default is to use these list unregistered. Did that ISP register or
> did Spamhaus track them down from the IP address?
Spamhaus found them.
>> They also tagged one of the resolvers that access customers use
>> (there are two dedicated resolvers for BL lookups), so presumably
>> some very small and low-volume home and small biz users were being
>> tagged in aggregate, probably not even aware they’re using spamhaus.
>
> Low-volume users that don't know they should be doing recursive lookups
> will often get away with it, and even if they don't, being blocked isn't
> significantly worse for them than turning-off spamhaus.
I know they have plenty of users with SOHO NAS boxes, home users that tinker, and other “power users”. SA is tucked away in many “appliances” these days it seems.
> I thought most ISPs had outsourced or given-up on email. ISP email has
> IMO always been a way of locking-in gullible customers.
They are in NYC so there’s a sizable chunk of old netheads that want a) the same address they’ve had since ’95 b) mail service that doesn’t exchange privacy for free email c) vanity domains. It’s not a money maker, it’s a value-add.
Personally I think Spamhaus and others going up to these tiny companies and asking for hundreds of bucks a month for access to a list is kind of nuts, but I’m no MBA.
I do wonder if they go after the larger hosters that run CPanel and have mail scattered over hundreds of hosts or if those individually don’t trip the threshold.
The small ISP with email is likely a dying breed, spam being one of the main things that forces yet another service to be outsourced at a not-insignificant cost. This same ISP discontinued Usenet service as a value-add only a few years ago.
C
RE: spamhaus enabled by default
Posted by Marc Roos <M....@f1-outsourcing.eu>.
> > Am 11.07.20 um 01:56 schrieb RW:
> > > I thought most ISPs had outsourced or given-up on email.
> >
> > why should someone with a brain outsource anything?
>
> I don't know, why do you outsource?
>
> > > ISP email has IMO always been a way of locking-in gullible
> > > customers.
The US is always behind with consumer rights, in the EU consumer data
portability is arranged enforced legislation. Then again, is there not
some saying like 'people deserve the government they are having'
> >
> > bullshit - how is there a lockin for customers with their own
domains?
>
> It locks in those that use the address directly - try and keep up.
>
I think it will be more popular not to host with google or so. Because
google is mixing your messages with spam, and your messages are more
likely to be marked as spam.
Furthermore doctors and anything serious will not use US based providers
because of the lack of privacy.
Recently someone contacted me in regards a CEO fraud issue. Google and
Outlook.com were not even able to deliver evidence an email was
delivered.
Re: spamhaus enabled by default
Posted by RW <rw...@googlemail.com>.
On Sat, 11 Jul 2020 17:35:58 +0200
Reindl Harald wrote:
> we are working at ISP level and customers have their own domains where
> they can get an auth-token for transfer the domain at every point in
> time
>
> so there is no dumb outsourcing nor any lockin
>
> when you use something like "myname@gmailcom" or
> "myname@randomisp.com" you are simply dumb given how cheap a domain
> per year is
That's email domain hosting. I was referring to traditional ISP email
with an address or subdomain on an ISP domain.
Re: spamhaus enabled by default
Posted by RW <rw...@googlemail.com>.
On Sat, 11 Jul 2020 02:49:31 +0200
Reindl Harald wrote:
> Am 11.07.20 um 01:56 schrieb RW:
> > I thought most ISPs had outsourced or given-up on email.
>
> why should someone with a brain outsource anything?
I don't know, why do you outsource?
> > ISP email has IMO always been a way of locking-in gullible
> > customers.
>
> bullshit - how is there a lockin for customers with their own domains?
It locks in those that use the address directly - try and keep up.
Re: spamhaus enabled by default
Posted by RW <rw...@googlemail.com>.
On Fri, 10 Jul 2020 18:25:33 -0400
Charles Sprickman wrote:
> Also I just dug up the letter and the wording used was “commercial
> use”. There was no mention of what the volume was or what the limit
> would be.
>
The default is to use these list unregistered. Did that ISP register or
did Spamhaus track them down from the IP address?
> They also tagged one of the resolvers that access customers use
> (there are two dedicated resolvers for BL lookups), so presumably
> some very small and low-volume home and small biz users were being
> tagged in aggregate, probably not even aware they’re using spamhaus.
Low-volume users that don't know they should be doing recursive lookups
will often get away with it, and even if they don't, being blocked isn't
significantly worse for them than turning-off spamhaus.
I thought most ISPs had outsourced or given-up on email. ISP email has
IMO always been a way of locking-in gullible customers.
Re: spamhaus enabled by default
Posted by Charles Sprickman <sp...@bway.net>.
> On Jul 10, 2020, at 5:56 PM, Charles Sprickman <sp...@bway.net> wrote:
>
>
>> On Jul 10, 2020, at 5:35 PM, Kris Deugau <kd...@vianet.ca> wrote:
>>
>> Charles Sprickman wrote:
>>> That’s unrealistic. Many ISPs these days that aren’t the “big boys” with dedicated staff for every facet of ISP operations, they are one and two man shops running WISPs in rural areas or developing countries. It’s not the 90’s anymore. It’s a terrible default, even home users should have to take an effort to enable a commercial service.
>>
>> I'm baffled by how a "one or two man shop [W]ISP" can have an in-house email system that generates more queries than the free limits unless you're outsourcing nearly everything else including DNS caching. (At which point, why are you not outsourcing your mail service and spam filtering too?) From personal experience, a provider of that size likely has less than 1000 customers, which should match to mail flow well under the free limit.
>>
>> I started work for one such small ISP in 2001 with ~2600 users at peak (granted, the spam landscape was quite different then), and when that company got taken over by a larger company in 2003, moved on to maintaining the spam filtering for that larger company.
>>
>> In that position we still weren't crossing the free query limits for a while, at ~40K users. None of the five or six other small mail systems I've had some hand in integrating have come close to the free limits, and several of those providers have had ~10-15 full-time staff. All of them *have* had local caching, even if it was built into some nightmare black-box mail appliance horror, or Microsoft's DNS cache from Windows Server 2003 (or possibly older, only got involved in the fringes of that one).
>>
>> It's not impossible, I'll grant (one guy I knew of a year or two ahead in university was - in 1997 or so - getting IIRC more than ~5K spams daily, personally), but I'd call it extremely rare even today.
>
> The letter I got was for an ISP that has less than 1,000 mailboxes and queries two local, caching resolvers.
Also I just dug up the letter and the wording used was “commercial use”. There was no mention of what the volume was or what the limit would be.
They also tagged one of the resolvers that access customers use (there are two dedicated resolvers for BL lookups), so presumably some very small and low-volume home and small biz users were being tagged in aggregate, probably not even aware they’re using spamhaus.
C
>
> C
>
>>
>> -kgd
>
Re: spamhaus enabled by default
Posted by Charles Sprickman <sp...@bway.net>.
> On Jul 10, 2020, at 5:35 PM, Kris Deugau <kd...@vianet.ca> wrote:
>
> Charles Sprickman wrote:
>> That’s unrealistic. Many ISPs these days that aren’t the “big boys” with dedicated staff for every facet of ISP operations, they are one and two man shops running WISPs in rural areas or developing countries. It’s not the 90’s anymore. It’s a terrible default, even home users should have to take an effort to enable a commercial service.
>
> I'm baffled by how a "one or two man shop [W]ISP" can have an in-house email system that generates more queries than the free limits unless you're outsourcing nearly everything else including DNS caching. (At which point, why are you not outsourcing your mail service and spam filtering too?) From personal experience, a provider of that size likely has less than 1000 customers, which should match to mail flow well under the free limit.
>
> I started work for one such small ISP in 2001 with ~2600 users at peak (granted, the spam landscape was quite different then), and when that company got taken over by a larger company in 2003, moved on to maintaining the spam filtering for that larger company.
>
> In that position we still weren't crossing the free query limits for a while, at ~40K users. None of the five or six other small mail systems I've had some hand in integrating have come close to the free limits, and several of those providers have had ~10-15 full-time staff. All of them *have* had local caching, even if it was built into some nightmare black-box mail appliance horror, or Microsoft's DNS cache from Windows Server 2003 (or possibly older, only got involved in the fringes of that one).
>
> It's not impossible, I'll grant (one guy I knew of a year or two ahead in university was - in 1997 or so - getting IIRC more than ~5K spams daily, personally), but I'd call it extremely rare even today.
The letter I got was for an ISP that has less than 1,000 mailboxes and queries two local, caching resolvers.
C
>
> -kgd
Re: spamhaus enabled by default
Posted by Kris Deugau <kd...@vianet.ca>.
Charles Sprickman wrote:
> That’s unrealistic. Many ISPs these days that aren’t the “big boys” with dedicated staff for every facet of ISP operations, they are one and two man shops running WISPs in rural areas or developing countries. It’s not the 90’s anymore. It’s a terrible default, even home users should have to take an effort to enable a commercial service.
I'm baffled by how a "one or two man shop [W]ISP" can have an in-house
email system that generates more queries than the free limits unless
you're outsourcing nearly everything else including DNS caching. (At
which point, why are you not outsourcing your mail service and spam
filtering too?) From personal experience, a provider of that size
likely has less than 1000 customers, which should match to mail flow
well under the free limit.
I started work for one such small ISP in 2001 with ~2600 users at peak
(granted, the spam landscape was quite different then), and when that
company got taken over by a larger company in 2003, moved on to
maintaining the spam filtering for that larger company.
In that position we still weren't crossing the free query limits for a
while, at ~40K users. None of the five or six other small mail systems
I've had some hand in integrating have come close to the free limits,
and several of those providers have had ~10-15 full-time staff. All of
them *have* had local caching, even if it was built into some nightmare
black-box mail appliance horror, or Microsoft's DNS cache from Windows
Server 2003 (or possibly older, only got involved in the fringes of that
one).
It's not impossible, I'll grant (one guy I knew of a year or two ahead
in university was - in 1997 or so - getting IIRC more than ~5K spams
daily, personally), but I'd call it extremely rare even today.
-kgd
Re: spamhaus enabled by default
Posted by Charles Sprickman <sp...@bway.net>.
> On Jul 10, 2020, at 1:57 PM, RW <rw...@googlemail.com> wrote:
>
> On Fri, 10 Jul 2020 18:01:30 +0200
> Philipp Ewald wrote:
>
>>> Most smaller sites have no problem unless they use third party DNS
>>> resolvers which are blocked. if you're local resolver is forwarding
>>> to some ISP's resolver then you also get blocked.
>>
>> No. We are like a ISP... and got more than 50.000 accepted Mails a
>> day so this is totally not in free-use includes, but i think enabled
>> by default is... na
>
> The default is right for most, defined in the link as
>
> "covering the small businesses, non-profits, personal users, etc. that
> make up the bulk of our installations."
>
> If you are managing an ISP level mail system the assumption is that you
> are paid to understand the basics of spam filtering.
That’s unrealistic. Many ISPs these days that aren’t the “big boys” with dedicated staff for every facet of ISP operations, they are one and two man shops running WISPs in rural areas or developing countries. It’s not the 90’s anymore. It’s a terrible default, even home users should have to take an effort to enable a commercial service.
And spamhaus should just replace the sales pitch email with instructions on how to comment their stuff out if they don’t want small ISPs (a small business, actually!) to use it. :)
Charles
Re: spamhaus enabled by default
Posted by RW <rw...@googlemail.com>.
On Fri, 10 Jul 2020 18:01:30 +0200
Philipp Ewald wrote:
> > Most smaller sites have no problem unless they use third party DNS
> > resolvers which are blocked. if you're local resolver is forwarding
> > to some ISP's resolver then you also get blocked.
>
> No. We are like a ISP... and got more than 50.000 accepted Mails a
> day so this is totally not in free-use includes, but i think enabled
> by default is... na
The default is right for most, defined in the link as
"covering the small businesses, non-profits, personal users, etc. that
make up the bulk of our installations."
If you are managing an ISP level mail system the assumption is that you
are paid to understand the basics of spam filtering.
Re: spamhaus enabled by default
Posted by Philipp Ewald <ph...@digionline.de>.
> Most smaller sites have no problem unless they use third party DNS resolvers which are blocked.
> if you're local resolver is forwarding to some ISP's resolver then you also get blocked.
No. We are like a ISP... and got more than 50.000 accepted Mails a day so this is totally not in free-use includes, but i think enabled by default is... na
Am 10.07.20 um 13:54 schrieb Kevin A. McGrail:
> Here's the policy:
> https://cwiki.apache.org/confluence/display/spamassassin/DnsBlocklistsInclusionPolicy
This was active since 2018?
Maybe it would be better to ask if your are commercial or not... AFIK you got problem if your running spamhaus and have no license so any mail got marked as SPAM (or got hit SMAPMHAUS rule on any domain?)
Am 10.07.20 um 13:43 schrieb Axb:
> On 7/10/20 1:40 PM, Philipp Ewald wrote:
>>> in local.cf add:
>>>
>>> dns_query_restriction deny spamhaus.org
>>>
>>> that should fix the problem and survive SA updates
>>
>> Many Thank! now it's work.
>>
>> but why is this enabled by default?
>
> because, under fair use, it's free for all.
>
> Most smaller sites have no problem unless they use third party DNS resolvers which are blocked.
> if you're local resolver is forwarding to some ISP's resolver then you also get blocked.
>
--
Philipp Ewald
Administrator
DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
Telefon: +49 221 6500-532, Fax: +49 221 6500-690, E-Mail: philipp.ewald@digionline.de
AG Köln HRB 27711, St.-Nr. 5215 5811 0640
Geschäftsführer: Werner Grafenhain
Informationen zum Datenschutz: www.digionline.de/ds
Re: spamhaus enabled by default
Posted by Axb <ax...@gmail.com>.
On 7/10/20 1:40 PM, Philipp Ewald wrote:
>> in local.cf add:
>>
>> dns_query_restriction deny spamhaus.org
>>
>> that should fix the problem and survive SA updates
>
> Many Thank! now it's work.
>
> but why is this enabled by default?
because, under fair use, it's free for all.
Most smaller sites have no problem unless they use third party DNS
resolvers which are blocked.
if you're local resolver is forwarding to some ISP's resolver then you
also get blocked.
>
> Am 10.07.20 um 13:23 schrieb Axb:
>> On 7/10/20 1:20 PM, Philipp Ewald wrote:
>>> Hey everyone,
>>>
>>> we got a nice mail from spamhaus.
>>> We have used their DNS Query's.
>>>
>>> Important is that we thought we have disabled them by:
>>> score __RCVD_IN_ZEN 0
>>>
>>> But tcpdump says we make dns querys to spamhaus, but the result got
>>> ignored.
>>
>> you forgot that DBL rules also query Spamhaus
>>
>>> I have removed the configuration lines in /usr/share/spamassassin but
>>> after update the configuration comes back.
>>>
>>> How do i disable them right? and why got this behavior changed?
>>
>> in local.cf add:
>>
>> dns_query_restriction deny spamhaus.org
>>
>> that should fix the problem and survive SA updates
>>
>> h2h
>
Re: spamhaus enabled by default
Posted by Philipp Ewald <ph...@digionline.de>.
> in local.cf add:
>
> dns_query_restriction deny spamhaus.org
>
> that should fix the problem and survive SA updates
Many Thank! now it's work.
but why is this enabled by default?
Am 10.07.20 um 13:23 schrieb Axb:
> On 7/10/20 1:20 PM, Philipp Ewald wrote:
>> Hey everyone,
>>
>> we got a nice mail from spamhaus.
>> We have used their DNS Query's.
>>
>> Important is that we thought we have disabled them by:
>> score __RCVD_IN_ZEN 0
>>
>> But tcpdump says we make dns querys to spamhaus, but the result got ignored.
>
> you forgot that DBL rules also query Spamhaus
>
>> I have removed the configuration lines in /usr/share/spamassassin but after update the configuration comes back.
>>
>> How do i disable them right? and why got this behavior changed?
>
> in local.cf add:
>
> dns_query_restriction deny spamhaus.org
>
> that should fix the problem and survive SA updates
>
> h2h
--
Philipp Ewald
Administrator
DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
AG Köln HRB 27711, St.-Nr. 5215 5811 0640
Geschäftsführer: Werner Grafenhain
Informationen zum Datenschutz: www.digionline.de/ds
Re: spamhaus enabled by default
Posted by Axb <ax...@gmail.com>.
On 7/10/20 1:20 PM, Philipp Ewald wrote:
> Hey everyone,
>
> we got a nice mail from spamhaus.
> We have used their DNS Query's.
>
> Important is that we thought we have disabled them by:
> score __RCVD_IN_ZEN 0
>
> But tcpdump says we make dns querys to spamhaus, but the result got
> ignored.
you forgot that DBL rules also query Spamhaus
> I have removed the configuration lines in /usr/share/spamassassin but
> after update the configuration comes back.
>
> How do i disable them right? and why got this behavior changed?
in local.cf add:
dns_query_restriction deny spamhaus.org
that should fix the problem and survive SA updates
h2h