Bug 7777 - askdns problem with multi-valued resource records
Summary: askdns problem with multi-valued resource records
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.4.2
Hardware: All Linux
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-11 15:22 UTC by Michael Storz
Modified: 2019-12-12 10:22 UTC (History)
3 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Storz 2019-12-11 15:22:32 UTC
askdns only works on the first resource record it receives even if it is a multi-value RR.

Example:

dig +short txt lrz.de
"google-site-verification=aery99S4-qQNyQyHH2_P3UlwnXrfYgKa-BHwwKDRY1w"
"v=spf1 redirect=_spf.mail.lrz.de"

echo 'From: test@lrz.de'|spamassassin -D all  --cf 'askdns LRZ_ASKDNS _AUTHORDOMAIN_ TXT /.+/' 2>&1|grep LRZ_ASKDNS|grep listed
Dec 11 16:13:49.624 [109500] dbg: askdns: domain "lrz.de" listed (LRZ_ASKDNS): google-site-verification=aery99S4-qQNyQyHH2_P3UlwnXrfYgKa-BHwwKDRY1w

or

echo 'From: test@lrz.de'|spamassassin -D all  --cf 'askdns LRZ_ASKDNS _AUTHORDOMAIN_ TXT /.+/' 2>&1|grep LRZ_ASKDNS|grep listed
Dec 11 16:14:05.619 [109689] dbg: askdns: domain "lrz.de" listed (LRZ_ASKDNS): v=spf1 redirect=_spf.mail.lrz.de

It never checks both records.

Deleting the line 

$pms->{askdns_map_dnskey_to_rules}{$dnskey}[$j++] = undef;

solves the problem for me:

echo 'From: test@lrz.de'|spamassassin -D all  --cf 'askdns LRZ_ASKDNS _AUTHORDOMAIN_ TXT /.+/' 2>&1|grep LRZ_ASKDNS|grep listed
Dec 11 16:19:42.411 [111140] dbg: askdns: domain "lrz.de" listed (LRZ_ASKDNS): v=spf1 redirect=_spf.mail.lrz.de
Dec 11 16:19:42.411 [111140] dbg: askdns: domain "lrz.de" listed (LRZ_ASKDNS): google-site-verification=aery99S4-qQNyQyHH2_P3UlwnXrfYgKa-BHwwKDRY1w
Comment 1 Henrik Krohns 2019-12-11 18:24:49 UTC
It works correctly in 4.0/trunk, since askdns code was rewritten.

I have no idea if the suggested line removal would break other things in 3.4, and it's too late for 3.4.3 anyway. But I'll leave this open if someone wants to verify mentioned change works properly..
Comment 2 Michael Storz 2019-12-12 09:41:37 UTC
Yeah, the deleted line looks really suspicious. That's the reason I did not report the error immediately when I discovered the bug. For me it looks like a left over  optimization after a rewrite of the code. I had the hope that someone could find the meaning of the line in the history of the plugin.

I'm running the patched version on a cluster of servers since September last year filtering at least 200.000 emails a day in pre-queue-mode without any problems. That's the reason, I wrote it is working for me.

I'm using askdns for a bunch of rules querying SPF, DMARC, MX and NS records to build anti-spam-signatures. Some spammers did not realize that they can be tracked via these records.
Comment 3 Henrik Krohns 2019-12-12 10:13:53 UTC
Should have reported it sooner to have a chance for 3.4.3. :-) But unless there are any serious bugs, I doubt 3.4.4 will be released. And since this "limitation" has been all the way from atleast 3.4.0, we can probably just think it as more of a feature..
Comment 4 Kevin A. McGrail 2019-12-12 10:22:20 UTC
I didn't even put in a milestone for 3.4.4.  Recommend you try out trunk or use your own patched version.