... "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."
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.
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.
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.
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.
> 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 no-reply@youtube.com. 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 <jmillikin@gmail.com>
(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 postalerts@robtoledoyour.com 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 postalerts@robtoledoyour.com, not Youtube!
Here is what happened: the spammer directly sent the mail from the their machine to google, using postalerts@robtoledoyour.com as the sender. Google verified the SPF: yes that spammer machine 2a01:7c8:bb01:51a::7 is allowed to send messages on behalf of "postalerts@robtoledoyour.com". Meaning that that machine can connect to a Google mail server and use the command:
MAIL from: postalerts@robtoledoyour.com
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: foo-list-bounces@example.com" 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 alltimec____ncool2019@gmail.com (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 alltimec_____ncool2019@gmail.com.
> Correct, this message isn't forged, it's authentic
I personally receive a lot of emails that aren't addressed to me and aren't marked as spam and have always wondered how this works.
Can someone go into a bit more details about why this works? In what way is this message authentic?
The ARC wiki page says "Validating an ARC chain only makes sense if the receiver trusts the ARC signers."; in this case the receiver is Gmail. Why does gmail trust a random domain (robtoledoyour.com)?
The envelope recipient - the account to which the message is delivered - hasn't got anything at all to do with the contents of the "To:" header, which can be absolutely anything. That's how the "Bcc" feature of email works!
The "To:" header is not involved in any way with the delivery of emails.
I think it’s because YouTube.com is the original sender and it’s considered ok if the receiver trusts the signers. The problem IMO is that the receiver’s mail provider (ex: ms365) doesn’t know if the receiver trusts the signers when deciding to deliver messages.
I’ve seen bad actors flood mailboxes with forwarded mail to obfuscate malicious activity. For example, they send a forged message asking for banking info updates and flood the real address that’ll get the “ok done” reply which I assume is an attempt to delay discovery of the attack.
Yes I would love to know why this works as well. I've noticed over the past few months, I get emails that land in my gmail inbox that are obviously spam (various bs offers), and I've always wondered how they are able to bypass the spam filter with ease it seems. Also the To email line is to an email address that is a variation of my email address @aol.com that doesn't actually exist
The latest thing that started happening a week or two ago was an endless stream of unsolicited mailing list messages addressed to "Prunella" trying to get me to click on links. Ended up just setting up an autodelete when that name is in the Send field (because I discovered Gmail doesn't let you auto-spam folder things).
The reason that message has that addressee is because the To: is protected by the DKIM signature, so whoever relayed the message cannot have changed it.
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."