On November 14, 2016 12:50:01 AM EST, "Murray S. Kucherawy"
<superuser(_at_)gmail(_dot_)com> wrote:
On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman
<ietf-dkim(_at_)kitterman(_dot_)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