Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gmail accepts forged YouTube emails

john-millikin.com

Post reply on HN
Print view View original

61–70 of 101 posts

Re: Gmail accepts forged YouTube emails

#61

Post by Benjamin_Dobell »

Gmail / Google Workspaces don't care about their paying customer's privacy and are too lazy to improve their deliverability. Issues with inbound header handling wouldn't surprise me either.

If you use multiple domains with Google Workspaces and noticed your emails not getting through when sent from your non-primary domain; you're not imagining it. Any mail receivers that are properly checking SPF are not going to give you a good deliverability score, no matter what you do. Gmail leaks your primary domain in the Reply-Path rather than specifying the domain you sent the email from. I've reported this to them, they don't give a shit. Fun.

Re: Gmail accepts forged YouTube emails

#62

Post by speleding »

Benjamin_Dobell wrote: post #61

Gmail / Google Workspaces don't care about their paying customer's privacy and are too lazy to improve their deliverability. Issues with inbound header handling wouldn't surprise me either. If you use multiple domains with Google Workspaces and noticed your emails not getting through when sent from your non-primary domain; you're not imagining it. Any mail receivers that are properly checking SPF are not going to giv…

Yeah, there are reports of Gmail setting the Return-Path to the primary domain going back a decade ago. That makes the alternative domain pretty useless if you want to get SPF passing. Fastmail does the right thing FWIW, they switch the Return-Path to the alternative domain when you send from there.

Re: Gmail accepts forged YouTube emails

#63

Post by yreg »

RL_Quine wrote: post #5
actionablefiber wrote: post #2

Any ideas for why that email appeared in your inbox? It doesn't look like it's a phishing attack - "Updates to YouTube's Terms of Service" is a subject line that guarantees that precisely zero people will even bother opening it.

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.

Re: Gmail accepts forged YouTube emails

#64

Post by yreg »

geoduck14 wrote: post #22
tjpnz wrote: post #18

Earlier quoted context omitted.

I liked Bill Gates' idea of making senders pay a fee (perhaps a minimum amount specified by the recipient) and giving recipients the option of refunding it for personal contacts.

Ok. So. I'm not going to say that is a bad idea, but I will share a story. I used to work for a company that was the USPS's #1 or #2 customer (depending on the year). We spent a TON of money on spam. The biggest cost was the stamp. If people have to start paying for emails- it will eliminate a lot of the spam - but it won't eliminate all of the spam - and companies like the one I used to work for will start to shine.

People who deliver spam to my physical mail box IRL spend money on it and manage to fill it no problem.

However, if they also had to pay me I would mind the spam a lot less.

Re: Gmail accepts forged YouTube emails

#65

Post by rchard2scout »

kazinator wrote: post #28

> addressed to an address that isn't mine. This is because John was the envelope recipient: the one named in the SMTP protocol "RCPT to:" command. There are ways that a perfectly legitimate e-mail you receive night not mention any of your addresses in To: or Cc:. E.g. you are subscribed to a mailing list and some new posting (not part of some discussion you are in) arrives. It might just be addressed as "To: whatever…

Or because you're in the Bcc:

Re: Gmail accepts forged YouTube emails

#66

Post by md_ »

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.

Re: Gmail accepts forged YouTube emails

#67

Post by jmillikin »

md_ wrote: 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 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.

Re: Gmail accepts forged YouTube emails

#68

Post by md_ »

jmillikin wrote: post #67
md_ wrote: 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).

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.

Re: Gmail accepts forged YouTube emails

#69

Post by haruka_ff »

RL_Quine wrote: post #5
actionablefiber wrote: post #2

Any ideas for why that email appeared in your inbox? It doesn't look like it's a phishing attack - "Updates to YouTube's Terms of Service" is a subject line that guarantees that precisely zero people will even bother opening it.

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

This actually sounds like the most plausible reason considering there is really no other incentive to do this.

Re: Gmail accepts forged YouTube emails

#70

Post by jmillikin »

md_ wrote: post #68
jmillikin wrote: post #67

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). 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 eliminatin…

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

Post reply on HN