Comment by md_ | Hacker News Reader

Comment by md_ | Hacker News Reader

Parent Full thread

> I think requiring approval would be the correct behavior. For <robtoledoyour.com> to be allowed to send email on behalf of <youtube.com> should require explicit permission in <youtube.com> 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.

  > 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 <some-list@example.com>

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

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 authenticated senders actually sent the mail and, if they determine it's an open relay, bitbucket it!

So what you describe is pretty much the status quo, I think. The fundamental issue with the YouTube mail the author has encountered, of course, is that the forwarding domain is authenticated as having passed on an (unmodified) YouTube.com email, and Gmail--quite reasonably, I think--just doesn't know enough to know if the Gmail recipient of that forward wanted it. Since the message has no obvious signs of spam (like linking to a suspicious domain), it seems reasonable to me to treat this like any other authenticated, non-spammy email from a domain Gmail has not seen much volume from before (which I assume is the case here).

Ultimately, even with DKIM, DMARC, and ARC, email allows people to send mail to people they've never communicated with before, and this is an important function to preserve!

(As an aside, I totally acknowledge that a) the protocol complexity in email is a lot worse than it could be if all this functionality was built in up front, and b) there are alternative tradeoffs we could make that would remove some of this complexity. And the complexity is obviously a problem for user comprehension or else we wouldn't be having this conversation! But, fundamentally, if we want to make significant changes, we would have to revisit seemingly desirable features like non-matching envelope and header To, allowing unsolicited email from other people, authenticated forwarding, etc.)

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. Just because the original content of the email came from YouTube does not mean that it should be allowed to claim a @youtube.com From address. It should have a @robtoledoyour.com address, because that was the nearest hop in the forwarding chain that Gmail can verify (e.g. via TLS).

And then, since the email is "from" robtoledoyour.com but claims to be from YouTube, it should be discarded (or at least sent to spam).

As you note, this would break use cases that depend on DKIM to allow relaying email through unrelated third-party servers. I think that's fine, because I don't think third-party relays should be allowed to claim the identity of the original server.

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.

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?

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

* The author of the email is <no-reply@youtube.com>, verified by DKIM.

* The sender of the email is <postalerts@robtoledoyour.com>, 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.

As a nitpick, TLS does not indicate the sender of the email.

You can try using different terms, but the standard terminology in the mail space is "envelope From" vs "header From", as I used above. These are different things, and there's enough information in this email for you to know which is which.

Some MUAs--like Outlook--would render this email as

"Sent by postalerts@robtoledoyour.com on behalf of no-reply@youtube.com"

As I said, it may be that you want your MUA to do that, in which case...use Outlook? But this has nothing to do with limitations of SMTP.

Reply on news.ycombinator.com