Hi, > Brandon Long <mailto:[email protected]> > 24 August 2017 at 00:40 > > > On Tue, Aug 22, 2017 at 10:41 PM, Rick van Rein <[email protected] > <mailto:[email protected]>> wrote: > > Hello, > > Thanks for the work on ARC! > > I would like to share a few remarks about > > > draft-ietf-dmarc-arc-protocol-08 > > that could improve its readability, and then there is one technical > remark. I apologise if things are due to reading it not intensely > enoughh, but that is only a sign that I find the draft difficult > to read. > > > [snip] > > > > 11. > It is not clear to me how the market forces would work in getting all > those low-cost / low-effort email forwarding arrangements to implement > this (somewhat complex) technology. Just the fact that keys have > to be > hunt in domains, presumably by users at the level of understanding of > forwarding, sounds like an irrational dream to me. What is the > intention of ARC in that respect? Is the intention to push such > situations out of the Internet [basically breaking email > functionality] > or to use SPF (without DMARC's additional envelope.From==header.From > check) and/or to trace back Received headers on an incoming "real" > mail > deal? What would then be the expectations of SPF on the > forwarding mail > domain? These kinds of impact on the email landscape are incredibly > important, especially because ARC intends to resolve them -- by being > rather heavy-weight. > > > I really don't understand what you're saying here (hunt in domains?) > Typo. "hung" in domains.
> For one, most forwarders, especially the low-cost / low-effort ones, > don't modify mail when forwarding, so there is no DMARC issue. > I've seen at least one that touches the subject, and as a result they have serious problems. > If they do modify mail, they're already hurting today. > Yep. Which is not the same as saying that it's acceptable -- ARC is supposed to help overcome that kind of pain, after all. > It's also true that the email ecosystem of today is more complicated, > and although you can just send mail from anywhere, it's not clear that > anyone will accept your mail without effort. > > The keys put in domains are already a requirement for DKIM, which, if > not a requirement for sending, is a good step at getting your mail > accepted anywhere. > I'm not fighting with the ideas of using crypto. I'm only stating that there may be a much lighter-weight alternative that could increase the chances of getting the simpler forwarders on board. > No one's trying to push anyone out of the Internet, but sometimes the > bar for participation is raised. And no one's saying that ARC will be > a requirement for anything. > It would be sad to raise the bar without a need. Hence the alternative. In practice, ARC will be a requirement for reliable delivery. > One could argue that ARC usage by the larger providers actually allows > you to send mail with only SPF auth and not DKIM, since the SPF auth > will be forwarded with ARC. Probably be a long time before that can > be relied on. > "only SPF" -> "only SPF and a matching From in envelope and header" > As for the rest of the paragraph about SPF and whatever... it sounds > like you're proposing an alternative or something. > Yes, though I'm not sure if it would be added on the same nodes that also do ARC, or on intermediate nodes. > As for the heavy-weight issue, managing a key is the same weight as it > was for DKIM, which isn't to say that most people get it right > (someone should make a lets encrypt style system for managing DKIM > keys, it wouldn't be too hard to do). The rest is handled by the > software, and frankly, although the software may be a bit tricky to > get right, I wouldn't expect the low-cost / low-effort folks to be > writing their own, they'll install something already written and use > it. And that software is much less complicated than say the TLS > software they are also hopefully using. I agree with all that. It's just leaning on parties that hardly have a model of earning an income (forwarders, unlike the senders and recipients of email) that I find unwise. Which made me think of an alternative. -Rick _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
