DKIM had a sound proof of concept when it was introduced, and I hate
to bring it up, but its key attraction, both technically and from a
marketing standpoint, came when it was tied to a DKIM Policy model as
the original specification had it proposed:
DKIM/SSP proposal:
Proposed:
o=~ NEUTRAL (signature optional [,No 3rd party?])
o=- STRONG (signature required, 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
o=^ USER
WG suggestions:
o=? WEAK (signature optional, no third party)
o=~ NEUTRAL (signature optional, 3rd party allowed)
It had a solid hash bound required anchor using a Domain Author Domain
with a published policy for rejection, filtering, classification,
whatever local policy wanted to use including nothing at all. So
solid was the proof of concept, in the words of one prominent person
in the group, "It's scary" of what people can do with a strong,
exclusive rejection/filtering policy model. And the best part was it
actually worked with a low false positive rate -- except for the
indirect, mailing list streams and years later, we are still dealing
with the latter.
ARC has no ties to Policy. The ARC chain concept is sensitive,
extremely high overhead and IMO, unnecessary for what we have been
trying to resolve related to DKIM Policy Strong rejection policies and
how to escape it with the blessings of the originating Author Domain.
Making ARC a PS isn't going to change the fact it is a weak idea (less
than "Half Baked") at this point in addressing the DKIM Policy
Rejection issue with indirect mail.
Tying ARC to a policy system may move the consideration much further
because it may start discussions on Policy Scenarios of what are
valid, invalid ARC seals. Until then, I'll continue to watch to see
where "yuns" are going with this expensive RFC5322 header overhead add-on.
--
HLS
On 1/3/2018 2:05 AM, Murray S. Kucherawy wrote:
On Tue, Jan 2, 2018 at 12:57 PM, Kurt Andersen (b) <[email protected]
<mailto:[email protected]>> wrote:
While John Levine cited the benefits of the "experimental"
approach taken for EAI
(https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw
<https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw>),
I'm also biased by the "let's all just play nice" mess that came
from designating incompatible "versions" of SPF as competing
experiments (see https://tools.ietf.org/html/rfc6686
<https://tools.ietf.org/html/rfc6686> for the eventual outcome of
that six year long experiment).
I'm not sure I understand the comparison. ARC, as far as I know,
doesn't have two factions attempting to advance their own agendas in a
common space. We have just one protocol here. Instead, the bulk of
the debate has been about whether this WG is prepared to stand behind
its processing via the standards track, and I thought we were leaning
toward the answer to that being "no" right now, and the core issue is
whether we want it to be standards track first or have an RFC number
first. If getting it published in some state is more critical than
having it on the standards track, then "experimental" is, to me, the
only option right now. And that's what I think I said in Singapore.
I think that any protocol which has not already been widely
implemented is, in some sense, experimental - if you are looking
at it from the perspective of hind-sight, you might have done some
things differently/more efficiently/etc. One might not have called
IPv6 "IP"-anything or may have chosen a longer address space for
IPv4 for instance.
I'm willing to go along with the consensus of the group, but
wanted to (re)express my continued opposition to the experimental
track for this.
Dave Crocker can probably articulate this better than me, but I'll
take a run at it.
There are two primary drivers for this decision for me:
1) ARC is trying to do something that's different enough from DKIM
(i.e., recording some kind of handling chain) that we really should
have some deployment and impact experience before we can say we have
enough confidence to call it a proposed standard; and
2) The advice that all handlers need to apply a seal to the message,
to which Bron previously and rather strenuously voiced opposition. I
believe the decision was to defer on that issue until we've run some
real-world experiments, which to my knowledge haven't happened.
Unless I've somehow missed a change in posture either by him or by the
specification (which is entirely possible), we're not done enough to
say it ought to be on the standards track.
The counter-argument to (1) is that Proposed Standard really is only a
proposal, but I think our goals are loftier than that here. Then
again DKIM went out PS, right? Well yes, it did, but we weren't in
any perceived hurry that I can recall.
-MSK
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
