|Summary:||suggested rule: DomainKey-Signature with invalid DNS|
|Product:||Spamassassin||Reporter:||Matt Domsch <matt>|
|Component:||Rules||Assignee:||SpamAssassin Developer Mailing List <dev>|
|Attachments:||domainkey-signature header spam mbox|
Description Matt Domsch 2016-04-13 21:36:16 UTC
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@example.com> where they included a DomainKey-Signature header with incorrect d= value, yet included a correct DKIM-Signature header with the correct d=value.