Mailing List Archive

<vendor>

Hi,

I can't speak for the other feeds, but for our (DROP), if you register a
DQS key and install our plugin it would work out of the box

</vendor>

On 10/11/22 17:54, Joey J wrote:
>
> I'm trying to incorporate:
> feeds.dshield.org/block.txt <http://feeds.dshield.org/block.txt>
> spamhaus.org/drop/drop.lasso <http://spamhaus.org/drop/drop.lasso>
> ciarmy.com/list/ci-badguys.txt <http://ciarmy.com/list/ci-badguys.txt>
> openbl.org/lists/base.txt <http://openbl.org/lists/base.txt>
>
>
--
Best regards,
Riccardo Alfieri

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

On 11/10/22 9:54 AM, Joey J wrote:
> Hello All,

Hi,

> I'm trying to see if there is a way to incorporate network ranges into
> SA to essentially flag messages.

N.B. at least one of the lists below is individual IPs and not networks
/ ranges of IPs. -- I'm not sure how to square that peg with your
wants / needs.

> I know I can use iptables and reject it before getting to SA, but in
> some cases we would have legit email get flagged within these bigger blocks.

I would suggest investigating the other offerings from each vendor. I
suspect there is a good chance that many, if not all, of them offer a
DNS based query method.

See Riccardo's comment about Spamhaus / Spamteq.

> I'm trying to incorporate:
> feeds.dshield.org/block.txt
> spamhaus.org/drop/drop.lasso
> ciarmy.com/list/ci-badguys.txt
> openbl.org/lists/base.txt
Short of that, it wouldn't be hard to turn them into a locally hosted BL
and then configure SpamAssassin to query it.



--
Grant. . . .
unix || die

