Check for missing signature and unsuccessful verification for previously verified domains

I would like to propose the following enhancement. The new option could be called "Check for missing signature and unsuccessful verification for previously verified domains" or similar.

Background Information:

The majority of e-mails one receives these days do not apply a DKIM signature. Therefore, when receiving an e-mail without a DKIM signature, one does not know if it is a legitimate e-mail from a domain not using DKIM, or a spoofed one (spam, fishing, etc.). To be sure in authenticity of the received e-mail, one would need to look up an earlier e-mail from the same domain, to see whether it applies DKIM. And similarly with e-mains with not successfully verified From: domains (verified with warnings) - one would need to check if they have been correctly verified previously (in which case they may now be forged using an attackers signing domain, etc.).

Proposal:

It would be great if the DKIM Verifier add-on had an internal database of From: domains from which successfully verified e-mails have been received in the past. To be used as follows:

When an e-mail is (completely) successfully verified (no warnings), it's From: domain is added to the internal database.
From: domain of e-mails without a DKIM signature and of e-mails whose signature was not successfully verified (for whatever reason/warnings not resulting in a completely successful verification) are searched for in the database. And if found in the database, the user is notified using something like:
- For e-mails without a DKIM signature: "DKIM signature missing for previously verified domain"
- For not successfully verified e-mails: "DKIM verification failed for previously verified domain" (with respective warning triangle and tool tip showing the failure reasons)

The highlighting color could be the one of the "invalid signature", or a new dedicated one introduced (default: red).

This option would also require:

A button (in the add-on configuration options) to delete the entire database content.
An option (in the "Other Actions" drop-down menu where the "Re-verify DKIM Signature" already is): "Remove From domain from previously DKIM verified". This would be useful on rare occasions where a domain indeed abandons DKIM verification and would need to be removed from the database.

Hints for database files: On Firefox, the NoScript add-on uses a "NoScriptSTS.db" file (although ASCII), while the Certificate Patrol add-on uses a "CertPatrol.sqlite" file. Both in the profile directory.

What do you think of this?

Thoughts for future (out of scope of this enhancement proposal): One more option for future could be "public key pinning" (i.e. storage of the public key and the selector per From: domain). That would be for the paranoid assuming being under an active MITM attack, with the MITM sending an e-mail to the recipient and spoofing their DNS requests. (Like the "Certificate Patrol" add-on does on Firefox, except that they use "certificate pinning" instead of just "public key pinning".) One could then (additionally to key and selector) also store the signing domain. Which would be useful for From: domains which use a signing domain different from the From: domain, but which are nevertheless legitimate. If one "pins" their signing domain down, one can trust them too. (One would possibly also need to be able to define exceptions for certain From: domains, if they use several legitimate keys/selectors/signing domains and therefore cannot be "pinned" down to just one. Like Google does with its website certificates.)

First thanks for your suggestions. Bellow my thoughts about both of them:

I found a few weeks ago something that may be a better way to solve this problem. I haven't yet looked into it in detail, but DMARC seems to be a method for a domain to tell if it uses DKIM. The advantage over your proposal would be that it works also for domains from which one hasn't received e-mails yet. The disadvantage is that it only works if the domain uses DMARC.

The main reason (besides time) I haven't yet implemented it is, what at least the fishing e-mails I received so far are either using a domain that looks only similar to the original, or are even using a free e-mail provider. Both something there DMARC an you proposal doesn't help much against.

But I will try to implement your proposal or DMARC. Please say that you think of DMARC, and if you would rather see your proposal or DMARC implemented.

About your proposal against MITM attacks: I can try to add it. But the ideal way to to this would be to use DNSSEC. Sadly Thunderbird provides no way to use DNSSEC (or even DNS for records like TXT; if you are interested in this see also Bug 589538, Bug 735967). As an alternative one could try to use the DNSSEC Validator add-on or an OS or external library that supports DNSSEC via js-ctypes.

Although the theoretical advantage from DNSSEC would be very big, I doubt MITM against DKIM are currently actively used. So even if I also think it would be good idea to implement this, it has a rather low priority for me (but it is still on my TODO list).

Because I probably won't have much time the next weeks, if by any chance you know how to program and are interested to help, feel free to implement one of the above (or anything else) yourself.

Thank you very much for your feedback. I'm going to insert my response into yours.

