Folks,
By way of trying to expand on the discussion about requirements for ARC
to /exit/ Experimental status and enter standards status/document status...
Internet Mail is a global store-and-forward service with many
independent operators. Most Internet Mail is subject to rather simple
operational scenarios, because most Internet Mail travels between a very
small number of very large operators. Their email exchanges essentially
appear to be one-hop between originating provider and receiving
provider. This statistical bias is misleading and creates a perception
of straightforward operational behavior and requirement.
The full range of global email service has more operators and more
handling complexity -- producing more interaction effects -- than the
dominant environments demonstrate. Note that the expanded use of DMARC,
into consumer-to-consumer mail, provides an unfortunate example of this
effect: not many problems amongst the very large operators but very
serious problems for some others, such as users of independent mailing
lists.
ARC produces a /chain/ of signatures. There is essentially no
operational experience doing this in real time in the operational
Internet. We need to learn what dependencies and what fragilities are
relevant to its use.
DKIM has demonstrated that a single signature can be broken by a number
of existing handling scenarios, such as within some operational
enterprises and through most mailing lists. It is therefore entirely
plausible that sending a message through multiple, independent operators
that are performing ARC signing will also produce breakage -- although
the ARC design is explicitly intended to minimize this risk.
This is worth emphasizing: email is an essential infrastructure service
and ad hoc expansion of the policy scope for DMARC -- another
authentication-related mechanism -- has produced significant operational
problems. While it is possible that ARC will not demonstrate such
problematic effects, it is also possible that it will. We should
approach this issue with due caution.
TIn terms of what it validates, the role of ARC signatures is quite
different from the role of SPF or DKIM validations. The nature of this
new role seems to be a form of 'transitive trust', which unfortunately
is not encouraging: my understanding is that operational experience with
mechanisms relying on transitive trust -- especially across multiple,
independent administrations -- has been problematic.
Integration of new types of validation information into email filtering
engines has a learning curve. So far, experience is with a tiny number
of very large operators. This sort of activity is amenable to
special-case, manual configuration, which unfortunately does not expand
into general, large-scale operation for most/all operators in the global
Internet.
Therefore, experimental experience with ARC needs to:
1. Demonstrate use across a 'significant' range of different email
sending software, receiving software, mailing list packages, mailbox
operators and mailing list operators.
2. Demonstrate robust survival of ARC signatures.
3. Demonstrate useful error reporting behaviors.
4. Demonstrate stable operational integration into mail filtering
engines, subject to a 'significant' array of usage policies -- or
demonstrate industry consensus on a small, stable set of policies.
(Vocabulary such as significant and robust and useful are intentionally
vague. Or rather, intentionally subjective. Determining the specifics
that will satisfy them is up to the working group and IETF management.)
When these demonstrations are made, it will be possible to write a usage
BCP that has rich and useful guidance for those wishing to deploy ARC.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
