Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent result for emails from github #166

Closed
mortenn opened this issue Sep 5, 2019 · 8 comments
Closed

Inconsistent result for emails from github #166

mortenn opened this issue Sep 5, 2019 · 8 comments
Assignees
Labels

Comments

@mortenn
Copy link

mortenn commented Sep 5, 2019

Hello, I have 5 emails from github in a folder, two of them are from this project :)

But only one of them show a DKIM indicator with the github icon.
The rest show nothing.

This is the signature of the one that shows the favicon:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; 
	h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; 
	s=s20150108; bh=uKHLp0ecywVa9Sz0faO984WMheg=; b=a+R0ASbjKwNBEtnp
	vQQxrtx1bHhl1IP0rrTNSrAXWEyIrQsZ4IWr2gcpeufiJuN32x/auAZMkQQS93u7
	uEp2O37Ipo6VlkEMsbUuuoQtx1RPI5BxSW4HM7/JHF6U85Y8sAMYwbJtA+yCx+Qj
	uXBxbLfMPiDryppme0/ybtIz16I=

And here is one of the ones that show no icon:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
	s=pf2014; t=1567109831;
	bh=UkdeQ9fm+Sb6Y/bw2SN74siGyIPvk4d8gSolYg2du4A=;
	h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
	 List-Archive:List-Post:List-Unsubscribe:From;
	b=Dh6/dn9EbvMLV9jo3Ew6X7YO959yKgAgICtF8d82E6GRMUBCzE8SboK6j0XhtEHvj
	 GqXRvoCFxk6veYVbAMWC2ZV0uhOdbiN9mkAGkH23CIluL7nrVi/U/QFBOx8aa2Up4i
	 QRlsSjeO7PNaNpucnliKI5GwsBDWjZigc5uYQYqE=
@mortenn
Copy link
Author

mortenn commented Sep 5, 2019

I am guessing this is probably due to issue #142

@lieser
Copy link
Owner

lieser commented Sep 5, 2019

The problem is the key used for the second signature (pf2014._domainkey.github.com). It contains, t=y;, meaning the domain is only testing DKIM. It is wherefore treated as it is not singed at all.

This can be changed by the advanced option Still verify the signature, if a domain is only testing DKIM.

Note that multiple outgoing e-mail servers of GitHub do have this problem. I already tried to report it over two years ago, but did not get any meaningful response (only that they will internally forward the info). But feal free to report it again to them, maybe you will have more luck.

@lieser lieser self-assigned this Sep 5, 2019
@lieser lieser added the question label Sep 5, 2019
@lieser
Copy link
Owner

lieser commented Sep 5, 2019

Additional note: besides looking directly at the key, one can identify this issue by looking at the log and finding a similar log entry like below (DKIM_SIGERROR_KEY_TESTMODE):

9/5/2019, 19:01:34	DKIM_Verifier.Verifier	WARN	DKIM Signature Error (DKIM_SIGERROR_KEY_TESTMODE): The signing domain is only testing DKIM (resource://dkim_verifier/helper.jsm:407:3) JS Stack trace: [email protected]:1181:11

@ale5000-git
Copy link

@lieser: I just wonder, due to the unfortunate common use t=y if it was possible to enable this setting by default.

@lieser
Copy link
Owner

lieser commented Sep 12, 2019

No, I will not enable the verification of DKIM using testmode by default.

If a domain is using the test mode, there are only two possible reason I can see:

  • they are currently correctly using this feature for testing. This should only be temporary. And if they mess something up during testing, the user of the add-on will not bothered by any errors, like I believe intended by the RFC.
  • they messed up the configuration, and don't really intend to use the testing mode. This should be fixed as fast as possible on the server side

So I see little value for enabling this for the average user (advanced users should not have any problems enabling this via settings). And I believe letting senders get away with the second case (miss configuration of DKIM) is in the long run bad for the DKIM ecosystem, as it reduces the pressure to actually fix the issue. See also The Harmful Consequences of the Robustness Principle if you are interested in this topic.

@lieser
Copy link
Owner

lieser commented Oct 7, 2019

As I think all questions are answered, I will close this. If not, feel free to reopen this.

@lieser lieser closed this as completed Oct 7, 2019
@mortenn
Copy link
Author

mortenn commented Oct 14, 2019

I reported this to github, and eventually got a response:
I'm sorry for the delay in our reply. Approximately 7 days ago we released an update that fixed a DKIM issue with emails coming from GitHub. I'm wondering if you're still seeing inconsistencies in emails received in the last few days?

I checked just now, and all emails from github had the icon present (but not that support mail, as that was a different domain)

@lieser
Copy link
Owner

lieser commented Oct 15, 2019

To me this does not seem to be resolved by GitHub. E.g. the e-mail I got for your comment still uses the pf2014._domainkey.github.com DKIM key, which still contains the testing tag.
Same for the e-mail for your comment today on the other issue.

Note that if you have enabled in the advanced options the verification of such DKIM signatures, the favicon icon will still be shown. You will only get a warning for it.

They are probably referring to a different problem they had. E.g. for some time now a lot of the notification e-mails I received from GitHub there not signed with DKIM at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants