https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7310
Bug ID: 7310
Summary: suggested rule: DomainKey-Signature with invalid DNS
Product: Spamassassin
Version: 3.4.1
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Rules
Assignee: [email protected]
Reporter: [email protected]
The predominance of spam I receive that is not otherwise detected or filtered
has the same pattern - it includes a DomainKey-Signature header (which is
considered obsolete I know, nonetheless it remains present) yet the selector
(s=foo) and domain (d=foo) portion of the header are fictitious.
As an example:
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=gamma; d=countingbooks.com;
h=To:Date:Message-ID:From:Subject:Date:MIME-Version:Content-type;
by DomainKey rules, our filter should look up
gamma._domainkey.countingbooks.com TXT record in DNS to find the public key
corresponding to the signer of this message. However, this does not exist.
This is akin to the __DKIM_EXISTS rule testing for the existence of the header,
and the DKIM_ADSP_NXDOMAIN rule that looks up a DKIM ADSP record in DNS, but in
this case we're merely looking up the public key record.
The opendkim milter (http://opendkim.org) has a specific test and configuration
option for how to handle such DNS lookup failures on a DKIM-Signature header,
but does not do likewise for (obsolete) DomainKey-Signature headers.
The perl(Mail::DKIM) module already used by SpamAssassin to handle the
DKIM-Signature header can also handle the DomainKey-Signature header, and the
SpamAssassin Plugin DKIM.pm indicates it will also check the
DomainKey-Signature heder, but does not seem to do so.
I have so far found only a single false positive on this test - that on mail
from the Boy Scouts of America <[email protected]> where they included
a DomainKey-Signature header with incorrect d= value, yet included a correct
DKIM-Signature header with the correct d=value.
--
You are receiving this mail because:
You are the assignee for the bug.