I've been dealing with IP blocklists using two other methods before
email even reaches SA:
- In postfix my smtpd_recipient_restrictions includes "reject_rbl_client
zen.spamhaus.org, reject_rhsbl_reverse_client dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org, reject_rhsbl_sender
dbl.spamhaus.org" and I'm guessing potentially others could be added.
- IP/CIDR lists like the one you mention, but also lists like Stop Forum
Spam (https://www.stopforumspam.com/) I cron fetch then add to an ipset
with a DROP (which is quite similar to what others are suggesting).
I find that those are quite suitable.

Bert

On 10/11/2022 18:05, Grant Taylor via users wrote:
> On 11/10/22 9:54 AM, Joey J wrote:
>> Hello All,
>
> Hi,
>
>> I'm trying to see if there is a way to incorporate network ranges
>> into SA to essentially flag messages.
>
> N.B. at least one of the lists below is individual IPs and not
> networks / ranges of IPs.  --  I'm not sure how to square that peg
> with your wants / needs.
>
>> I know I can use iptables and reject it before getting to SA, but in
>> some cases we would have legit email get flagged within these bigger
>> blocks.
>
> I would suggest investigating the other offerings from each vendor.  I
> suspect there is a good chance that many, if not all, of them offer a
> DNS based query method.
>
> See Riccardo's comment about Spamhaus / Spamteq.
>
>> I'm trying to incorporate:
>> feeds.dshield.org/block.txt
>> spamhaus.org/drop/drop.lasso
>> ciarmy.com/list/ci-badguys.txt
>> openbl.org/lists/base.txt
> Short of that, it wouldn't be hard to turn them into a locally hosted
> BL and then configure SpamAssassin to query it.
>
>
>

On 11/11/22 9:09 AM, Bert Van de Poel wrote:
> - IP/CIDR lists like the one you mention, but also lists like Stop Forum
> Spam (https://www.stopforumspam.com/) I cron fetch then add to an ipset
> with a DROP (which is quite similar to what others are suggesting).

Stop Forum Spam seems interesting.

I'd be curious to see how you're converting SFS list(s) to ipset
entries. Mostly I've not yet had enough coffee to convert from a range
of IPs; <start>-<stop>, to CIDR; <network>/<netmask>.

I didn't pay close attention to the list, but I did see that it was
range based and would need some conversion. -- I have added it to my
pile of things to look at more closely later.



--
Grant. . . .
unix || die

On 11.11.22 17:09, Bert Van de Poel wrote:
>I've been dealing with IP blocklists using two other methods before
>email even reaches SA:
>- In postfix my smtpd_recipient_restrictions includes
>"reject_rbl_client zen.spamhaus.org, reject_rhsbl_reverse_client
>dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org,
>reject_rhsbl_sender dbl.spamhaus.org" and I'm guessing potentially
>others could be added.

I recomment switching DNSBL processing at postfix level to postscreen
http://www.postfix.org/POSTSCREEN_README.html
which supports multiple weighed block and allow lists.

(not only) because of this I have local DNSBL for these.

...and they can be used on SA level too.

--
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.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."

On 2022-11-11 at 11:26:13 UTC-0500 (Fri, 11 Nov 2022 09:26:13 -0700)
Grant Taylor via users <gtaylor@tnetconsulting.net>
is rumored to have said:

> On 11/11/22 9:09 AM, Bert Van de Poel wrote:
>> - IP/CIDR lists like the one you mention, but also lists like Stop Forum Spam (https://www.stopforumspam.com/) I cron fetch then add to an ipset with a DROP (which is quite similar to what others are suggesting).
>
> Stop Forum Spam seems interesting.
>
> I'd be curious to see how you're converting SFS list(s) to ipset entries. Mostly I've not yet had enough coffee to convert from a range of IPs; <start>-<stop>, to CIDR; <network>/<netmask>.

From my bashrc...

# type cidrcon
cidrcon is a function
cidrcon ()
{
for a in $*;
do
echo $a;
done | perl -e "use Net::CIDR::Lite; \$cidr = Net::CIDR::Lite->new(<>) ; \$_ = join (\"\n\",\$cidr->list) ; print \"\$_\n\";"
}

Obviously requires Perl and the Net::CIDR::Lite module. I do not recall why the implementation is so weird, but I've been using it for decades(!?)


> I didn't pay close attention to the list, but I did see that it was range based and would need some conversion. -- I have added it to my pile of things to look at more closely later.
>
>
>
> --
> Grant. . . .
> unix || die


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

Actually, ipset supports <start>-<stop> syntax:
       CREATE-OPTIONS := range fromip-toip|ip/cidr [ netmask cidr ] [
timeout value ] [ counters ] [ comment ] [ skbinfo ]


On 11/11/2022 18:10, Bill Cole wrote:
> On 2022-11-11 at 11:26:13 UTC-0500 (Fri, 11 Nov 2022 09:26:13 -0700)
> Grant Taylor via users <gtaylor@tnetconsulting.net>
> is rumored to have said:
>
>> On 11/11/22 9:09 AM, Bert Van de Poel wrote:
>>> - IP/CIDR lists like the one you mention, but also lists like Stop Forum Spam (https://www.stopforumspam.com/) I cron fetch then add to an ipset with a DROP (which is quite similar to what others are suggesting).
>> Stop Forum Spam seems interesting.
>>
>> I'd be curious to see how you're converting SFS list(s) to ipset entries. Mostly I've not yet had enough coffee to convert from a range of IPs; <start>-<stop>, to CIDR; <network>/<netmask>.
> From my bashrc...
>
> # type cidrcon
> cidrcon is a function
> cidrcon ()
> {
> for a in $*;
> do
> echo $a;
> done | perl -e "use Net::CIDR::Lite; \$cidr = Net::CIDR::Lite->new(<>) ; \$_ = join (\"\n\",\$cidr->list) ; print \"\$_\n\";"
> }
>
> Obviously requires Perl and the Net::CIDR::Lite module. I do not recall why the implementation is so weird, but I've been using it for decades(!?)
>
>
>> I didn't pay close attention to the list, but I did see that it was range based and would need some conversion. -- I have added it to my pile of things to look at more closely later.
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die

On 11/11/22 10:10 AM, Bill Cole wrote:
> From my bashrc...
>
> # type cidrcon
> cidrcon is a function
> cidrcon ()
> {
> for a in $*;
> do
> echo $a;
> done | perl -e "use Net::CIDR::Lite; \$cidr = Net::CIDR::Lite->new(<>) ; \$_ = join (\"\n\",\$cidr->list) ; print \"\$_\n\";"
> }

Oh ... (minimally) obfuscated Perl one liner.

N.B. My Perl is rusty.

Let's try deobfuscating and interpreting.

> use Net::CIDR::Lite;

Load the Net::CIDR::Lite module.

> $cidr = Net::CIDR::Lite->new(<>);

Instantiate an instance of the Net::CIDR::Lite module.

It also looks like you're reading from STDIN via "<>". Is that correct?

I feel like that's a Perlish short cut to opening the STDIN. I have
almost always used an "open" statement for such.

> $_ = join ("\n",$cidr->list);

Set the unnamed variable to the output of the list output from the
Net::CIDR::Lite object using new lines.

> print "$_\n";

Print the unnamed variable with a trailing new line.

I /think/.

Am I close?

> Obviously requires Perl and the Net::CIDR::Lite module. I do not
> recall why the implementation is so weird, but I've been using it
> for decades(!?)

The deobfuscated code doesn't seem weird to me.

I suspect some of the weirdness comes from transforming it into a one
liner and escaping things as necessary to pass it from shell to Perl.

I guess it may be a little weird that the cidrcon() shell function takes
multiple parameters and prints each of them on a line to pass into Perl.

I wonder if it was easier / simpler to do -- what I call -- the rotation
(from one line with multiple parameters to multiple lines with one
parameter) in shell than to deal with them in Perl.

Thank you for sharing Bill. -- Your message has been waiting for me to
read, analyze, assimilate, and reply. ;-)



--
Grant. . . .
unix || die

On 2022-11-14 at 14:09:14 UTC-0500 (Mon, 14 Nov 2022 12:09:14 -0700)
Grant Taylor via users <gtaylor@tnetconsulting.net>
is rumored to have said:

> On 11/11/22 10:10 AM, Bill Cole wrote:
>> From my bashrc...
>>
>> # type cidrcon
>> cidrcon is a function
>> cidrcon ()
>> {
>> for a in $*;
>> do
>> echo $a;
>> done | perl -e "use Net::CIDR::Lite; \$cidr = Net::CIDR::Lite->new(<>) ; \$_ = join (\"\n\",\$cidr->list) ; print \"\$_\n\";"
>> }
>
> Oh ... (minimally) obfuscated Perl one liner.

Not obfuscated, inherently obscure.

>
> N.B. My Perl is rusty.
>
> Let's try deobfuscating and interpreting.

Uh oh. I wrote that *years* ago, and don't recall what I was thinking in the specific code...

>> use Net::CIDR::Lite;
>
> Load the Net::CIDR::Lite module.
>
>> $cidr = Net::CIDR::Lite->new(<>);
>
> Instantiate an instance of the Net::CIDR::Lite module.
>
> It also looks like you're reading from STDIN via "<>". Is that correct?

Um, well... Yes. I suppose I am. Took me some time to look at that again and understand it...

The 'for' loop provides STDIN data via a pipe to perl. One command line arg per line.

> I feel like that's a Perlish short cut to opening the STDIN. I have almost always used an "open" statement for such.

Do not overthink my code. I assure you that I did not.

<> in Perl is an operator that returns either each line from STDIN one at a time (scalar context) or all lines available from STDIN (until eof) as an array of lines.

>> $_ = join ("\n",$cidr->list);
>
> Set the unnamed variable

Au Contraire!

That's a scalar named '_' (see 'man perlvar')

> to the output of the list output from the Net::CIDR::Lite object using new lines.

Correct. NCL->list returns a list of CIDR networks. This joins them all with linefeeds to get them into one handy scalar. named _

>> print "$_\n";
>
> Print the unnamed variable with a trailing new line.

Yes.

> I /think/.
>
> Am I close?

Yes.

>> Obviously requires Perl and the Net::CIDR::Lite module. I do not recall why the implementation is so weird, but I've been using it for decades(!?)
>
> The deobfuscated code doesn't seem weird to me.
>
> I suspect some of the weirdness comes from transforming it into a one liner and escaping things as necessary to pass it from shell to Perl.
>
> I guess it may be a little weird that the cidrcon() shell function takes multiple parameters and prints each of them on a line to pass into Perl.
>
> I wonder if it was easier / simpler to do -- what I call -- the rotation (from one line with multiple parameters to multiple lines with one parameter) in shell than to deal with them in Perl.

I can't even begin to recall.

I wrote it circa 2003 as part of a tool only I haver ever used which transforms a blocklist in an irregular perverse range format into multiple output formats, including a consolidated collection of CIDR blocks for a packet filter on an old Flowpoint router and a BIND zone file. The whole mess included Expect scripts too...

> Thank you for sharing Bill. -- Your message has been waiting for me to read, analyze, assimilate, and reply. ;-)

Always willing to share my shoddy code.

And that's not put-on modesty. I go back into old code myself and wonder WTF I was thinking and why I didn't do things otherwise. I think I've quite literally forgotten everything I ever formally learned about programming, and it shows.

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