Den 31-01-2021 kl. 18:43 skrev Matus UHLAR - fantomas:
> On 31.01.21 16:30, Arne Jensen wrote:
>> If this one causes false positives for anyone, then that actual
>> person/organisation (obviously, MX operator side) that it causes false
>> positives for, are the one to blame.
>>
>> Spamcop hasn't ever listed "91.195.240.87" a valid return code, have
>> they?
>
> ...even spamcop's howto doesn't describe using the code:
>
> https://www.spamcop.net/fom-serve/cache/349.html
>
That particular link (and many other example out there) can indeed be
improved, however.
Postfix says:
> [Feature 20030715] Support for multi-valued RBL lookup results.
> For example, specify "reject_rbl_client foo.bar.tld=127.0.0.3" to
> reject clients that are listed with a "127.0.0.3" address record.
> More information is in the postconf(5) manual page.
Spamcop.net was registered on 1999-01-30, roughly 4.5 years before.
Maybe Spamcop made the Postfix example on their site, before Postfix
implemented this, and haven't yet received any feedback about it?
Click the "How do I configure my mailserver to reject mail based on the
blocklist?" link, that you see on top of the link you sent, and you will
be pointed to the actual site which I linked in the Google cache link
(due to spamcop.net being unavailable at the time):
->
https://www.spamcop.net/fom-serve/cache/291.html It literally also says:
> We recommend that when using any spam filtering method, users be given
> access to the filtered mail - don't block the mail as documented here,
> but store it in a separate mailbox. Or tag it and provide users
> documentation so that they can filter based on the tags in their own
> MUA. We provide this information only for administrators who cannot
> use a more subtle approach for whatever reason.
So eh, depending on how you interpret that one, then by rejecting it
outright, ... you aren't really following their advice either.
But again, unless you have already done so, it's a good time now to make
sure you check the return codes properly, not just for Spamcop, but for
all black/white-lists that you use may eventually use.
DNSWL (whitelist) will return 127.0.0.255, if you're over quota or using
public resolvers.
Spamhaus (blacklist) will return 127.255.255.x responses, if you're over
quota, using public resolvers or otherwise incorrect queries.
URIBL (black/mix list(s)) will return 127.0.0.1 / 127.0.0.255, if you're
over quota or using public resolvers, or otherwise seeming to be abusive
towards their infrastructure.
... and so will likely many (if not most/all) others, too.
Blindly accepting every single DNS response (A records) as a
positive/negative code for those kind of lists WILL backfire at some point.
After all, you are the only one to blame for eventual careless (lack of)
actions, on your systems, including eventual consequences coming as a
result of them.
>> Note that the spamcop.net domain simply hasn't been renewed! It hasn't
>> *YET* been "overtaken by someone", as you say.
>
> it has been overtaken by registrar and provided with fake data.
> (I wouldn't expect this from serious registrar)
>
The majority (if not all) registrars (of any major NON-country code
TLD's) will do something like that, going from expiration date and
generally up to around ~7-45 days after the expiration date, where the
domain is (finally) being deleted completely, and made available for new
registrants to take.
Remember, it only happens after several reminder notifications and
without payment. I'm always getting several reminders before things like
this happens, regardless which registrar I've been using.
But considering your phrasing, ... isn't it also possible to argue
whether Spamcop is really something serious?
e.g.
a) They ignored multiple notifications about their expiring domain
b) They eventually didn't care enough to monitor their things properly
... I guess we could go on?
So what about a "serious company/organisation"? I mean, wouldn't a such
one have enough things in place, to make sure that their domains didn't
expire, like it happened here?
--
Med venlig hilsen / Kind regards,
Arne Jensen