I found a few weeks ago something that may be a better way to solve this problem. I haven't yet looked into it in detail, but DMARC seems to be a method for a domain to tell if it uses DKIM. The advantage over your proposal would be that it works also for domains from which one hasn't received e-mails yet. The disadvantage is that it only works if the domain uses DMARC.

I skimmed through the DMARC spec, and it seems that its main goal is:

Specifying what to do if the SPF or the DKIM verification fails ("policy": none (do nothing), quarantine (place into the spam folder), reject)
Specifying a report-back channel from receiver to the sender, for various reports (number of received e-mails which failed authentication, etc., for debugging and attack analysis by the sender)

Specifically, https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 chapter "3.2. Overview" says: "[...] A DMARC-enabled Domain Owner creates a DNS record to specify policy. Mail sent for such a domain may or may not also be authenticated with DKIM and/or SPF. [...]"

Chapter "4. Policy" says: " [...] A Mail Receiver MUST consider an arriving message to pass the DMARC test if and only if one or more of the underlying message authentication mechanisms pass with proper identifier alignment. DMARC considers only success; failure and nonexistence of authentication mechanisms are equivalent. A Domain Owner that does not advertise an SPF policy or sign with DKIM is making an implicit statement that the use cases those protocols satisfy are not to be considered when determining whether the message under evaluation is valid. [...]"

==> In other words, a published DMARC DNS record with absent DKIM record is correct according to the spec, as long as an SPF record is published. (Because only one is required - either DKIM or SPF.)

I.e.: a) One cannot use DMARC record presence to determine if the domain supports DKIM, if it also supports SPF.

b) Also, as you noted, there are domains which support DKIM, but not DMARC. E.g., I went through the e-mails I received this year which have a DKIM signature, and using http://otalliance.org/resources/authentication/spflookup.html saw that only 5 of 13 such domains also support DMARC. (Although those 5 include facebookmail.com (FB updates) and gmail.com, from which two alone I received more e-mails than from other eleven combined.)

==> That disqualifies usage of DMARC for determination of DKIM support for domains supporting SPF. Rather, it seems to me, DMARC is mainly designed to work between large e-mail providers/senders (Gmail, Facebook, Paypal, etc.), as a way for them:

To communicate to each other what to do (policy: nothing/move to spam/reject) with the masses of spoofed e-mails they receive each day which purport to come from domains of other large providers.
To report back to their large brethren as to how much their domain is used in spoofed e-mails. And thus to support their DMAC debugging (policy adjustment, need for SPF/DKIM, etc.)

The main reason (besides time) I haven't yet implemented it is, what at least the fishing e-mails I received so far are either using a domain that looks only similar to the original, or are even using a free e-mail provider. Both something there DMARC an you proposal doesn't help much against.

Same with me. But that maybe because I'm on one of the large e-mail providers, which already does some filtering Voodoo (maybe SPF based? definitely not DKIM) and then places an "X-UI-Filterresults" header into the e-mail. People using their own e-mail servers might be affected more. Just a guess.

But I will try to implement your proposal or DMARC. Please say that you think of DMARC, and if you would rather see your proposal or DMARC implemented.

Definitely my proposal.

One could, of course, additionally implement DMARC (to respect sender policies, reporting back to the sender, etc.). But that would have nothing to do with the security enhancements proposed here. One could also let the user configure local policies (instead or additionally to the ones provided via DMARC by the sender): do nothing / move to spam / delete on DKIM verification failures. But this is also not what this enhancement proposal is about. And I personally have no plans to propose these policies. :)

As far as I can see, the only additional value of DMARC related to this proposal would be in:

Its "adkim" tag (see chapter "5.2. General Record Format" of its spec). Which indicates if the From domain and the signing domain ("d=") must match exactly ("strict" mode), or if one of them can be a sub-domain of the other ("relaxed" mode). So, the "adkim" tag would be useful for e-mails received with a DKIM signature where one of those two domains is a sub-domain of the other. But with all the 5 domains I noted above which use DMARC additionally to DKIM, both domains match exactly. So that there would be no DKIM warning anyway. Making this low priority, I guess.
Detection of DKIM support with domains which don't supporting SPF, for e-mails received without a DKIM signature. (I.e. one would first need to check for existence of the SPF record. And only if absent check for existence of DMARC record, whose presence would then indicate support of DKIM.) But with the 5 domains I noted above which use DMARC additionally to DKIM that would apply to only one. Making this low priority too.

