Live data from Hacker News

Gmail accepts forged YouTube emails

john-millikin.com

81–90 of 101 posts

Re: Gmail accepts forged YouTube emails

#81
post #66

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 su…

> 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 to be allowed to send email on behalf of should require explicit permission in DNS records (or similarly canonical location). As you note, this would break some…

> I think requiring approval would be the correct behavior. For to be allowed to send email on behalf of should require explicit permission in DNS records (or similarly canonical location).

This is what DMARC solves, I believe

Re: Gmail accepts forged YouTube emails

#82
post #72

Earlier quoted context omitted.

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 a…

I think the core disagreement is whether forwarding an unmodified signed email should be considered "from the original author" or "from the nearest authenticated hop". You say that the email should be considered to be from YouTube, because it was originally created and signed by YouTube. In your model, the fact it was received from some unknown third party is non-notable. I think it's the most recent hop that matters…

Here's the interesting thing: DKIM verifies the message contents. You can add many hops through many servers and still verify the DKIM - It's a design feature, actually, because of

Similarly to GPG, where an authenticated e-mail can be forwareded but you can still read and verify the original author's signature, DKIM hashes over the message contents and not the headers, so you can add remailer headers and still verify the original domain. It appears that the message contents are indeed from youtube.com, even if it was forwarded. This is the property that we want from mailing lists, where you can verify the original sender's domain authorized the letter even though you received it from a different domain.

Why someone is forwarding a legit google e-mail on and adding their own address, I cannot say. There's probably security implications, and ways to abuse it, but the message itself and the DKIM check are legit.

Re: Gmail accepts forged YouTube emails

#83

Earlier quoted context omitted.

> This is fully misguided. It is not. There's still a significant amount of spam that doesn't have SPF, there's a lot of forgery and it's easier to filter if everyone used the holy trinity. > SPAM is mostly sent through illegitimately acquired accounts on big-brand servers now. That's what you see on and from gmail, but it's not the majority of spam.

> It is not. There's still a significant amount of spam that doesn't have SPF, there's a lot of forgery and it's easier to filter if everyone used the holy trinity. Absolutely. But but again, this will _not_ solve SPAM as the parent implied. > That's what you see on and from gmail, but it's not the majority of spam. There's a huge variability on sources, depending also on the class of users you have on your server. H…

> But but again, this will _not_ solve SPAM as the parent implied.

Nothing will, it's an unreasonable standard to set for a proposal intended to improve the situation.

> it wouldn't _improve_ the ham/spam filtering ratio in my case.

But for many it would. Plus it would force legitimate e-mail senders to stay on-par with the spammers'.

Re: Gmail accepts forged YouTube emails

#84
post #63
post #5

Earlier quoted context omitted.

An attempt at increasing reputation? Nobody is going to mark that as a spam.

I'm sure many people will mark anything they are not interested in as spam.

My rule: If there isn't a prominent, 1-click unsubscribe link in an email, it gets marked as spam.

If I click unsubscribe, and the form asks me to fill in information, it gets marked as spam. No, I'm not filling in my email, let alone completing a CAPTCHA, to ask you to stop sending me emails.

However, I don't click an unsubscribe link in an email where I suspect the unsubscribe link is itself a scam to collect information.

Re: Gmail accepts forged YouTube emails

#85

Earlier quoted context omitted.

> 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 to be allowed to send email on behalf of should require explicit permission in DNS records (or similarly canonical location). As you note, this would break some…

> I think requiring approval would be the correct behavior. For to be allowed to send email on behalf of should require explicit permission in DNS records (or similarly canonical location). This is what DMARC solves, I believe

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.

Re: Gmail accepts forged YouTube emails

#86
post #72

Earlier quoted context omitted.

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 a…

I think the core disagreement is whether forwarding an unmodified signed email should be considered "from the original author" or "from the nearest authenticated hop". You say that the email should be considered to be from YouTube, because it was originally created and signed by YouTube. In your model, the fact it was received from some unknown third party is non-notable. I think it's the most recent hop that matters…

I don't think that's the core disagreement at all. You're being too unspecific about what "from" you are talking about. :)

