I wonder how it works for real, since mailspike.net itself fails DNS resolution.
On Tuesday, May 20th, 2025 at 6:57 PM, Reindl Harald (privat)
<ha...@rhsoft.net> wrote:
>
>
> suree, but nobody is using "rep.mailspike.net" since MSPIKE is part of
> the default rules
>
> header __RCVD_IN_MSPIKE_B eval:check_rbl('mspikeb-lastexternal',
> 'bl.mailspike.net.')
> tflags __RCVD_IN_MSPIKE_B net
> reuse __RCVD_IN_MSPIKE_B
> header __RCVD_IN_MSPIKE_L eval:check_rbl('mspikeg-firsttrusted',
> 'wl.mailspike.net.')
> tflags __RCVD_IN_MSPIKE_L net
> reuse __RCVD_IN_MSPIKE_L
> header __RCVD_IN_MSPIKE_Z
> eval:check_rbl_sub('mspikeb-lastexternal', '127.0.0.2')
>
> Am 20.05.25 um 18:42 schrieb Rupert Gallagher:
>
> > I assume some of you is using it.
> >
> > https://cwiki.apache.org/confluence/display/spamassassin/DnsBlocklists#dnsbl-block
> >
> > On Tuesday, May 20th, 2025 at 5:32 PM, Rupert Gallagher r...@protonmail.com
> > wrote:
> >
> > > Hello,
> > >
> > > Is rep.mailspike.net working for you?
> > >
> > > If I query 78.153.140.99 at https://mailspike.io/ip_verify I get
> > > 127.0.0.11, however if I query using dig I get no answer at all, and the
> > > name server itself does not exist.
> > >
> > > > dig +short -t A 99.140.153.78.rep.mailspike.net
> > >
> > > [no answer]
> > >
> > > > dig @1.1.1.1 +short -t A rep.mailspike.net
> > >
> > > [no answer]
> > >
> > > > dig @8.8.8.8 +short -t A rep.mailspike.net
> > >
> > > [no answer]
> > >
> > > > dig @127.0.0.1 +short -t A rep.mailspike.net
> > >
> > > [no answer]
>
>
> --
>
> Mit besten Grüßen, Reindl Harald
> Andreas-Hofer-Straße 17/2/4
> A-1210 Wien
> +43 676 40 221 40
