3 ms·

So I just tested it again (took a while as forgot needed the -crlf option in s_client) So, gmail does rewrite the From: header (well it keeps the name, but rep

So I just tested it again (took a while as forgot needed the -crlf option in s_client) So, gmail does rewrite the From: header (well it keeps the name, but replaces the email within the <brackets> and adds a X-Google-Original-From header), and as this story is about senders (not receivers), spoofing would be protected in that regard. However, what I remember now, is that I was proving that it doesn't tell you anything if the person in the To: was actually sent the mail. i.e. even though DKIM protects the "To:" and "From:" headers it has nothing to do with the Rcpt To: (i.e. think how BCC works). So DKIM doesn't prove that an email was actually sent to someone (even if its on their machine now), just that someone might have faked a scheme where they sent an email with a To in the headers to someone, but the RCPT TO was not that person. So, it get signed as such, but isn't true. And in the case of gmail, the only reason there's any form of protection on the From: header is because gmail enforces a level of protection outside of dkim. So what I must have done back then, was send people emails that looked like they were meant for Hunter Biden to receive that had all the DKIM validation check out, but were obviously never sent to him. (with all that said, for someone to have actually done this to Hunter Biden, they would have had to be playing such a long game, it's almost inconceivable to me, I was just proving that DKIM doesn't actually tell you if the supposed recepient is actually the receipient when sent via gmail, but as others have noted, if the From: header in the email isn't as locked down as gmail (and I'm sure not all are) / one knows of an exploit in gmail to subvert the From header in place editing, then it doesn't even help with that). anyways, I apologize for exaggeration in my original post, its wasn't quite accurate. I hope I cleared up any confusion I caused.

logifail 3y ago
> So DKIM doesn't prove that an email was actually sent to someone (even if its on their machine now), just that someone might have faked a scheme where they sent an email with a To in the headers to someone, but the RCPT TO was not that person. We find the DKIM headers on the recipient's copy of messages, and they confirm information about the authenticity of the sender, right? So a malicious actor in league with Alice prepares a laptop which purports to be Bob's (but isn't).... and on it there are DKIM-signed messages "From: Alice <alice@example.com>" and apparently "To: Bob <bob@example.com>", except they didn't actually go anywhere near Bob because they were "RCPT TO: <someone_else>"? ...or is there more to it?
- compsciphd 3y ago
  that's it. I'd think that if one attacks the sender, one could even do it without the purported senders cooperation could also cause it to happen. Now, especially because google rotates DKIM keys this would be such a long game attack that in my view, it's very improbable to be such a scenario.
  - logifail 3y ago
    > [without] the purported senders cooperation Thinking about forging mail, in the case of senders who control their DKIM signing keys (me, for instance), if you have the sender's cooperation then you have access to their private DKIM key, can't you just sign any message you like? No need for the messages you're forging and signing to go anywhere near any email clients or mailservers at all.
    - compsciphd 3y ago
      yes, for example, an insider at google could conceptually have forged a mail. just don't consider that probable. I think its more important to understand the limitations of what DKIM is telling us.

logifail 3y ago

> So DKIM doesn't prove that an email was actually sent to someone (even if its on their machine now), just that someone might have faked a scheme where they sent an email with a To in the headers to someone, but the RCPT TO was not that person. We find the DKIM headers on the recipient's copy of messages, and they confirm information about the authenticity of the sender, right? So a malicious actor in league with Alice prepares a laptop which purports to be Bob's (but isn't).... and on it there are DKIM-signed messages "From: Alice <alice@example.com>" and apparently "To: Bob <bob@example.com>", except they didn't actually go anywhere near Bob because they were "RCPT TO: <someone_else>"? ...or is there more to it?

compsciphd 3y ago
that's it. I'd think that if one attacks the sender, one could even do it without the purported senders cooperation could also cause it to happen. Now, especially because google rotates DKIM keys this would be such a long game attack that in my view, it's very improbable to be such a scenario.
- logifail 3y ago
  > [without] the purported senders cooperation Thinking about forging mail, in the case of senders who control their DKIM signing keys (me, for instance), if you have the sender's cooperation then you have access to their private DKIM key, can't you just sign any message you like? No need for the messages you're forging and signing to go anywhere near any email clients or mailservers at all.
  - compsciphd 3y ago
    yes, for example, an insider at google could conceptually have forged a mail. just don't consider that probable. I think its more important to understand the limitations of what DKIM is telling us.