About your proposal against MITM attacks: I can try to add it. But the ideal way to to this would be to use DNSSEC. Sadly Thunderbird provides no way to use DNSSEC (or even DNS for records like TXT; if you are interested in this see also Bug 589538, Bug 735967). As an alternative one could try to use the DNSSEC Validator add-on or an OS or external library that supports DNSSEC via js-ctypes.

I might be wrong here (I'm by no means an expert, just a hobbyist), but it looks to me like DNSSEC would have following disadvantages:

It won't solve the MITM issue here, with the MITM sitting between the user and their DNS resolver. It would only transfer the need for pinning from the From domain to the DNS resolver IP. I.e., instead of pinning the public key of the From domain, one would need to pin the one of the DNS resolver (and I'm not even sure they use one, i.e. it looks like the DNS requests/responses with DNSSEC are not encrypted). Which means that the DNS requests can still be MITMed - the user won't know if they are actually using 8.8.8.8 or not. It looks to me like the purpose of DNSSEC is not prevention of targeted MITM attacks, but of global (or at least area-wide) DNS poisoning. Note: The connection to the user's e-mail servers can still be secured though, as their certs can be pinned as described here: http://forums.mozillazine.org/viewtopic.php?f=39&t=2687657. So, if the MITM provides either wrong IP address or wrong content, it will be detected. Because, not knowing the private key of the real server to decrypt its communications and impersonate it, they would have to use another private/public key pair. So, the cert/key pinning also solves the DNS poisoning issue. (Although not for "non-technical" people, as they won't know what to do with cert/key warnings on personally critical connections (banks, etc.). Such as using manual means for cert/key verification, e.g. https://www.ssllabs.com/ssltest/index.html, https://www.sslshopper.com/ssl-checker.html (also for IMAP/POP3/SMTP, though fewer details), or others. While pinning those verification site's certs using "Certificate Patrol" on Firefox. And similarly with online DKIM checkers over HTTPS, such as https://www.protodave.com/tools/dkim-key-checker/ - it uses a self-signed cert, but that does not matter if one uses cert pinning.)
Because most DNS resolvers don't (yet) support DNSSEC, one will not be able to use the default resolvers of the connection, but will be stuck with GoogleDNS. And I don't trust Google with my privacy. Traveling a lot, I prefer spreading my DNS requests over a wide geographic area (among other privacy protections). :) And when at home (whichever country that is), I'd rather rely on my local jurisdiction, where I'm not a foreigner and therefore have a higher privacy protection. Besides: the local ISP would see all requests to GoogleDNS anyway, so why not just use its local resolver? (Except in oppressive countries with simple DNS filtering, to bypass the filtering.)
js-ctypes scares me a bit for security reasons. I'm not an expert, but giving a JavaScript add-on, which has access to the Internet, an ability to run native code sounds like opening an additional exploitation possibility.

Although the theoretical advantage from DNSSEC would be very big, Idoubt MITM against DKIM are currently actively used. So even if I also think it would be good idea to implement this, it has a rather low priority for me (but it is still on my TODO list).

I completely agree that this is low priority. (To DNSSEC: As I wrote above, it seems to protect against DNS poisoning, not MITM attacks. It's still useful, of course, for less "technical" users who can't use pinning, but with privacy implications until all DNS resolvers on the planet start supporting it, which may take a while. I personally can live without it - the pinning seems to be more secure.)

Because I probably won't have much time the next weeks, if by any chance you know how to program and are interested to help, feel free to implement one of the above (or anything else) yourself.

Unfortunately, I know nothing about JavaScript. (Only some C and VB.) But I'm very much interested in helping out in testing. I'll see if I lay my hands on JS and Thunderbird some time in the future.

Sorry, this post became a bit long. :)

Thanks for your detailed response.

About DMARC: I was aware that it's main purpose was not to tell if a domain uses DKIM. But I thought part of it was to explicit say if they are using DKIM or not, so that I can misuse it for our purpose. Seems I was wrong on that, thanks for clarifying that. I agree with you that in this case DMARC doesn't make much sense for your proposal.

