You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Mark London <mr...@psfc.mit.edu> on 2024/11/14 03:15:01 UTC
All RCVD_IN_VALIDITY rules being applied to every email.
FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED,
RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered
for every email that our server received. I do not use a public DNS
server. I disabled all of them. Strange. - Mark
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 14.11.24 15:31, Matija Nalis wrote:
>I'm not using VALIDITY for SA, but I do periodic checks with Icinga
>check_rbl if my mailservers did get on any blacklist, and about 2
>days ago I've got alerts that ALL of mailservers were suddenly on
>Validity Senderscore blacklist:
>
>CHECK_RBL CRITICAL - x.x.x.x BLACKLISTED on 1 server of 122 (bl.score.senderscore.com (127.255.255.255))
>
>So I stopped checking that, too...
You are not listed, you got blocklisted.
>On Wed, Nov 13, 2024 at 10:15:01PM -0500, Mark London wrote:
>> FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED,
>> RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered for
>> every email that our server received. I do not use a public DNS server. I
>> disabled all of them. Strange. - Mark
--
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.
I intend to live forever - so far so good.
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Matija Nalis <mn...@voyager.hr>.
They probably tightened up their AUP / enforcement...
I'm not using VALIDITY for SA, but I do periodic checks with Icinga
check_rbl if my mailservers did get on any blacklist, and about 2
days ago I've got alerts that ALL of mailservers were suddenly on
Validity Senderscore blacklist:
CHECK_RBL CRITICAL - x.x.x.x BLACKLISTED on 1 server of 122 (bl.score.senderscore.com (127.255.255.255))
So I stopped checking that, too...
On Wed, Nov 13, 2024 at 10:15:01PM -0500, Mark London wrote:
> FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED,
> RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered for
> every email that our server received. I do not use a public DNS server. I
> disabled all of them. Strange. - Mark
--
Opinions above are GNU-copylefted.
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nix <ni...@esperi.org.uk>.
On 18 Nov 2024, Bill Cole spake thusly:
> On 2024-11-18 at 12:21:12 UTC-0500 (Mon, 18 Nov 2024 17:21:12 +0000)
> Nix <ni...@esperi.org.uk>
> is rumored to have said:
>
>> On 14 Nov 2024, Mark London uttered the following:
>>
>>> FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered for
>>> every email that our server received. I do not use a public DNS server. I disabled all of them. Strange. - Mark
>>
>> I'm seeing this too. I'm not a high-volume site, yet...
> [... snip of log entries ...]
>> I'm not a high-volume site, a few thousand mails a day. If I'm blocked,
>> probably more or less everyone is being blocked. (Are the DNSBLs above
>> all run by the same entity now?)
>
> If you forward DNS queries instead of running your own *fully
> recursive* DNS resolver locally, you *look* like you are part of a
> high-volume leech. This almost certainly does not mean you should run
> dnsmasq locally, it means you need a REAL resolver. Unbound does a
> good job without the rococo config options of BIND. Many people also
> like the resolver half of the PowerDNS suite.
I'm running BIND (actually, two BINDs, one authoritative one, one
recursive resolver). Sorry, I've been doing that for so long I forgot
any alternative was possible! :)
>> ... hm actually perhaps my checks of mail to a couple of high-volume
>> mailing lists are triggering it.
>
> Extremely unlikely. Check your DNS config first. If /etc/resolv.conf
> doesn't have a nameserver entry with a loopback address, you need to
> fix that. If you do not have a recursive resolver listening on port 53
> on a loopback address, you need to fix that as well.
>
> If you already have a real recursing resolver on the local LAN you can
> use that instead, but if you had that you would already be using it, I
> expect.
I am.
>> But, really... what on earth is going on in that message?
>>
>> Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
>>
>> So there's a mention of a file under
>> /etc/mail/spamassassin/helpers/.spamassassin/, but that directory is
>> empty (writable only by root, but spamd is running as root). Is this
>> just a misfire because it's trying to write after dropping privileges or
>> something?
>
> Yes, it seems likely that it is privileges problem. The code creating
> the blockfile is in M::SA::Plugin::Check.pm which I don't believe ever
> runs as root via spamd, even if you start spamd as root.
>
> The relevant code has comments implying that the functionality is in
> response to bug 6728 and is probably not ideally placed. I agree with
> that. I'm not sure where it should be, but if you run spamd as root
> then by the time you have a message in hand, you're actually running
> as either the user running spamc or nobody, which will cause issues if
> you are trying to create that blockfile in that directory.
Yeah. I suppose it should be landing in the user's ~/.spamassassin, but
it's not...
> The point of the big ugly error message is to have a big ugly error
> message. MOST people who report problems with SA accuracy here have
> misconfigured their resolvers, apparently because they don't trust
> documentation or don't read it.
Not me! This is something else. Maybe lkml is just too high volume...
God knows it's too high volume to actually *read* (I'm grabbing it for
grepping purposes and I really don't mind if SA doesn't RBL-scan mails
directed there -- it's all my other mail I want RBL-scanning.)
--
NULL && (void)
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2024-11-18 at 12:21:12 UTC-0500 (Mon, 18 Nov 2024 17:21:12 +0000)
Nix <ni...@esperi.org.uk>
is rumored to have said:
> On 14 Nov 2024, Mark London uttered the following:
>
>> FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered for
>> every email that our server received. I do not use a public DNS server. I disabled all of them. Strange. - Mark
>
> I'm seeing this too. I'm not a high-volume site, yet...
[... snip of log entries ...]
> I'm not a high-volume site, a few thousand mails a day. If I'm blocked,
> probably more or less everyone is being blocked. (Are the DNSBLs above
> all run by the same entity now?)
If you forward DNS queries instead of running your own *fully recursive* DNS resolver locally, you *look* like you are part of a high-volume leech. This almost certainly does not mean you should run dnsmasq locally, it means you need a REAL resolver. Unbound does a good job without the rococo config options of BIND. Many people also like the resolver half of the PowerDNS suite.
> ... hm actually perhaps my checks of mail to a couple of high-volume
> mailing lists are triggering it.
Extremely unlikely. Check your DNS config first. If /etc/resolv.conf doesn't have a nameserver entry with a loopback address, you need to fix that. If you do not have a recursive resolver listening on port 53 on a loopback address, you need to fix that as well.
If you already have a real recursing resolver on the local LAN you can use that instead, but if you had that you would already be using it, I expect.
> I wonder if I can prevent those DNSBLs
> from being consulted just for mail apparently to those lists?
Not really. That's what the auto-created "blockfile" is supposed to do: stop queries to services that are blocking you. Looks like it is not working for you...
> But, really... what on earth is going on in that message?
>
> Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
>
> So there's a mention of a file under
> /etc/mail/spamassassin/helpers/.spamassassin/, but that directory is
> empty (writable only by root, but spamd is running as root). Is this
> just a misfire because it's trying to write after dropping privileges or
> something?
Yes, it seems likely that it is privileges problem. The code creating the blockfile is in M::SA::Plugin::Check.pm which I don't believe ever runs as root via spamd, even if you start spamd as root.
The relevant code has comments implying that the functionality is in response to bug 6728 and is probably not ideally placed. I agree with that. I'm not sure where it should be, but if you run spamd as root then by the time you have a message in hand, you're actually running as either the user running spamc or nobody, which will cause issues if you are trying to create that blockfile in that directory.
The point of the big ugly error message is to have a big ugly error message. MOST people who report problems with SA accuracy here have misconfigured their resolvers, apparently because they don't trust documentation or don't read it.
--
Bill Cole
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nix <ni...@esperi.org.uk>.
On 18 Nov 2024, Nick Howitt stated:
> The RBL's check the referring DNS Server. if you use someone like OpenDNS or GoogleDNS, as many others do then, as far as the RBL
> list is concernet it is receiving too many queries via those DNS servers.
>
> If you want to use these RBL's, it is recommended you run your own recursive DNS server rather than use a public DNS server.
I am.
--
NULL && (void)
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nick Howitt <ni...@howitts.co.uk>.
The RBL's check the referring DNS Server. if you use someone like
OpenDNS or GoogleDNS, as many others do then, as far as the RBL list is
concernet it is receiving too many queries via those DNS servers.
If you want to use these RBL's, it is recommended you run your own
recursive DNS server rather than use a public DNS server.
On 18/11/2024 17:21, Nix wrote:
> On 14 Nov 2024, Mark London uttered the following:
>
>> FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered for
>> every email that our server received. I do not use a public DNS server. I disabled all of them. Strange. - Mark
> I'm seeing this too. I'm not a high-volume site, yet...
>
> Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
> Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_SAFE_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_sa-accredit.habeas.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-accredit.habeas.com" to disable queries)
> Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_CERTIFIED_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_sa-trusted.bondedsender.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-trusted.bondedsender.org" to disable queries)
> Nov 14 00:00:26 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_CERTIFIED_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_sa-trusted.bondedsender.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-trusted.bondedsender.org" to disable queries)
> Nov 14 00:00:26 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_SAFE_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_sa-accredit.habeas.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-accredit.habeas.com" to disable queries)
>
> I'm not a high-volume site, a few thousand mails a day. If I'm blocked,
> probably more or less everyone is being blocked. (Are the DNSBLs above
> all run by the same entity now?)
>
> ... hm actually perhaps my checks of mail to a couple of high-volume
> mailing lists are triggering it. I wonder if I can prevent those DNSBLs
> from being consulted just for mail apparently to those lists?
>
> But, really... what on earth is going on in that message?
>
> Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
>
> So there's a mention of a file under
> /etc/mail/spamassassin/helpers/.spamassassin/, but that directory is
> empty (writable only by root, but spamd is running as root). Is this
> just a misfire because it's trying to write after dropping privileges or
> something?
>
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by "Anne P. Mitchell, Esq." <am...@isipp.com>.
> 10k requests per 30-day period is about 333 queries/day. Or less than 14 queries per hour.
> Not very much at all (and certainly at least order of magnitude less than your stated traffic).
> No amount of local DNS caching is going to fix limits *that low*.
Just a reminder that there is no such limitation on the IADB, which is essentially the same type of 'good sender' certification as that aspect of Validity. We don't even *have* a paid version for receivers - it's free, and it always has been, and it always will be, because we consider our first responsibility as being to the ISPs and spam filters who rely on us. We also were the originator of the 'data points' model of DNS lists, where each octet in the zone represents a discrete aspect of the sender's sending policies, for example:
127.3.100.200 The only email which comes from this IP address is one-to-one or transactional email. No bulk email is sent from this IP address
127.3.100.100 The only email which comes from this IP address is mailing list email, and that mailing list email is entirely confirmed (double) opt-in
We did this *specifically* so that SA could take full advantage if the information we have (in fact I worked with Craig Hughes on developing this model - and I made the considered choice to *not* try to protect it through patent or copyright, so we knew that others would copy it and that was ok with us, as anything that makes it easier for receivers to identify good email so that they can focus their resources to the bad email, makes the email ecosystem better).
So, again, queries to the IADB are unlimited and always free, have been for the 20+ years we've been in operation (we founded the *exact* came month that Scott Weiss started Bonded Sender).
All we ask is that if you are going to do a ton of querying, that you transfer the zone to a local copy instead of querying directly.
Anne
--
Anne P. Mitchell, Esq.
Email Law & Policy Attorney
Legislative Advisor
Author: Section 6 of the CAN-SPAM Act of 2003 (the vendor liability for affiliates section)
CEO Institute for Social Internet Public Policy
Creator of the term 'deliverability'; Co-Founder of the deliverability industry
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus, eMail Abuse Prevention System (MAPS)
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nix <ni...@esperi.org.uk>.
On 20 Nov 2024, Andy Smith uttered the following:
> Hi,
>
> On Wed, Nov 20, 2024 at 05:07:09PM +0000, Nix wrote:
>> > From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>>
>> Tried registering here. I can register a v4 address, but every format of
>> v6 CIDR I've tried reports "Invalid V6_CIDR" with (of course) no
>
> I experienced the same a couple of months ago and reported it to them.
> Their response after several weeks was:
>
> "I investigated this with our engineering team. We currently don't
> support IPV6 in the on the my validity/ zone file registration page.
> Our product team is working to remove IPV6 as option.
>
> Currently only IPV4 single and IPV4 range are supported. I apologize
> for any confusion."
>
> I see they haven't got around to removing the IPv6 features that they
> consider a mistake yet then.
>
> (They don't have IPv6 addresses on their nameservers so currently there
> is no point supplying your IPv6 netblocks in any case. You're not
> missing out.)
Oh right. I never even considered *checking* that. Of course they've got
IPv6 addresses, who hasn't who's running a server for high-volume public
use?
... most of the more stick-in-the-mud corners of the Internet, it turns
out.
> More here:
>
> https://www.mail-archive.com/mailop@mailop.org/msg23456.html
Wow, that thread is eye-opening. Fairly hilarious DNS management, I must
say...
> Their web site only half works. They were unable / unwilling to explain
> to me how they have calculated that I have exceeded their limits when
> I'm almost certain that I haven't. I find their corporate web site to be
> difficult to understand regarding what they actually do or sell. But
> their DNS lists *are* free so there is a limit to what one can expect. I
> don't have a lot of confidence that they will continue to exist as a
> company.
Indeed not.
> I don't think they should be in default SpamAssassin and if I experience
> any more problems with them then I'm going to disable lookups.
Ditto.
--
NULL && (void)
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Andy Smith <an...@strugglers.net>.
Hi,
On Wed, Nov 20, 2024 at 05:07:09PM +0000, Nix wrote:
> > From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>
> Tried registering here. I can register a v4 address, but every format of
> v6 CIDR I've tried reports "Invalid V6_CIDR" with (of course) no
I experienced the same a couple of months ago and reported it to them.
Their response after several weeks was:
"I investigated this with our engineering team. We currently don't
support IPV6 in the on the my validity/ zone file registration page.
Our product team is working to remove IPV6 as option.
Currently only IPV4 single and IPV4 range are supported. I apologize
for any confusion."
I see they haven't got around to removing the IPv6 features that they
consider a mistake yet then.
(They don't have IPv6 addresses on their nameservers so currently there
is no point supplying your IPv6 netblocks in any case. You're not
missing out.)
More here:
https://www.mail-archive.com/mailop@mailop.org/msg23456.html
Their web site only half works. They were unable / unwilling to explain
to me how they have calculated that I have exceeded their limits when
I'm almost certain that I haven't. I find their corporate web site to be
difficult to understand regarding what they actually do or sell. But
their DNS lists *are* free so there is a limit to what one can expect. I
don't have a lot of confidence that they will continue to exist as a
company.
I don't think they should be in default SpamAssassin and if I experience
any more problems with them then I'm going to disable lookups.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Greg Troxel <gd...@lexort.com>.
Nick Howitt <ni...@howitts.co.uk> writes:
>> ... the account is free and then they hit you with an EULA that says
>>
>>> The Services are available at the then-current rate. Customer shall
>>> pay all applicable fees when due as invoiced and, if fees are being
>>> paid via credit card or other electronic means, Customer authorizes
>>> Validity to charge fees using Customer’s selected payment method.
>> By my reading that means they can just decide to start charging you
>> and
>> you have no recourse?! Though the account is explicitly stated in huge
>> letters to be "free", so one hopes that would count as the "then-current
>> rate". The near-contradiction is unfortunate though, and there's no
>> indication about them having to tell you when they change their fees.
>> (Not that they could get any money from me without asking anyway.)
>> The account requires a 'company name', so I guess if you're an
>> individual you're... fucked?
>>
> Sorry but this is conspiracy theory rubbish. You can open an account
> easily and use your name as a business. You can possibly easily put in
> "none" or "n/a" and the account is yours. No billing details or
> address details at all so how can they suddenly start billing?
>
> Just accept that if you want to start using their information for
> free, you will have to give a name and email address. You will also
> need to declare an IP address or CIDR, presumably for their whitelist.
That is not rubbish. Terms that say you agree to pay are a serious
problem even if there is no credit card information on file. That has
the strong appearance of the Service intending to create an enforceable
contract. And a mandatory "company name" field appears to mean just
that. Nix makes an entirely fair point.
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nick Howitt <ni...@howitts.co.uk>.
On 20/11/2024 16:39, Nix wrote:
> On 20 Nov 2024, Nick Howitt uttered the following:
>
>>
>>
>> On 20/11/2024 12:55, Nix wrote:
>>> On 19 Nov 2024, Greg Troxel told this:
>>>
>>>> Matija Nalis <mn...@voyager.hr> writes:
>>>>
>>>>> From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>>>>>
>>>>>> Starting March 1, 2024, Validity will allow up to 10,000 requests to anonymous users over a 30-day period.
>>>>>
>>>>> 10k requests per 30-day period is about 333 queries/day. Or less than 14 queries per hour.
>>>>> Not very much at all (and certainly at least order of magnitude less than your stated traffic).
>>>>> No amount of local DNS caching is going to fix limits *that low*.
>>>>
>>>> That is remarkably low.
>>> ... the account is free and then they hit you with an EULA that says
>>>
>>>> The Services are available at the then-current rate. Customer shall
>>>> pay all applicable fees when due as invoiced and, if fees are being
>>>> paid via credit card or other electronic means, Customer authorizes
>>>> Validity to charge fees using Customer’s selected payment method.
>>> By my reading that means they can just decide to start charging you and
>>> you have no recourse?! Though the account is explicitly stated in huge
>>> letters to be "free", so one hopes that would count as the "then-current
>>> rate". The near-contradiction is unfortunate though, and there's no
>>> indication about them having to tell you when they change their fees.
>>> (Not that they could get any money from me without asking anyway.)
>>> The account requires a 'company name', so I guess if you're an
>>> individual you're... fucked?
>>
>> Sorry but this is conspiracy theory rubbish. You can open an account
>> easily and use your name as a business. You can possibly easily put in
>> "none" or "n/a" and the account is yours. No billing details or
>> address details at all so how can they suddenly start billing?
>
> They can't, but they might think they can start hitting you with bill
> demands out of the blue. Having just gone through exactly that with my
> electricity provider (where due to terrible record-keeping it suddenly
> decided I was an unrelated business and owed them tens of thousands of
> someone else's bill: it took months to sort out and I had to threaten
> them with legal action and the press), I am a *little* paranoid about
> that sort of thing right now.
>
> In the UK at least a large number of consumer protection laws cease to
> apply if you're a business (not that I am).
>
>> Just accept that if you want to start using their information for
>> free, you will have to give a name and email address. You will also
>> need to declare an IP address or CIDR, presumably for their whitelist.
>
> Yeah. *That* I have no objection to. It's the requirement to agree to a
> cut-and-paste EULA and the assumption that any users must be corporate
> that is... concerning.
>
I am also in the UK. Just put None as the business name, then. If you're
really worried, use a disposable email, but then they can't tell you if
you breach their limits.
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nix <ni...@esperi.org.uk>.
On 20 Nov 2024, Nick Howitt uttered the following:
>
>
> On 20/11/2024 12:55, Nix wrote:
>> On 19 Nov 2024, Greg Troxel told this:
>>
>>> Matija Nalis <mn...@voyager.hr> writes:
>>>
>>>> From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>>>>
>>>>> Starting March 1, 2024, Validity will allow up to 10,000 requests to anonymous users over a 30-day period.
>>>>
>>>> 10k requests per 30-day period is about 333 queries/day. Or less than 14 queries per hour.
>>>> Not very much at all (and certainly at least order of magnitude less than your stated traffic).
>>>> No amount of local DNS caching is going to fix limits *that low*.
>>>
>>> That is remarkably low.
>> ... the account is free and then they hit you with an EULA that says
>>
>>> The Services are available at the then-current rate. Customer shall
>>> pay all applicable fees when due as invoiced and, if fees are being
>>> paid via credit card or other electronic means, Customer authorizes
>>> Validity to charge fees using Customer’s selected payment method.
>> By my reading that means they can just decide to start charging you and
>> you have no recourse?! Though the account is explicitly stated in huge
>> letters to be "free", so one hopes that would count as the "then-current
>> rate". The near-contradiction is unfortunate though, and there's no
>> indication about them having to tell you when they change their fees.
>> (Not that they could get any money from me without asking anyway.)
>> The account requires a 'company name', so I guess if you're an
>> individual you're... fucked?
>
> Sorry but this is conspiracy theory rubbish. You can open an account
> easily and use your name as a business. You can possibly easily put in
> "none" or "n/a" and the account is yours. No billing details or
> address details at all so how can they suddenly start billing?
They can't, but they might think they can start hitting you with bill
demands out of the blue. Having just gone through exactly that with my
electricity provider (where due to terrible record-keeping it suddenly
decided I was an unrelated business and owed them tens of thousands of
someone else's bill: it took months to sort out and I had to threaten
them with legal action and the press), I am a *little* paranoid about
that sort of thing right now.
In the UK at least a large number of consumer protection laws cease to
apply if you're a business (not that I am).
> Just accept that if you want to start using their information for
> free, you will have to give a name and email address. You will also
> need to declare an IP address or CIDR, presumably for their whitelist.
Yeah. *That* I have no objection to. It's the requirement to agree to a
cut-and-paste EULA and the assumption that any users must be corporate
that is... concerning.
--
NULL && (void)
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nick Howitt <ni...@howitts.co.uk>.
On 20/11/2024 12:55, Nix wrote:
> On 19 Nov 2024, Greg Troxel told this:
>
>> Matija Nalis <mn...@voyager.hr> writes:
>>
>>> From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>>>
>>>> Starting March 1, 2024, Validity will allow up to 10,000 requests to anonymous users over a 30-day period.
>>>
>>> 10k requests per 30-day period is about 333 queries/day. Or less than 14 queries per hour.
>>> Not very much at all (and certainly at least order of magnitude less than your stated traffic).
>>> No amount of local DNS caching is going to fix limits *that low*.
>>
>> That is remarkably low.
>
> ... the account is free and then they hit you with an EULA that says
>
>> The Services are available at the then-current rate. Customer shall
>> pay all applicable fees when due as invoiced and, if fees are being
>> paid via credit card or other electronic means, Customer authorizes
>> Validity to charge fees using Customer’s selected payment method.
>
> By my reading that means they can just decide to start charging you and
> you have no recourse?! Though the account is explicitly stated in huge
> letters to be "free", so one hopes that would count as the "then-current
> rate". The near-contradiction is unfortunate though, and there's no
> indication about them having to tell you when they change their fees.
> (Not that they could get any money from me without asking anyway.)
>
> The account requires a 'company name', so I guess if you're an
> individual you're... fucked?
>
Sorry but this is conspiracy theory rubbish. You can open an account
easily and use your name as a business. You can possibly easily put in
"none" or "n/a" and the account is yours. No billing details or address
details at all so how can they suddenly start billing?
Just accept that if you want to start using their information for free,
you will have to give a name and email address. You will also need to
declare an IP address or CIDR, presumably for their whitelist.
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nix <ni...@esperi.org.uk>.
On 19 Nov 2024, Greg Troxel told this:
> Matija Nalis <mn...@voyager.hr> writes:
>
>> From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>>
>>> Starting March 1, 2024, Validity will allow up to 10,000 requests to anonymous users over a 30-day period.
>>
>> 10k requests per 30-day period is about 333 queries/day. Or less than 14 queries per hour.
>> Not very much at all (and certainly at least order of magnitude less than your stated traffic).
>> No amount of local DNS caching is going to fix limits *that low*.
>
> That is remarkably low.
... the account is free and then they hit you with an EULA that says
> The Services are available at the then-current rate. Customer shall
> pay all applicable fees when due as invoiced and, if fees are being
> paid via credit card or other electronic means, Customer authorizes
> Validity to charge fees using Customer’s selected payment method.
By my reading that means they can just decide to start charging you and
you have no recourse?! Though the account is explicitly stated in huge
letters to be "free", so one hopes that would count as the "then-current
rate". The near-contradiction is unfortunate though, and there's no
indication about them having to tell you when they change their fees.
(Not that they could get any money from me without asking anyway.)
The account requires a 'company name', so I guess if you're an
individual you're... fucked?
--
NULL && (void)
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Greg Troxel <gd...@lexort.com>.
Nick Howitt <ni...@howitts.co.uk> writes:
>> Has SA doctrine changed in terms of default ruleset inclusion of RBLs
>> that block small sites with properly-configured resolvers? I managed
>> to miss the new feature of detecting blockage and disabling that RBL,
>> and I can see that with that feature, having default rules that are
>> blocked for many reasonable personal use systems is less problematic.
>>
> So what happens to the limit when you register with them?
A good question, but I have never perceived it being ok to have to
register for default ruleset RBLs. (What people intentionally and agree
to with account creation is of course up to them.)
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nick Howitt <ni...@howitts.co.uk>.
On 19/11/2024 13:53, Greg Troxel wrote:
> Matija Nalis<mn...@voyager.hr> writes:
>
>> Fromhttps://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>>
>>> Starting March 1, 2024, Validity will allow up to 10,000 requests to anonymous users over a 30-day period.
>> 10k requests per 30-day period is about 333 queries/day. Or less than 14 queries per hour.
>> Not very much at all (and certainly at least order of magnitude less than your stated traffic).
>> No amount of local DNS caching is going to fix limits *that low*.
> That is remarkably low.
>
> A quick check for me shows just over 10K messages processed by SA. I
> didn't However a bunch of them hit shortcircuit rules (e.g. DKIM
> welcomelist) and thus I suspect some of those don't query RBLs (but logs
> show some do). So perhaps I am just squeaking by. And yes, I am
> running my own resolver.
>
> This is a personal server. While I can see that some personal servers
> would be under a 10k/30d limit, this is quite different from a 50k or
> 100k limit and I'd expect many even single-person servers to get
> blocked.
>
> Has SA doctrine changed in terms of default ruleset inclusion of RBLs
> that block small sites with properly-configured resolvers? I managed
> to miss the new feature of detecting blockage and disabling that RBL,
> and I can see that with that feature, having default rules that are
> blocked for many reasonable personal use systems is less problematic.
>
So what happens to the limit when you register with them?
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Greg Troxel <gd...@lexort.com>.
Matija Nalis <mn...@voyager.hr> writes:
> From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>
>> Starting March 1, 2024, Validity will allow up to 10,000 requests to anonymous users over a 30-day period.
>
> 10k requests per 30-day period is about 333 queries/day. Or less than 14 queries per hour.
> Not very much at all (and certainly at least order of magnitude less than your stated traffic).
> No amount of local DNS caching is going to fix limits *that low*.
That is remarkably low.
A quick check for me shows just over 10K messages processed by SA. I
didn't However a bunch of them hit shortcircuit rules (e.g. DKIM
welcomelist) and thus I suspect some of those don't query RBLs (but logs
show some do). So perhaps I am just squeaking by. And yes, I am
running my own resolver.
This is a personal server. While I can see that some personal servers
would be under a 10k/30d limit, this is quite different from a 50k or
100k limit and I'd expect many even single-person servers to get
blocked.
Has SA doctrine changed in terms of default ruleset inclusion of RBLs
that block small sites with properly-configured resolvers? I managed
to miss the new feature of detecting blockage and disabling that RBL,
and I can see that with that feature, having default rules that are
blocked for many reasonable personal use systems is less problematic.
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Kris Deugau <kd...@vianet.ca>.
Nix wrote:
> On 19 Nov 2024, Matija Nalis stated:
>
>> On Mon, Nov 18, 2024 at 05:21:12PM +0000, Nix wrote:
>>> I'm not a high-volume site, a few thousand mails a day. If I'm blocked,
>>> probably more or less everyone is being blocked. (Are the DNSBLs above
>>
>> Yes, pretty much every non-paying customer is blocked...
>>
>> From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>
> Tried registering here. I can register a v4 address, but every format of
> v6 CIDR I've tried reports "Invalid V6_CIDR" with (of course) no
> indication of what formats they actually accept. Since I (like everyone
> should) issue outgoing queries from random addresses within a given /64,
> non-CIDR is a lost cause...
>
> I remember when these people weren't a complete shower :/
From recent posts on the mailop list, the fact that an IPv6
field/selection is offered on whichever form that is, is an error/bug as
they do not support queries over IPv6, so there's no point in providing
a v6 IP/range that you would be sending queries from.
-kgd
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nick Howitt <ni...@howitts.co.uk>.
On 20/11/2024 17:07, Nix wrote:
> On 19 Nov 2024, Matija Nalis stated:
>
>> On Mon, Nov 18, 2024 at 05:21:12PM +0000, Nix wrote:
>>> I'm not a high-volume site, a few thousand mails a day. If I'm blocked,
>>> probably more or less everyone is being blocked. (Are the DNSBLs above
>>
>> Yes, pretty much every non-paying customer is blocked...
>>
>> From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
>
> Tried registering here. I can register a v4 address, but every format of
> v6 CIDR I've tried reports "Invalid V6_CIDR" with (of course) no
> indication of what formats they actually accept. Since I (like everyone
> should) issue outgoing queries from random addresses within a given /64,
> non-CIDR is a lost cause...
>
> I remember when these people weren't a complete shower :/
Virgin don't give me IPv6, so I can't comment.
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nix <ni...@esperi.org.uk>.
On 19 Nov 2024, Matija Nalis stated:
> On Mon, Nov 18, 2024 at 05:21:12PM +0000, Nix wrote:
>> I'm not a high-volume site, a few thousand mails a day. If I'm blocked,
>> probably more or less everyone is being blocked. (Are the DNSBLs above
>
> Yes, pretty much every non-paying customer is blocked...
>
> From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
Tried registering here. I can register a v4 address, but every format of
v6 CIDR I've tried reports "Invalid V6_CIDR" with (of course) no
indication of what formats they actually accept. Since I (like everyone
should) issue outgoing queries from random addresses within a given /64,
non-CIDR is a lost cause...
I remember when these people weren't a complete shower :/
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Matija Nalis <mn...@voyager.hr>.
On Mon, Nov 18, 2024 at 05:21:12PM +0000, Nix wrote:
> I'm not a high-volume site, a few thousand mails a day. If I'm blocked,
> probably more or less everyone is being blocked. (Are the DNSBLs above
Yes, pretty much every non-paying customer is blocked...
From https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS :
> Starting March 1, 2024, Validity will allow up to 10,000 requests to anonymous users over a 30-day period.
10k requests per 30-day period is about 333 queries/day. Or less than 14 queries per hour.
Not very much at all (and certainly at least order of magnitude less than your stated traffic).
No amount of local DNS caching is going to fix limits *that low*.
> (Are the DNSBLs above all run by the same entity now?)
You mean RCVD_IN_VALIDITY_* ?
Yes, I'd very much assume they're all run by Validity.
> ... hm actually perhaps my checks of mail to a couple of high-volume
> mailing lists are triggering it. I wonder if I can prevent those DNSBLs
> from being consulted just for mail apparently to those lists?
>
> But, really... what on earth is going on in that message?
>
> Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
As it suggests, Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries.
(unless you intend to become their paying cusomer, or heavily customize your ruleset to only query them on very small subset of messages to stay under those limits)
> So there's a mention of a file under
> /etc/mail/spamassassin/helpers/.spamassassin/, but that directory is
> empty (writable only by root, but spamd is running as root). Is this
> just a misfire because it's trying to write after dropping privileges or
> something?
Probably. You could strace(1) it to see if and why it is failing to create a file.
Your spamd is probably (hopefully!) dropping permissions to some user before doing all those zillions of checks, so it should be writeable by that user.
--
Opinions above are GNU-copylefted.
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Nix <ni...@esperi.org.uk>.
On 14 Nov 2024, Mark London uttered the following:
> FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered for
> every email that our server received. I do not use a public DNS server. I disabled all of them. Strange. - Mark
I'm seeing this too. I'm not a high-volume site, yet...
Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_SAFE_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_sa-accredit.habeas.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-accredit.habeas.com" to disable queries)
Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_CERTIFIED_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_sa-trusted.bondedsender.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-trusted.bondedsender.org" to disable queries)
Nov 14 00:00:26 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_CERTIFIED_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_sa-trusted.bondedsender.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-trusted.bondedsender.org" to disable queries)
Nov 14 00:00:26 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_SAFE_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_sa-accredit.habeas.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-accredit.habeas.com" to disable queries)
I'm not a high-volume site, a few thousand mails a day. If I'm blocked,
probably more or less everyone is being blocked. (Are the DNSBLs above
all run by the same entity now?)
... hm actually perhaps my checks of mail to a couple of high-volume
mailing lists are triggering it. I wonder if I can prevent those DNSBLs
from being consulted just for mail apparently to those lists?
But, really... what on earth is going on in that message?
Nov 14 00:00:03 loom warning: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
So there's a mention of a file under
/etc/mail/spamassassin/helpers/.spamassassin/, but that directory is
empty (writable only by root, but spamd is running as root). Is this
just a misfire because it's trying to write after dropping privileges or
something?
--
NULL && (void)
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 13.11.24 22:15, Mark London wrote:
>FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED,
>RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered
>for every email that our server received. I do not use a public DNS
>server. I disabled all of them. Strange. - Mark
Do you have trustpath configured properly?
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustPath
- if you use backup MX server which is listed here, it may cause this
problem.
do you update your rules?
those three rules use different dnswls:
header RCVD_IN_VALIDITY_CERTIFIED eval:check_rbl('ssc-firsttrusted', 'sa-trusted.bondedsender.org.', '^127\.0\.0\.')
header RCVD_IN_VALIDITY_RPBL eval:check_rbl('rnbl-lastexternal', 'bl.score.senderscore.com.', '^127\.0\.0\.')
header RCVD_IN_VALIDITY_SAFE eval:check_rbl('ssc-firsttrusted', 'sa-accredit.habeas.com.', '^127\.0\.0\.')
- maybe you have old rules from time *_BLOCKED was not tested:
header RCVD_IN_VALIDITY_CERTIFIED_BLOCKED eval:check_rbl('ssc-firsttrusted', 'sa-trusted.bondedsender.org.', '127.255.255.255')
header RCVD_IN_VALIDITY_RPBL_BLOCKED eval:check_rbl('rnbl-lastexternal', 'bl.score.senderscore.com.', '127.255.255.255')
header RCVD_IN_VALIDITY_SAFE_BLOCKED eval:check_rbl('ssc-firsttrusted', 'sa-accredit.habeas.com.', '127.255.255.255')
Do you use your own DNS server?
Doesn't your ISP intercept DNS queries?
--
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.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watkins. -- Daffy Duck & Porky Pig
Re: All RCVD_IN_VALIDITY rules being applied to every email.
Posted by Jared Hall via users <us...@spamassassin.apache.org>.
On 11/13/2024 10:15 PM, Mark London wrote:
> FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED,
> RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered
> for every email that our server received. I do not use a public DNS
> server. I disabled all of them. Strange. - Mark
Not enough information. Could simply be a case of DNS poisoning?
-- Jared Hall