4 ms·

As other commenters noted, this doesn't seem to be a "forged" message at all; it's DKIM-signed by youtube.com. Probably whoever owns "alltimecaptaincool2019@gm

by md_ 4y ago

As other commenters noted, this doesn't seem to be a "forged" message at all; it's DKIM-signed by youtube.com. Probably whoever owns "alltimecaptaincool2019@gmail.com" has it forwarding to "robtoledoyour.com", who is then forwarding (with ARC!) to the author's Gmail mailbox. I don't see why this shouldn't work--there's nothing in DKIM, DMARC, or ARC which is intended to prevent forwarding of legitimate emails (and such a feature would annoy many users of email!). A well-functioning spam classifier knows that this email a) has a body that was signed by YouTube.com, b) was forwarded via robtoledoyour.com, and can make a spam classification decision based on that. Allowing the mail through seems reasonable given the contents are not spammy. I'm unclear on what a protocol--SMTP or anything else!--could do better here other than just not support forwarding mail at all (or require bidirectional approval before allowing forwarding), which would be hugely disruptive to existing email users.

jmillikin 4y ago
> I'm unclear on what a protocol--SMTP or anything else!--could do better > here other than just not support forwarding mail at all (or require > bidirectional approval before allowing forwarding) I think requiring approval would be the correct behavior. For <robtoledoyour.com> to be allowed to send email on behalf of <youtube.com> should require explicit permission in <youtube.com> DNS records (or similarly canonical location). As you note, this would break some of the remaining hold-outs who treat SMTP as an unauthenticated store-and-forward protocol. This seems both directionally correct, and aligned with how use of email has changed over the past ~20 years.
- md_ 4y ago
  > I think requiring approval would be the correct behavior. For <robtoledoyour.com> to be allowed to send email on behalf of <youtube.com> should require explicit permission in <youtube.com> DNS records (or similarly canonical location). Sorry, by "bidirectional approval" I meant that the author's (i.e. recipient's) mailbox would somehow confirm its desire to receive mail forwarded by robtoledoyour.com. What you describe is, I think, impossible without eliminating certain extremely common use cases; it would break: * Mailing lists (which are the whole reason ARC exists); I don't want to have to approve lists.kernel.org to send arbitrary mail on behalf of me (and certainly not on behalf of gmail.com, which I don't control!); I want it to be able to forward mail that it promises came from me and for recipients to trust it only if they trust lists.kernel.org (which is how ARC works). * Mail forwarding between a user's different mailboxes; there's no way I can get Amazon.com to agree that myspambox@gmail.com should be allowed to forward mail on behalf of Amazon just so I can use a throwaway to forward mail to my main account. I can imagine configurations where everything works dramatically differently, but it's hard for me to see what's wrong with the status quo (a signed message, with ARC, etc) except that To headers are allowed to not match RCPT TO, which as others have noted is both a point of confusion for users and how BCC works, and thus a hard to eliminate feature.
  - jmillikin 4y ago
    > Mailing lists (which are the whole reason ARC exists) It would break mailing lists that want to have the original author's unmodified email address in the `From` header, which ... sounds fine? Contemporary mailing list software sends `From` headers like this: 'Jane User' via Some Mailing List <some-list@example.com> which is verifiable. > Mail forwarding between a user's different mailboxes I would expect this to continue to work as before, as long as the mailboxes are in the same MTA -- for example admin@ and postmaster@ forwarding to jdoe@. If you mean `admin@example.com` forwarding to `jdoe@otherdomain.com`, then I think it would be appropriate to require explicit bidirectional opt-in (and Gmail IIRC does enforce just that). edit: Also, this doesn't need to be enforced for all domains from the start. If domains want to continue to be open forwarders that let anyone use them to send spam, they don't need to set SPF/DKIM/DMARC records (and receivers like Gmail will continue to bit-bucket their mail).
    - md_ 4y ago
      I think you're basically describing the current ecosystem. :) ARC allows what you describe for mailing lists, only, even better, it's machine-readable--the message metadata indicate that "Jane User" sent the mail, according to "Some Mailing List", and that Jane User's email was verified per DKIM! And MTAs can (as you note) require bidirectional confirmation for forwarding and (as you note) can easily identify which authenticated senders actually sent the mail and, if they determine it's an open relay, bitbucket it! So what you describe is pretty much the status quo, I think. The fundamental issue with the YouTube mail the author has encountered, of course, is that the forwarding domain is authenticated as having passed on an (unmodified) YouTube.com email, and Gmail--quite reasonably, I think--just doesn't know enough to know if the Gmail recipient of that forward wanted it. Since the message has no obvious signs of spam (like linking to a suspicious domain), it seems reasonable to me to treat this like any other authenticated, non-spammy email from a domain Gmail has not seen much volume from before (which I assume is the case here). Ultimately, even with DKIM, DMARC, and ARC, email allows people to send mail to people they've never communicated with before, and this is an important function to preserve! (As an aside, I totally acknowledge that a) the protocol complexity in email is a lot worse than it could be if all this functionality was built in up front, and b) there are alternative tradeoffs we could make that would remove some of this complexity. And the complexity is obviously a problem for user comprehension or else we wouldn't be having this conversation! But, fundamentally, if we want to make significant changes, we would have to revisit seemingly desirable features like non-matching envelope and header To, allowing unsolicited email from other people, authenticated forwarding, etc.)