1) You are right, DNSSEC does not encrypt the responses. But confidentiality (that's that encryption is for) is not that we want, it's integrity. And as far as I understand it, that's exactly what DNSSEC provides, in a similar recursive way as certificates (by a chain of trust). You still have to save public keys, but only some as trust anchors (or only one as a root trust anchor). This makes it a lot easier for (especially "non-technical") people, because they don't have to decide if a changed (or new) key is trustworthy or not. They just have to trust the root trust anchor. Buy the way, if I understand it correctly, DNS poisoning is also an MITM attack, only against the DNS server, and not against the DNS client.

2) You are probably right that many DNS Servers don't yet support DNSSEC, but that hopefully will change.

3) The security risk is if arguments that come from outside sources (like the internet or even user inputs) aren't checked to be valid inputs. But because unlike C JavaScript checks things like array boundary's, the risk for something like this should be much lower (at least if you don't use something like eval(...) on external input). Of course this wouldn't apply to a library which is written in C. But if you use a widely used DNS library, it should be resistant against attacks like this.

Unfortunately, I know nothing about JavaScript. (Only some C and VB.) But I'm very much interested in helping out in testing. I'll see if I lay my hands on JS and Thunderbird some time in the future.

Feedback and testing already helps a lot, so don't worry about it.

DKIM, DMARC and DNSSEC are promising technologies that attempt to address different facets of the INTERNET authentication conundrum. For email, DKIM offers a less robust authentication but with significantly lower resource requirements than public key based message content signatures (e.g. PGP, X.509 certificate infrastructure, etc). DKIM can be easily and quickly applied by mass mailings originators or by INTERNET service providers for "trusted" customers. DMARC allows DKIM originators the ability to receive some feedback when DKIM signed messages fail client / intermediate processor validation. Until there RFC 6377 best practices are adopted by the major INTERNET service providers, DKIM and DMARC will be minimally effective authentication improvements. (www.ietf.org/rfc/rfc6377.txt)

DNSSEC has promise to harden DNS attack vectors. However, DNSSEC is conceptually simple and elegant but its implementation is complex and its maintenance is never ending. I found "DNSViz" from Sandia Labs to be most helpful in understanding the implementation complexity of large organizations and the headaches of maintaining validation chains. The tool's address is: http://dnsviz.net/ A good example of a complex structure is: www.dod.mil

I applaud the author of DKIM Verifier for providing a tool that has great potential. Thank you for your willingness to incorporate the suggestions of the user community.

1) You are right, DNSSEC does not encrypt the responses. But confidentiality (that's that encryption is for) is not that we want, it's integrity. And as far as I understand it, that's exactly what DNSSEC provides, in a similar recursive way as certificates (by a chain of trust). You still have to save public keys, but only some as trust anchors (or only one as a root trust anchor). This makes it a lot easier for (especially "non-technical") people, because they don't have to decide if a changed (or new) key is trustworthy or not. They just have to trust the root trust anchor. Buy the way, if I understand it correctly, DNS poisoning is also an MITM attack, only against the DNS server, and not against the DNS client.

Just to contribute to the discussion: I agree with all of that. Thank you for explanation, I wasn't aware that DNSSEC can provide communication integrity between the user's PC and its DNS resolver. I thought it was only for between the (first from user's prospective) resolver and its resolvers/servers. (Although Windows until including 7 and Server 2008 R2 can't do it yet - see http://technet.microsoft.com/en-us/library/ee649277%28WS.10%29.aspx, where it says that "the DNS client is non-validating, which means it does not perform DNSSEC validation; it relies on its local DNS servers for validation instead" and "... the client must be able to trust the local DNS server". As well as its communication channel to it, apparently.)

As you wrote, hopefully that will change. DNSSEC is an improvement in any case. Even if user's PC doesn't support it. And even more so if it does. Although (as in case with SSL/TLS) key pinning would provide additional authentication security (even if PC supports DNSSEC) for paranoid "technical" bunch, because, as it seems to me, the DNSSEC channel would be vulnerable to the same cert/key replacement MITM attacks as SSL/TLS. Anyway, this is out of scope of this proposal. :)

I applaud the author of DKIM Verifier for providing a tool that has great potential. Thank you for your willingness to incorporate the suggestions of the user community.

I second that. Thank you!

I am currently working on this, an included a default list of signers. It would help a lot if you could collect the e-mail addresses and the signing domains from big companies/organizations from which you received DKIM signed e-mails. Especially look out for domains like github.com, who are sending signed and not signed e-mails from the same address. If your list contains more than a few entry's, best send it via e-mail to dkim.verifier.addon@gmail.com. Thanks

If you want to see what I already did, its in the dev branch, not the master. But I would not recommend to use it already.

Note: I opened separated issues for public key pinning an DNSSEC

Thanks! I've sent you a list of e-mail domains to the above e-mail address.

It is not completely finished yet, but it should work now. If you want to test it, here's a small explanation of the rules:

addr: this will be compared to the From address. "*" matches any sequence of zero or more characters
sdid: the signer
ruletype: 1: e-mail should be signed; 2: doesn't matter if e-mail is signed or not
priority: if more then one rule matches the From address, the one with the highest priority is used
enabled: 0: false; 1: true

This should now be completed. A detailed description can be found in the wiki.

This will be added in version 1.0.0. A prerelease can be downloaded from https://github.com/lieser/dkim_verifier/releases. Would be nice if you could test it. If you encounter any problems, or need additional features related to this, please reopen the issue. Thanks.

Thanks very much for introducing this. I'm sorry for the late reply, I was away for a while. Here is some feedback (dkim_verifier-1.0.0pre1.xpi with TB (Icedove) 17.0.8 on Debian):

I) There seems to be an issue with domains not using DKIM on all From addresses. Specifically with the "gmxnet.de" domain which is present in the "default" list.

