[jmillikin]

The message has been forged, as can be observed from the From: header being a domain that the sending server was not authorized to send from.

Whether a subset of the message -- in this case the body -- is authentic doesn't matter. If I were to MITM google.com and send back an archived snapshot from a month ago, that would be forged traffic even if it matches responses that Google had once sent.

[jeffbee]

With all due respect, you don’t know what you’re talking about. Relaying month-old traffic is completely acceptable in email.

[azca]

Remembering back to the uucp days and when certain OOB nodes came back up after outages, this is precisely why email as a standard can handle delayed delivery and MX records have preferences for relays that can queue for future delivery.

[jmillikin]

It's not about the age! Look at the headers!

  Received: from 7n.robtoledoyour.com (7n.robtoledoyour.com. [2a01:7c8:bb01:51a::7])
  From: YouTube <[e-mail]>

That email was sent by <robtoledoyour.com>, claiming to be <youtube.com>.

YouTube has not created DNS records allowing <robtoledoyour.com> to send or forward email on its behalf.

[jeffbee]

You are inventing imaginary requirements for email that do not exist. The "From:" header is not part of the envelope. The "From:" header is protected by the DKIM signature. This message is from youtube.com. You received it via some other relay. Nothing about that is weird. People love relaying email all over the place.

[kazinator]

Do you have a hypothesis about why someone would be re-sending these YouTube messages? One possibility is that the original To: recipient of this message is an bad actor's address. Maybe some small percentage of users will contact that address, and thereby get harvested.

[jeffbee]

I think they're trying to goose their sender reputation, but I don't know if that is going to work.

[kazinator]

Interesting; I actually thought about that too! But there are ways it could backfire, like people reporting this junk to blacklist sites. Spamcop doesn't care that what you sent is a copy of a valid e-mail from YouTube with good DKIM.

[kazinator]

> That email was sent by <robtoledoyour.com>, claiming to be <youtube.com>.

Not exactly! The "Received:" header lines track the identities of forwarding hosts. So we know that the mail was forwarded by a certain machine. Here is what I think the line exactly nmeans off the top of my head:

   from 7n.robtoledoyour.com (7n.robtoledoyour.com. [2a01:7c8:bb01:51a::7])
        ^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^
        A                      B                      C

The A, I think, comes from the string that the host gave in the SMTP HELO command. C is the IP address pulled from the SMTP connection, and B is what that resolved to under reverse DNS.

Now, none of these is understood to be the sender. For the purposes of SMTP, the sender is the envelope sender: the argument given in the SMTP "MAIL FROM:" command.

So I think when we are talking about, say, the SPF system, the S refers to that sender. An SPF record published by a domain example.com says something like "if such and such hosts send an e-mail whose envelope sender is example.com, they are blessed to do that".

So yes, there is the concept of whether robtoledyour.com is allowed to forward mails which are from a certain sender.

WHAT WE DON'T KNOW HERE: is what that sender is! We know only the From: address in the header, which is [e-mail]. That is not necessarily the envelope sender!

The e-mail just has a forged From: line, which is easy to do.

Now, let's look at the full e-mail again. There is more information:

  Received: from 7n.robtoledoyour.com (7n.robtoledoyour.com. [2a01:7c8:bb01:51a::7])
          by mx.google.com with ESMTPS id es15-20020a056402380f00b0042de38ce571si326031edb.295.2022.05.31.10.35.25
          for <[e-mail]>
          (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128);
          Tue, 31 May 2022 10:35:25 -0700 (PDT)
  Received-SPF: pass (google.com: domain of [e-mail] designates 2a01:7c8:bb01:51a::7 as permitted sender) client-ip=2a01:7c8:bb01:51a::7;

The Received-SPF line reveals to us who the sender is! You see? The sender is [e-mail], not Youtube!

Here is what happened: the spammer directly sent the mail from the their machine to google, using [e-mail] as the sender. Google verified the SPF: yes that spammer machine 2a01:7c8:bb01:51a::7 is allowed to send messages on behalf of "[e-mail]". Meaning that that machine can connect to a Google mail server and use the command:

   MAIL from: [e-mail]

Google's delivery checks (whatever they are) didn't care that the From: header purports to be from Youtube, not matching the envelope sender at all.

It is legitimate for envelope and From senders not to match. It happens with mailing lists, for instance.

When you get a mailing list post, the From: will indicate the original person who wrote the post. (It had better!) But the mailing list posting is actually from the mailing list, not from that user. When the mailing list robot connects to its forwarding server (or perhaps directly to your server) it will use a command like command "mail from: [e-mail]" and not the address in the From: line.

The mailing list cannot use the address in the From: line because that will not pass SPF checks! Most mailing list sites do not have SPF permission to send mail on behalf of the list participants, as the envelope senders. They have to send as themselves, and just forward the mail data with the original From:.

Now let's discuss the DKIM aspect of this. Google checked the DKIM signature and it passed. This is because what the spammer sent is in fact a Youtube message, verbatim.

Nothing in the body of the message points to the spammer's domain, for instance. All the links in the HTML are the original Youtube material.

Here is possibly what the spammer might be hoping for. It could be that the original target of the Youtube message, namely [e-mail] (the one in the To: header) is an address controlled by the spammer, who is hoping that some of the recipients of the e-mail will send a message to that address.

That will be unlikely because YouTube also set the Reply-to: header. Maybe in some mail clients, if "reply all" is used, it will include [e-mail].