- iamacyborg 4y ago
  > I think requiring approval would be the correct behavior. For <robtoledoyour.com> to be allowed to send email on behalf of <youtube.com> should require explicit permission in <youtube.com> DNS records (or similarly canonical location). This is what DMARC solves, I believe
  - LeonM 4y ago
    What DMARC solves is that you can allow a service to originally send email on behalf of a domain. It does this by adding a 'alignment' requirement for SPF and DKIM, on top of the simple pass/fail mechanism. - For SPF alignment the domain part of the rfc5321.mailfrom and rfc5322.from must match. - For DKIM alignment, the public key must be published under the domain found in the rfc5322.from address. If either SPF or DKIM is aligned the email is considered a DMARC pass. Since SPF alignment breaks with forwarding (amongst other horrible flaws), it is common practice to focus on DKIM and not rely on SPF. Once an email is DKIM aligned (thus passes DMARC), it will remain aligned if the email is forwarded. This is by design, so that DMARC will not break forwarding. The email in the article was originally DKIM aligned (thus passed DMARC inspection), then forwarded. There are various strictness settings in SPF, DKIM and DMARC in both the DNS records and the email headers, but none will prevent forwarding of email.

by md_ 4y ago

jmillikin 4y ago

> I'm unclear on what a protocol--SMTP or anything else!--could do better > here other than just not support forwarding mail at all (or require > bidirectional approval before allowing forwarding) I think requiring approval would be the correct behavior. For <robtoledoyour.com> to be allowed to send email on behalf of <youtube.com> should require explicit permission in <youtube.com> DNS records (or similarly canonical location). As you note, this would break some of the remaining hold-outs who treat SMTP as an unauthenticated store-and-forward protocol. This seems both directionally correct, and aligned with how use of email has changed over the past ~20 years.

