Re: spamhaus enabled by default
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
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
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, uh...@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
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
> 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
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
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
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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently)
Re: spamhaus enabled by default
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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently)
Re: spamhaus enabled by default
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
Congrats on derailing another post needlessly. M. Omer GOLGELI July 15, 2020 12:41 AM, "Antony Stone" 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
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
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
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
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 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 > > wrote: > > > > > July 14, 2020 6:07 PM, "Kevin A. McGrail" > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > M. Omer GOLGELI > > > > >
Re: spamhaus enabled by default
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 > wrote: > > > July 14, 2020 6:07 PM, "Kevin A. McGrail" > > 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. > > > > > > > > > > > > > > > > > > M. Omer GOLGELI > >
Re: spamhaus enabled by default
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 wrote: > > > > On Jul 14, 2020, at 12:08 PM, M. Omer GOLGELI > wrote: > > > > July 14, 2020 6:07 PM, "Kevin A. McGrail" 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 > > > > > > > > > > > > > > > > > > > M. Omer GOLGELI > >
Re: spamhaus enabled by default
> On Jul 14, 2020, at 12:08 PM, M. Omer GOLGELI wrote: > > July 14, 2020 6:07 PM, "Kevin A. McGrail" 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 > > > > > > > > > M. Omer GOLGELI
Re: spamhaus enabled by default
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 kmcgr...@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
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
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 wrote: > July 14, 2020 6:07 PM, "Kevin A. McGrail" 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. > > > > > > > > > M. Omer GOLGELI >
Re: spamhaus enabled by default
July 14, 2020 6:07 PM, "Kevin A. McGrail" 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. M. Omer GOLGELI
Re: spamhaus enabled by default
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
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 wrote: > July 11, 2020 1:33 PM, "Riccardo Alfieri" > 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
July 11, 2020 1:33 PM, "Riccardo Alfieri" 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
On 11 Jul 2020, at 04:33, Riccardo Alfieri 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
> On Jul 11, 2020, at 6:33 AM, Riccardo Alfieri > 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
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 > "myn...@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
> > 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
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
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
> On Jul 10, 2020, at 7:56 PM, RW 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
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
> On Jul 10, 2020, at 5:56 PM, Charles Sprickman wrote: > > >> On Jul 10, 2020, at 5:35 PM, Kris Deugau 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
> On Jul 10, 2020, at 5:35 PM, Kris Deugau 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
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
> On Jul 10, 2020, at 1:57 PM, RW 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
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
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
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.ew...@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
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
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.ew...@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
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 kmcgr...@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
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
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
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
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