[kazinator]

... "In fact, an ARC chain can be counterfeited,[3] so ARC processing applies when receivers trust the good faith of ARC signers, but not so much their filtering practices."

Hmm, article references an e-mail post by good old John Levine, moderator of comp.compilers for over 30 years, who has some interesting things to say:

"[If] I were a certain kind of bad guy, I would take the two seal ARC chain from a message from a virtuous sender, replace the message body and >From and Subject line with my spam, add a fresh new i=3 seal and blast it out. That ARC chain is 100% valid, even though the messsage is spam."

[jeffbee]

You're implying that this message has been tampered with, but it has not. It is perfectly authentic. Whoever produced this message possesses the private signing key of youtube.com. This message has in no way been forged.

The only mystery here is why someone is mirroring google mail back to gmail with unexpected envelope recipients. It could be a weird error, or it could be they think they can game the IP reputation system by doing it.

In any case, the fine moderators ought to correct the title, because it is wrong and misleading.

[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.

[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].