The issue is that when "Use default rules" (or "Check if e-mail should be signed", which grays it out) is NOT active, the "From does not match user identifier" is shown (orange highlighting).

Note: The issue also disappears (i.e. the domain validates green) if "Automatically add rules..." gets activated.

TEST PROCEDURE:

Activate "Check if e-mail should be signed" and "Use default rules". Deactivate "Automatically add rules..." and "Treat wrong SSID as warning...".
Do the "Reverify DKIM signature".
Deactivate "Check if e-mail should be signed" or "Use default rules".
Do the "Reverify DKIM signature".

EXPECTED RESULTS:

Signature verifies green.
Signature verifies green.

ACTUAL RESULTS:

Signature verifies orange. "From does not match user identifier" is shown in the tool tip.

Example e-mail: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmxnet.de; s=global1; t=[removed]; i=[removed]@gmxnet.de; bh=[removed]; h=Date:From:To:Message-ID:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=[removed]

Debug output with "Check if e-mail should be signed" active (works correctly) - latest output first:

2013-11-12 03:29:13 DKIM_Verifier.Verifier DEBUG Header hash input: date:Mon, 21 Oct 2013 14:13:14 +0200 (CEST) from:[removed]@gmxnet.de to:[removed] message-id:[removed].JavaMail.jboss@ccsystool02.schlund.de subject:Ihre E-Mail an GMX mime-version:1.0 content-type:text/plain; charset=UTF-8 content-transfer-encoding:quoted-printable dkim-signature:v=1; a=rsa-sha256; c=relaxed/simple; d=gmxnet.de; s=global1; t=[removed]; i=[removed]@gmxnet.de; bh=[removed]; h=Date:From:To:Message-ID:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=

2013-11-12 03:29:13 DKIM_Verifier.Verifier DEBUG Parsed DKIM-Key: ({v:"DKIM1", h:null, h_array:null, k:"rsa", n:null, p:"[removed]", s:"*", t:"", t_array:[]})

2013-11-12 03:29:13 DKIM_Verifier.JSDNS DEBUG global1._domainkey.gmxnet.de/TXT: Answer: v=DKIM1; p=[removed]

2013-11-12 03:29:11 DKIM_Verifier.JSDNS INFO Resolving global1._domainkey.gmxnet.de TXT by querying [removed]

2013-11-12 03:29:11 DKIM_Verifier.Verifier DEBUG computed body hash: [removed]

2013-11-12 03:29:11 DKIM_Verifier.Verifier DEBUG Parsed DKIM-Signature: ({v:"1", a_sig:"rsa", a_hash:"sha256", b:"[removed]", b_folded:"[removed]", bh:"[removed]", c_header:"relaxed", c_body:"simple", d:"gmxnet.de", h:"Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding", h_array:["date", "from", "to", "message-id", "subject", "mime-version", "content-type", "content-transfer-encoding"], i:"[removed]@gmxnet.de", i_domain:"gmxnet.de", l:null, q:"dns/txt", s:"global1", t:[removed], x:null, z:null})

