Hello, I don’t quite know why, but rspamd considered this email very spammy:
2026-02-17 09:07:17 #2317039(rspamd_proxy) <82c6da>; proxy; rspamd_task_write_log: id: <[email protected]>, qid: <4fFYgT4dNNz5gt>, ip: 172.28.1.201, from: <[email protected]>, (default: T (reject): [12.21/11.00] [URL_OBFUSCATED_TEXT(9.00){type=bracket_dots;url=http://github.com;orig= ZONEMD RR (type 63) create phantom QNAME trigger ;orig=ZONEMD RR (type 63) create phantom QNAME trigger f;},SPAM_FLAG(5.00){},INTERNAL_BULK_SENDERS_IGNORED_AUTOLEARN(-2.00){},MID_CONTAINS_FROM(1.00){},NEURAL_HAM(-1.00){-1.000;},R_MISSING_CHARSET(0.50){},MAILLIST(-0.17){generic;},MIME_GOOD(-0.10){text/plain;},HAS_LIST_UNSUB(-0.01){},ALIAS_RESOLVED(0.00){},ARC_NA(0.00){},BAYES_SPAM(0.00){99.99%;},FORGED_RECIPIENTS_MAILLIST(0.00){},FORGED_SENDER_MAILLIST(0.00){},FROM_HAS_DN(0.00){},FROM_INTERNAL_BULK_SENDERS(0.00){172.28.1.201;},FROM_NEQ_ENVFROM(0.00){[email protected];[email protected];},LOCAL_OUTBOUND(0.00){},MIME_TRACE(0.00){0:+;},MISSING_XM_UA(0.00){},RCPT_COUNT_TWO(0.00){2;},RCVD_COUNT_THREE(0.00){3;},RCVD_TLS_LAST(0.00){},RCVD_VIA_SMTP_AUTH(0.00){},RECEIVED_HELO_LOCALHOST(0.00){},TAGGED_FROM(0.00){bounces-1725-XXX;},TO_DN_SOME(0.00){}]), len: 5175, time: 20.925ms, dns req: 21, digest: <4a22acd73bc52a0abae6476f118c1260>, rcpts: <XXX>, mime_rcpts: <[email protected],[email protected]> I don’t know what has caused the high score of the obfuscated URL which already scored 9 out of a total 12.21 points. The email also had "X-Spam: Yes” set in its headers which did not come from us. I will extract the patch from the archive. -Michael > On 17 Feb 2026, at 12:29, ummeegge <[email protected]> wrote: > > Yes, have send it to the list. Have a bouncing message report "Hi, this > is the Mlmmj program managing the <[email protected]> > mailing list. > > Some messages to you could not be delivered. If you're seeing this > message it means things are back to normal, and it's merely for your > information. > > Here is the list of the bounced messages: > - 1725" . > In the list i can see it here > https://lists.ipfire.org/development/[email protected]/T/#u > ??? > > Am Dienstag, dem 17.02.2026 um 10:13 +0000 schrieb Michael Tremer: >> Hello Erik, >> >> Where has it been sent to? To this list? >> >> I did not receive anything. >> >> -Michael >> >>> On 17 Feb 2026, at 09:18, ummeegge <[email protected]> wrote: >>> >>> Hello Michael, >>> sure. Patch has been delivered. >>> >>> Best, >>> >>> Erik >>> >>> Am Montag, dem 16.02.2026 um 16:11 +0000 schrieb Michael Tremer: >>>> Hello Erik, >>>> >>>> Thanks for the feedback. >>>> >>>> Good to hear that your problem could be solved upstream. >>>> >>>> Will you provide a patch to fix this in IPFire before the next >>>> release of Unbound? >>>> >>>> -Michael >>>> >>>>> On 16 Feb 2026, at 13:30, ummeegge <[email protected]> wrote: >>>>> >>>>> Yes, it took longer since I discovered it and I simply wanted >>>>> to >>>>> share >>>>> the insights with you all – thought it makes sense. >>>>> >>>>> Issue was opened yesterday: >>>>> https://github.com/NLnetLabs/unbound/issues/1404 >>>>> The fix has been committed today to the maintainer's fork: >>>>> https://github.com/dwongdev/unbound/commit/16e1e6d375e93e6c00c9b5d20ec4e50fb55d961f >>>>> It's a kind of "Root Cause Analysis" that delivered it there, >>>>> and >>>>> the >>>>> issue is meanwhile marked as 'completed' (low hanging fruit ;-) >>>>> ). >>>>> Hopefully it will soon be merged upstream. >>>>> >>>>> Have also tested the patch here now and it works like it >>>>> should: >>>>> AXFR/IXFR with multiple DBL zones, no problems at all. >>>>> >>>>> Best, >>>>> >>>>> Erik >>>>> >>>>> Am Montag, dem 16.02.2026 um 11:35 +0000 schrieb Michael >>>>> Tremer: >>>>>> Hello Erik, >>>>>> >>>>>> This is a *very* long email to tell us about a bug in >>>>>> Unbound. >>>>>> >>>>>> Did you report your problem there? >>>>>> >>>>>> -Michael >>>>>> >>>>>>> On 15 Feb 2026, at 11:58, ummeegge <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> We've identified a compatibility issue with the IPFire >>>>>>> Domain >>>>>>> Blocklist >>>>>>> (DBL) RPZ zones. These zones contain a ZONEMD record (Type >>>>>>> 63) >>>>>>> at >>>>>>> the >>>>>>> zone apex (e.g., ads.rpz.ipfire.org. 60 IN ZONEMD ...), >>>>>>> intended >>>>>>> for >>>>>>> data integrity checks. This record causes a critical >>>>>>> failure in >>>>>>> Unbound >>>>>>> DNS resolver when used with RPZ. >>>>>>> >>>>>>> Impact was here: >>>>>>> >>>>>>> DNSSEC Failure: Unbound does not ignore the ZONEMD >>>>>>> record >>>>>>> during >>>>>>> RPZ processing and mistakenly interprets the zone apex >>>>>>> record >>>>>>> as a >>>>>>> policy rule for the root name (.). >>>>>>> >>>>>>> Symptoms: After loading more than one IPFire RPZ zone or >>>>>>> modifying >>>>>>> the configuration file and restarting/reloading Unbound, >>>>>>> the >>>>>>> resolver >>>>>>> fails to prime its DNSSEC trust anchor. Typical log >>>>>>> entries: >>>>>>> >>>>>>> >>>>>>> unbound: info: rpz: applied [dbl-ads] . rpz-local-data . >>>>>>> DNSKEY >>>>>>> IN >>>>>>> unbound: info: failed to prime trust anchor -- could not >>>>>>> fetch >>>>>>> DNSKEY rrset . DNSKEY IN >>>>>>> >>>>>>> Result: All DNSSEC validation fails, rendering the resolver >>>>>>> unable >>>>>>> to >>>>>>> resolve any domain names and effectively breaking DNS >>>>>>> resolution >>>>>>> for >>>>>>> the entire network. >>>>>>> >>>>>>> The issue affects more users, as confirmed by Unbound >>>>>>> GitHub >>>>>>> Issue >>>>>>> #1404 (verified in Unbound 1.24.1/1.24.2) and potentially >>>>>>> also >>>>>>> #1152. >>>>>>> >>>>>>> Technical Cause: >>>>>>> >>>>>>> In Unbound's RPZ implementation (services/rpz.c), the >>>>>>> function >>>>>>> rpz_type_ignored() filters out DNSSEC-related records >>>>>>> (DNSKEY, >>>>>>> RRSIG, >>>>>>> NSEC, etc.) to prevent them from being treated as policy >>>>>>> rules. >>>>>>> ZONEMD >>>>>>> (RFC 8976, Type 63) is missing from this ignore list – this >>>>>>> is >>>>>>> IMHO >>>>>>> an >>>>>>> Unbound bug. >>>>>>> >>>>>>> Loading process: >>>>>>> >>>>>>> Unbound reads the apex ZONEMD record. >>>>>>> >>>>>>> rpz_type_ignored(63) returns 0 → record gets processed. >>>>>>> >>>>>>> strip_dname_origin() removes the zone name → empty label >>>>>>> (.). >>>>>>> >>>>>>> A rpz-local-data rule for . is created, blocking root >>>>>>> DNSKEY >>>>>>> priming queries. >>>>>>> >>>>>>> Note: A detailed analysis and proposed fix (add case >>>>>>> LDNS_RR_TYPE_ZONEMD: to rpz_type_ignored()) has been >>>>>>> submitted >>>>>>> to >>>>>>> Unbound Issue #1404. The root cause lies with Unbound. >>>>>>> >>>>>>> Reproduction Steps: >>>>>>> >>>>>>> Configure one IPFire DBL RPZ zone (e.g., >>>>>>> ads.rpz.ipfire.org) >>>>>>> following the instructions from >>>>>>> https://www.ipfire.org/dbl/how-to-use . >>>>>>> >>>>>>> Restart Unbound → zone gets cached (may still work >>>>>>> initially). >>>>>>> >>>>>>> Modify the configuration or add a second zone and >>>>>>> restart >>>>>>> Unbound >>>>>>> again → priming failure appears in logs. >>>>>>> >>>>>>> Tested with Unbound 1.24.1 on IPFire Core 199 and Unbound >>>>>>> 1.24.2 on >>>>>>> Rocky Linux 8.10 (on Unbounds Github). Single zone may load >>>>>>> initially, >>>>>>> but fails reliably with config changes or by adding >>>>>>> multiple >>>>>>> zones. >>>>>>> >>>>>>> Current temporary workaround: >>>>>>> >>>>>>> Remove ZONEMD records post-download via script (e.g., cron >>>>>>> job >>>>>>> after >>>>>>> AXFR): >>>>>>> >>>>>>> >>>>>>> sed -i '/IN[[:space:]]\+ZONEMD/d' >>>>>>> /var/lib/unbound/*.rpz.ipfire.org.zone >>>>>>> >>>>>>> Then reload Unbound. >>>>>>> >>>>>>> >>>>>>> While Unbound developers might likely investigate and may >>>>>>> fix >>>>>>> rpz_type_ignored() (Issue #1404), which way should IPFire >>>>>>> users >>>>>>> go >>>>>>> until then – since this blocks testing the Beta DBL usage >>>>>>> with >>>>>>> Unbound >>>>>>> (great project)? Haven´t tested a patched version of >>>>>>> Unbound >>>>>>> since >>>>>>> i >>>>>>> have currently no build environment around but if again, am >>>>>>> happy >>>>>>> to >>>>>>> test preview versions! >>>>>>> >>>>>>> May someone have similar problems or even another >>>>>>> workaround or >>>>>>> potential Fix for this ? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Erik >>>>>>> >>>>> >>>> >>> >
