From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4fZB8540rkz32cx for ; Mon, 16 Mar 2026 10:26:13 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fZB852WwXz2xMP for ; Mon, 16 Mar 2026 10:26:13 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4fZB830CbmzBx; Mon, 16 Mar 2026 10:26:10 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1773656771; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=URoWXdxlFdfh9FIqNgJc8udMNqB3WO3DGfypLVLko5k=; b=yUP6RoKAFBjbRjSqmjU0hBBakOJWgqjC7AFBhleFT22JMozpm1ZePzf1mfhmKOnn3ayxOA np7A7vIpDwxhG6BA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1773656771; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=URoWXdxlFdfh9FIqNgJc8udMNqB3WO3DGfypLVLko5k=; b=hpFaH80QKJ+66df9D4f2f08set9HABECMRUDvTwehdLblLM60+eTFi2c5moCIuIckI9wij uLYebmL2CybAHm2WoMdELYuPuk4W336nlLuowlA61nx3c0iEiHAbmsDugWG2l1xiHuIS/v wj+6Cf5u6+BrQ4g0y7ahQTVgB2Sbjb7N3U/Caw/9ujOopk4Te8Wk7pNliRluayeHAyknrY zMv/3ek0/HM5RFfyiKfRD+WDgZ9yy0G2KnjZTpj2SpcsUP90uruc6U9Wvl94HIddGAIix1 7zo1hXG5t1PhN9rKUgoY+Fg4B+m0WkiVBF9fQltwVxUpNzYEMzk15s3VXyOqxw== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: postcodeloterij.nl in Gambling category From: Michael Tremer In-Reply-To: Date: Mon, 16 Mar 2026 10:26:09 +0000 Cc: dbl@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adolf Belka Hello Adolf, Thanks for raising this. There seems to be a problem here indeed. > On 13 Mar 2026, at 17:49, Adolf Belka wrote: >=20 > Hi All, >=20 > postcodeloterij.nl is in 5 of the lists in the gambling category but I = was finding that it was not being blocked. >=20 > I checked and found that the domains file in the URL Filter blacklists = directory did not have the postcodeloterij.nl domain in it. That = obviously is why it was not being blocked. Correct. Since you reported the domain as missing and Stefan accepted = the report, I cannot reproduce the problem any more unfortunately. > I have reported in in the reporting system but am also reporting it = here as it is not that the lists have it and shouldn't or the lists = haven't got it and should, it is that the lists have it but it seems to = get filtered out when the domains list is created. >=20 > In the How to use section there are links to = https://dbl.ipfire.org/lists/gambling/domains.txt and this has no = entries for postcodeloterij.nl in it. >=20 > It looks like somehow in the creation of the gambling domains.txt file = the postcodeloterij.nl entries are not included for some reason. This is fixed now. I analysed my algorithm that is actually pulling all domains from the = lists and removing anything we don=E2=80=99t want to export. This seems = to be working well. The problem itself seems to be in the dead checker. I have found a = couple of more domains that seem to have been removed from the list = because the checker assumes that they are dead which they are not. I = manually ran the checker again on the affected domains and of course = they came back just fine :) So I am not sure where to go from here. Generally it is a good idea to = remove completely dead domains, but what is it worth if this is not 100% = accurate. We could still run the dead check to have a feeling about what our = upstream sources are giving us and simply always export everything. That = way, we are always on the safe side. The downside is that the lists = would at least double in size which means more bandwidth and more memory = usage for no reason. -Michael > Regards, >=20 > Adolf. >=20 >=20