On Tue, Aug 22, 2017 at 10:41 PM, Rick van Rein <r...@openfortress.nl> 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?) For one, most forwarders, especially the low-cost / low-effort ones, don't modify mail when forwarding, so there is no DMARC issue. If they do modify mail, they're already hurting today. 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. 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. 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. As for the rest of the paragraph about SPF and whatever... it sounds like you're proposing an alternative or something. 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. Brandon
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
