4 ms·

> 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 explic

by md_ 4y ago

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

jmillikin 4y ago
> 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).
- md_ 4y ago
  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.)
  - jmillikin 4y ago
    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.

by md_ 4y ago

jmillikin 4y ago

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

md_ 4y ago
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.)
- jmillikin 4y ago
  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.