On November 14, 2016 12:50:01 AM EST, "Murray S. Kucherawy" <superu...@gmail.com> wrote: >On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman ><ietf-d...@kitterman.com> >wrote: > >> Wouldn't a DMARC option to allow senders to specify only messages >that >> pass verification and alignment for BOTH SPF and DMARC accomplish the >same >> result with less complexity and without the layering violation >inherent in >> this proposal? >> > >Doesn't that presuppose point-to-point handling? The proposal here >doesn't.
Your proposal breaks all non-point-to-point handling, if I understand it correctly, so whether you make DKIM signatures non-forwardable or do it in DMARC policy, it's the same end result. > >> DMARC seems to be the policy engine of choice in the community (for >better >> or for worse). I think addressing this at the policy level makes >more >> sense than changing the semantics of DKIM signatures after almost a >decade >> of deployment. >> > >As the problem was presented to me, I haven't heard that DMARC is >specifically involved here. It might be (maybe even "probably" is >apt), >but I haven't heard that, so I limited this idea to just the DKIM >signing >and verifying components of the system. I think your pushing a substantial change to DKIM and to the extent this is a reasonable problem to solve, DKIM isn't the right layer in the email authentication stack to do it. > >> P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately >> convinced I'd want to enable this feature. I don't know if other >distro >> maintainers are on this list or not, but that's one opinion. It's >not >> guaranteed to be widely deployed. >> > >Why is this a distribution issue? Because so far this looks like a source of interoperability problems and bug report headaches I could do without. I think the solution to "I have a problem that results when I sign spam" is "don't do that", not the entire community turns on its head to work around someone's local configuration problems. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
