4 ms·

Q: If 2FA is enabled on a Google account, does SMTP AUTH still work? I've just tested this, I generated a new app password in my Google Account and used that t

Q: If 2FA is enabled on a Google account, does SMTP AUTH still work? I've just tested this, I generated a new app password in my Google Account and used that to send Gmail from Python. Works fine when sending "from: <me@gmail>" with the app password, yet I can't change the sender since the SMTP auth then fails "5.7.8 Username and Password not accepted. Learn more at https://support.google.com/mail/?p=BadCredentials https://support.google.com/mail/?p=BadCredentials"

dizhn 3y ago
You can set identities in gmail from which you can send emails. If it weren't gmail but a mail server you hosted, it would be even more trivial. Neither of these have to do with SMTP authentication. Without significant other configuration the mail server does not care what Mail From: address you enter. This is how my classmates were able to get emails from the US president back in the day.
- logifail 3y ago
  > You can set identities in gmail from which you can send emails Right, and there's a verification step in which you confirm you own (or at least control) the additional email address[es]: https://support.google.com/mail/answer/22370?hl=en-GB https://support.google.com/mail/answer/22370?hl=en-GB The OP appeared to be talking about somehow persuading Gmail into DKIM-signing an email from an address that wasn't theirs, though?
  - dizhn 3y ago
    The immediate parent?
    - logifail 3y ago
      The post (https://news.ycombinator.com/item?id=37723688 https://news.ycombinator.com/item?id=37723688) to which I replied, although perhaps I'm misunderstanding this bit: "I demonstrated to others that I could have a DKIM signed email sent through gmail that was from a spoofed from: and it passed all DKIM tests (i.e. telnet gmail smtp server 25 (well with ssl, so openssl connect or something). smtp auth and do the standard MAIL FROM "SoSo <so@so> RCPT TO so@so data...... and it will look like a legit mail sent from SoSo" I've tried several times to do what I think is being claimed here and I'm struggling. For instance, telnet to a public mailserver I control, SMTP AUTH with an account with relay permissions, MAIL FROM so@so, RCPT TO my own Gmail, refused by GMail due to so@so's DMARC policy...
      - dizhn 3y ago
        Perhaps the domain in the article has a lax policy as most domains still do. Or what's failing is SPF alignment for you and not dkim.
      - compsciphd 3y ago
        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?

dizhn 3y ago

You can set identities in gmail from which you can send emails. If it weren't gmail but a mail server you hosted, it would be even more trivial. Neither of these have to do with SMTP authentication. Without significant other configuration the mail server does not care what Mail From: address you enter. This is how my classmates were able to get emails from the US president back in the day.

logifail 3y ago
> You can set identities in gmail from which you can send emails Right, and there's a verification step in which you confirm you own (or at least control) the additional email address[es]: https://support.google.com/mail/answer/22370?hl=en-GB https://support.google.com/mail/answer/22370?hl=en-GB The OP appeared to be talking about somehow persuading Gmail into DKIM-signing an email from an address that wasn't theirs, though?
- dizhn 3y ago
  The immediate parent?
  - logifail 3y ago
    The post (https://news.ycombinator.com/item?id=37723688 https://news.ycombinator.com/item?id=37723688) to which I replied, although perhaps I'm misunderstanding this bit: "I demonstrated to others that I could have a DKIM signed email sent through gmail that was from a spoofed from: and it passed all DKIM tests (i.e. telnet gmail smtp server 25 (well with ssl, so openssl connect or something). smtp auth and do the standard MAIL FROM "SoSo <so@so> RCPT TO so@so data...... and it will look like a legit mail sent from SoSo" I've tried several times to do what I think is being claimed here and I'm struggling. For instance, telnet to a public mailserver I control, SMTP AUTH with an account with relay permissions, MAIL FROM so@so, RCPT TO my own Gmail, refused by GMail due to so@so's DMARC policy...
    - dizhn 3y ago
      Perhaps the domain in the article has a lax policy as most domains still do. Or what's failing is SPF alignment for you and not dkim.
    - compsciphd 3y ago
      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?