summaryrefslogtreecommitdiff
path: root/content/entry/re-dkim-show-your-privates.md
diff options
context:
space:
mode:
authorNicholas Johnson <mail@nicholasjohnson.ch>2025-02-05 00:00:00 +0000
committerNicholas Johnson <mail@nicholasjohnson.ch>2025-02-05 00:00:00 +0000
commit1026603aae0cbf763fa1dcd204230329f0386ae1cea85d7cd2758ed3222f581b (patch)
tree9c42bbecef1b2aec4db5d5fae512a1773b3fb002a6c0c195d2f6ac7043b34dfe /content/entry/re-dkim-show-your-privates.md
parent7cef74ed8db2b0b6b799b3b0e3a9211e521bd7bd4313e8b9f7b7fcf7ed4cb997 (diff)
downloadjournal-1026603aae0cbf763fa1dcd204230329f0386ae1cea85d7cd2758ed3222f581b.tar.gz
journal-1026603aae0cbf763fa1dcd204230329f0386ae1cea85d7cd2758ed3222f581b.zip
Replace instances of 'anyways' with 'anyway'
'anyway' is the correct spelling.
Diffstat (limited to 'content/entry/re-dkim-show-your-privates.md')
-rw-r--r--content/entry/re-dkim-show-your-privates.md4
1 files changed, 2 insertions, 2 deletions
diff --git a/content/entry/re-dkim-show-your-privates.md b/content/entry/re-dkim-show-your-privates.md
index 36a9e6a..a3144ff 100644
--- a/content/entry/re-dkim-show-your-privates.md
+++ b/content/entry/re-dkim-show-your-privates.md
@@ -18,11 +18,11 @@ The Session team's blog post, "[Session Protocol: Technical implementation detai
>
> Instead of designing a cryptographic protection, Session will add the ability to edit other users’ messages locally, thus providing a way to completely forge conversations. Since signatures are deleted after messages are received, there will be no way to prove whether a screenshot of a conversation is real or edited, diminishing the value of screenshots as evidence."
-Programmers could still change the Session source code to save the message signatures anyways, but I highly doubt anyone is doing this. By contrast, email servers *do* retain email signatures even after emails are already validated. So there's more of a concern for email being cryptographically undeniable than Session Private Messenger.
+Programmers could still change the Session source code to save the message signatures anyway, but I highly doubt anyone is doing this. By contrast, email servers *do* retain email signatures even after emails are already validated. So there's more of a concern for email being cryptographically undeniable than Session Private Messenger.
So, in my opinion, all email providers should publish expired DKIM keys. Especially the big ones that handle lots of mail like AOL, Gmail, iCloud, Outlook, Yahoo, Yandex, etc. I'll quickly debunk some of the main objections.
-Publishing expired keys doesn't make spam harder to combat since the key gets revoked anyways. Since email accounts rely on the security of both client *and* the server and many people use weak passwords and fall victim to phishing attacks, determining whether someone sent a particular outgoing email depends more on context (server logs, IP addresses, other info) than DKIM signatures. So publishing expired keys probably doesn't make computer forensics harder.
+Publishing expired keys doesn't make spam harder to combat since the key gets revoked anyway. Since email accounts rely on the security of both client *and* the server and many people use weak passwords and fall victim to phishing attacks, determining whether someone sent a particular outgoing email depends more on context (server logs, IP addresses, other info) than DKIM signatures. So publishing expired keys probably doesn't make computer forensics harder.
This practice could make valuable corporate/government email leaks less credible, but CEOs and politicians aren't the only ones who use email. Everybody uses it and making everybody less safe to gain slight confidence that occasional, albeit important email leaks are legitimate doesn't seem worth it.