2013-11-12 03:29:11 DKIM_Verifier.Policy DEBUG shouldBeSigned: true; sdid: gmxnet.de; hideFail: false; foundRule: true

Debug output with "Check if e-mail should be signed" NOT active (issue occurs) - latest output first:

2013-11-12 03:38:30 DKIM_Verifier.Verifier DEBUG Header hash input: date:Mon, 21 Oct 2013 14:13:14 +0200 (CEST) from:[removed]@gmxnet.de to:[removed] message-id:[removed].JavaMail.jboss@ccsystool02.schlund.de subject:Ihre E-Mail an GMX mime-version:1.0 content-type:text/plain; charset=UTF-8 content-transfer-encoding:quoted-printable dkim-signature:v=1; a=rsa-sha256; c=relaxed/simple; d=gmxnet.de; s=global1; t=[removed]; i=[removed]@gmxnet.de; bh=[removed]; h=Date:From:To:Message-ID:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=

2013-11-12 03:38:30 DKIM_Verifier.Verifier DEBUG Parsed DKIM-Key: ({v:"DKIM1", h:null, h_array:null, k:"rsa", n:null, p:"[removed]", s:"*", t:"", t_array:[]})

2013-11-12 03:38:30 DKIM_Verifier.JSDNS DEBUG global1._domainkey.gmxnet.de/TXT: Answer: v=DKIM1; p=[removed]

2013-11-12 03:38:29 DKIM_Verifier.JSDNS INFO Resolving global1._domainkey.gmxnet.de TXT by querying [removed]

2013-11-12 03:38:29 DKIM_Verifier.Verifier DEBUG computed body hash: [removed]

2013-11-12 03:38:29 DKIM_Verifier.Verifier DEBUG Warning: DKIM_SIGWARNING_FROM_NOT_IN_AUID (From does not match User Identifier)

2013-11-12 03:38:29 DKIM_Verifier.Verifier DEBUG Parsed DKIM-Signature: ({v:"1", a_sig:"rsa", a_hash:"sha256", b:"[removed]", b_folded:"[removed]", bh:"[removed]", c_header:"relaxed", c_body:"simple", d:"gmxnet.de", h:"Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding", h_array:["date", "from", "to", "message-id", "subject", "mime-version", "content-type", "content-transfer-encoding"], i:"[removed]@gmxnet.de", i_domain:"gmxnet.de", l:null, q:"dns/txt", s:"global1", t:[removed], x:null, z:null})

II) I don't know if this is a side effect of the above issue (I) or a separate issue, but after playing around a bit with "Use default rules" inactive and "Automatically add rules..." active (which made the above issue (I) disappear first, as I wrote in the "Note" to it) and collecting a bunch of domains/addresses in the "Signers rules", I came back and re-evaluated the above "gmxnet.de" e-mails and saw the following issue:

a) The issue (I) is back (i.e. "Automatically add rules..." no longer prevents it). (Well, this is just a note here, not a separate issue.)

b) The "From" column in the "Signers rules" of the gmxnet.de domain contains the "From:" string and quotation marks. E.g. for the above [removed]@gmxnet.de it contains following (including quotation marks): "From: [removed]"@gmxnet.de instead of just [removed]@gmxnet.de.

And the same line gets added each time the same e-mail is re-evaluated. So, that there are many identical lines containing the above "From:" string and quotation marks for the same address. (I guess because the "From:" together with quotation marks result in different string, so that the add-on doesn't find [removed]@gmx.de and tries to add it (again).) As can be seen in the following image:

point_ii

Note: I don't know if it had an affect, but I had kept the "Signers rules" window open for a while, while testing and "collecting" domains/addresses. (And saw, e.g., that it's window content not always updates while the window is open: e.g. another valid address from a domain (e.g. gmail.com) replaces a previously existing line of the same domain, instead of appearing on a new additional line. Only after closing and re-opening the window do both lines appear. And then I started noticing the issue (II), also with the "Signers rules" window closed. It might be related. Even if the missing "window update" itself is probably not an issue.)

III) On some old e-mails I get an "Internal error", presumably due to their selector (i.e. key domain) no longer existing. The debug then shows following (latest output first):