All the YouTube.com DKIM signature says is that YouTube.com did in fact author this content. Which is true!

ARC and SPF (both present on this message!) indicate that the last hop was not YouTube.com, and who the last hop was! So all the information you were asking for is in fact present here.

What you are suggesting is just a different phrasing of your prior suggestion: that people should not be allowed to forward email. And given this message has an ARC header that indicates it was forwarded, and from whom, it seems really strange to me to say that instead of messages that indicate they were forwarded, you think we should just ban forwarding entirely.

Maybe the problem is on Gmail's MUA: maybe this should be more prominently shown to the user as a forwarded email?

Re: Gmail accepts forged YouTube emails

#87
post #63

Earlier quoted context omitted.

I'm sure many people will mark anything they are not interested in as spam.

My rule: If there isn't a prominent, 1-click unsubscribe link in an email, it gets marked as spam. If I click unsubscribe, and the form asks me to fill in information, it gets marked as spam. No, I'm not filling in my email, let alone completing a CAPTCHA, to ask you to stop sending me emails. However, I don't click an unsubscribe link in an email where I suspect the unsubscribe link is itself a scam to collect infor…

I've been toying with just automatically trashing any email that contains the string "unsubscribe", in any context.

Re: Gmail accepts forged YouTube emails

#88
post #10

Earlier quoted context omitted.

Correct, this message isn't forged, it's authentic. You can check the signature yourself.

Then why was it addressed to "alltimecaptaincool2019@gmail.com" and why was it sent from postalerts@robtoledoyour.com ?

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.

Re: Gmail accepts forged YouTube emails

#89
post #86

Earlier quoted context omitted.

I think the core disagreement is whether forwarding an unmodified signed email should be considered "from the original author" or "from the nearest authenticated hop". You say that the email should be considered to be from YouTube, because it was originally created and signed by YouTube. In your model, the fact it was received from some unknown third party is non-notable. I think it's the most recent hop that matters…

I don't think that's the core disagreement at all. You're being too unspecific about what "from" you are talking about. :) All the YouTube.com DKIM signature says is that YouTube.com did in fact author this content. Which is true! ARC and SPF (both present on this message!) indicate that the last hop was not YouTube.com, and who the last hop was! So all the information you were asking for is in fact present here. Wha…

I'll try using different terms, in hopes that'll help:

* The author of the email is , verified by DKIM.

* The sender of the email is , verified by TLS.

If the author and the sender are the same, then there's no problem -- that's who the email is from.

If the author and the sender are different, you think the email is "from" the author, and I think the email is "from" the sender.

IMO whether the content was originally authored by YouTube might be interesting in some vague abstract chain-of-trust sense, but it's not useful to me as a consumer of email. I want to know (1) why some message came to arrive in my inbox and (2) who sent it to me. The desired UX is something like this:

  [postalerts@robtoledoyour.com] Updates to YouTube's Terms of Service
(ideally also tagged as spam due to the mismatch between author and sender)

An analogy might be physical mail. If I receive a copy of Dante's Inferno in my mailbox, then I expect the return address to describe the person who put my address on the shipment. It would be beyond useless for the return address to say "Dante Alighieri, Italy" even though that is an accurate description of the work's author.

Re: Gmail accepts forged YouTube emails

#90

Fun fact: sns.amazonaws.com has no DMARC record. Basically all alerts from AWS can be forged or end up in your spam folder and you have no way to know they really came from Amazon. You might say: oh, there's probably a good reason they don't have DMARC, right? Apparently the reason is it's a feature request that they haven't gotten to. And SNS has been around for 12 years. If I'm a hacker trying to phish someone into…

Why would you use SNS to send emails? That just seems really silly to me. It’s meant for pub-sub. I’d alert with PagerDuty or OpsGenie, so I’d not only get an email but a text or voice call.

SNS has two modes: A2A and A2P. A2A is pub-sub, A2P is for sending notifications to users (via e-mail, SMS, or mobile push)

CloudWatch Alerts are sent from SNS, and I would imagine others are as well, although some may use SES. I think SES has the same issue, as the AWS docs only mention DMARC/DKIM in the context of a custom domain.

Post reply on HN