md_ 4y ago
> I think requiring approval would be the correct behavior. For <robtoledoyour.com> to be allowed to send email on behalf of <youtube.com> should require explicit permission in <youtube.com> DNS records (or similarly canonical location). Sorry, by "bidirectional approval" I meant that the author's (i.e. recipient's) mailbox would somehow confirm its desire to receive mail forwarded by robtoledoyour.com. What you describe is, I think, impossible without eliminating certain extremely common use cases; it would break: * Mailing lists (which are the whole reason ARC exists); I don't want to have to approve lists.kernel.org to send arbitrary mail on behalf of me (and certainly not on behalf of gmail.com, which I don't control!); I want it to be able to forward mail that it promises came from me and for recipients to trust it only if they trust lists.kernel.org (which is how ARC works). * Mail forwarding between a user's different mailboxes; there's no way I can get Amazon.com to agree that myspambox@gmail.com should be allowed to forward mail on behalf of Amazon just so I can use a throwaway to forward mail to my main account. I can imagine configurations where everything works dramatically differently, but it's hard for me to see what's wrong with the status quo (a signed message, with ARC, etc) except that To headers are allowed to not match RCPT TO, which as others have noted is both a point of confusion for users and how BCC works, and thus a hard to eliminate feature.
- jmillikin 4y ago
  > Mailing lists (which are the whole reason ARC exists) It would break mailing lists that want to have the original author's unmodified email address in the `From` header, which ... sounds fine? Contemporary mailing list software sends `From` headers like this: 'Jane User' via Some Mailing List <some-list@example.com> which is verifiable. > Mail forwarding between a user's different mailboxes I would expect this to continue to work as before, as long as the mailboxes are in the same MTA -- for example admin@ and postmaster@ forwarding to jdoe@. If you mean `admin@example.com` forwarding to `jdoe@otherdomain.com`, then I think it would be appropriate to require explicit bidirectional opt-in (and Gmail IIRC does enforce just that). edit: Also, this doesn't need to be enforced for all domains from the start. If domains want to continue to be open forwarders that let anyone use them to send spam, they don't need to set SPF/DKIM/DMARC records (and receivers like Gmail will continue to bit-bucket their mail).
  - md_ 4y ago
    I think you're basically describing the current ecosystem. :) ARC allows what you describe for mailing lists, only, even better, it's machine-readable--the message metadata indicate that "Jane User" sent the mail, according to "Some Mailing List", and that Jane User's email was verified per DKIM! And MTAs can (as you note) require bidirectional confirmation for forwarding and (as you note) can easily identify which authenticated senders actually sent the mail and, if they determine it's an open relay, bitbucket it! So what you describe is pretty much the status quo, I think. The fundamental issue with the YouTube mail the author has encountered, of course, is that the forwarding domain is authenticated as having passed on an (unmodified) YouTube.com email, and Gmail--quite reasonably, I think--just doesn't know enough to know if the Gmail recipient of that forward wanted it. Since the message has no obvious signs of spam (like linking to a suspicious domain), it seems reasonable to me to treat this like any other authenticated, non-spammy email from a domain Gmail has not seen much volume from before (which I assume is the case here). Ultimately, even with DKIM, DMARC, and ARC, email allows people to send mail to people they've never communicated with before, and this is an important function to preserve! (As an aside, I totally acknowledge that a) the protocol complexity in email is a lot worse than it could be if all this functionality was built in up front, and b) there are alternative tradeoffs we could make that would remove some of this complexity. And the complexity is obviously a problem for user comprehension or else we wouldn't be having this conversation! But, fundamentally, if we want to make significant changes, we would have to revisit seemingly desirable features like non-matching envelope and header To, allowing unsolicited email from other people, authenticated forwarding, etc.)
iamacyborg 4y ago
> I think requiring approval would be the correct behavior. For <robtoledoyour.com> to be allowed to send email on behalf of <youtube.com> should require explicit permission in <youtube.com> DNS records (or similarly canonical location). This is what DMARC solves, I believe
- LeonM 4y ago
  What DMARC solves is that you can allow a service to originally send email on behalf of a domain. It does this by adding a 'alignment' requirement for SPF and DKIM, on top of the simple pass/fail mechanism. - For SPF alignment the domain part of the rfc5321.mailfrom and rfc5322.from must match. - For DKIM alignment, the public key must be published under the domain found in the rfc5322.from address. If either SPF or DKIM is aligned the email is considered a DMARC pass. Since SPF alignment breaks with forwarding (amongst other horrible flaws), it is common practice to focus on DKIM and not rely on SPF. Once an email is DKIM aligned (thus passes DMARC), it will remain aligned if the email is forwarded. This is by design, so that DMARC will not break forwarding. The email in the article was originally DKIM aligned (thus passed DMARC inspection), then forwarded. There are various strictness settings in SPF, DKIM and DMARC in both the DNS records and the email headers, but none will prevent forwarding of email.