Timestamp: 11/12/2013 05:02:14 AM Error: 2013-11-12 05:02:14 DKIM_Verifier.Verifier FATAL result.data is null JS Stack trace: @dkimKey.jsm:238 < effort@core.js:53 < resolveDeferred@core.js:125 < then@core.js:34 < resolve@core.js:167 < dnsCallback@DNSWrapper.jsm:131 < DNS_getRDData@JSDNS.jsm:849 < @JSDNS.jsm:643 < @JSDNS.jsm:924

Source File: resource://dkim_verifier/mozilla/log4moz.js Line: 410

2013-11-12 05:02:14 DKIM_Verifier.JSDNS DEBUG gamma._domainkey.gmail.com/TXT: No answer, no authority to recurse on. DNS lookup failed.

2013-11-12 05:02:09 DKIM_Verifier.JSDNS INFO Resolving gamma._domainkey.gmail.com TXT by querying [removed]

2013-11-12 05:02:09 DKIM_Verifier.Verifier DEBUG computed body hash: [removed]

2013-11-12 05:02:05 DKIM_Verifier.Verifier DEBUG Parsed DKIM-Signature: ({v:"1", a_sig:"rsa", a_hash:"sha256", b:"[removed]", b_folded:"[removed]", bh:"[removed]", c_header:"relaxed", c_body:"relaxed", d:"gmail.com", h:"domainkey-signature:received:received:reply-to:from:to:subject:date:mime-version:content-type:x-mailer:thread-index:x-mimeole:message-id", h_array:["domainkey-signature", "received", "received", "reply-to", "from", "to", "subject", "date", "mime-version", "content-type", "x-mailer", "thread-index", "x-mimeole", "message-id"], i:"@gmail.com", i_domain:"gmail.com", l:null, q:"dns/txt", s:"gamma", t:null, x:null, z:null})

2013-11-12 05:02:05 DKIM_Verifier.Policy DEBUG shouldBeSigned: false; sdid: undefined; hideFail: undefined; foundRule: false

Question: Would it be possible to have a more meaningful info than the "Internal error" in such a case? So that one doesn't need to check the debugging output to see what's happening. (I guess the "Internal error" stands for all those not explicitly handled.)

E.g., on a connection issue (e.g. with missing internet connection), clear info (e.g. "Error connecting to DNS server" or other) is already shown.

Thank you!

P.S.: I'll have some feedback on enhancement request #18 soon, too.

P.P.S.: I can't reopen this issue - apparenly only the project owner can. :)

I think I) and II) are the same problem: the From header is not correctly parsed. Could you please post the From header from then message source?

I found the problem for III) and fixed it.

edit: About the replacing of lines in the "Signers rules" window: currently, the number of rows is only updated if a rule is deleted or added through the "Signers rules" window. I will try to find a way that the row count is also updated if an rule is added by the auto add rule option.

And thanks for the detailed feedback.

I) and II) should now also be fixed

I think I) and II) are the same problem: the From header is not correctly parsed. Could you please post the From header from then message source?

Sure:

From: [removed]@gmxnet.de

Etc.. I.e., all of @gmxnet.de except [removed]@gmxnet.de. Please note that there is an exception for the latter in the "Default signers rules" list.

I) and II) should now also be fixed

Thanks! I'll check it and report back.

P.S.:

About the replacing of lines in the "Signers rules" window: currently, the number of rows is only updated if a rule is deleted or added through the "Signers rules" window. I will try to find a way that the row count is also updated if an rule is added by the auto add rule option.

I wouldn't worry about that unless there is a quick and easy solution. Because it's not a normal use case that one has the "Signers rules" open while checking e-mails. One can be expected to close and re-open the window to see the number of rows updated. I just kept the window open for testing. And mentioned it just because I thought it might be the root cause (or one of the root causes) of issue (II).

Issues I) to III) are fixed, thanks!

Just one more small thing:

IV) There is a typo in the SDID cell of the googlemail.com domain in "Default signers rules". It has a double "m" at the end ("googlemail.comm"). (Which currently causes the "Wrong signer..." error on that domain - its great to see that that detection works, too.)

Let me say how impressed I am with this new functionality - I think it's absolutely super-duper great! :) Just "black-box" testing this, I see that you considered many details implementing it.

Feel free to close this enhancement request, as far as I am concerned. I'm going to remove the e-mail addresses in my previous posts here, to prevent them being spammed.

lieser / dkim_verifier

Check for missing signature and unsuccessful verification for previously verified domains #15

Background Information:

Proposal: