On 12/30/2014 6:38 AM, MH Michael Hammer (5304) wrote:
> he first question is whether this is a matter of local policy. If the
> answer is yes (Which I believe and invoke King Canute), then anything
> written IS a recommendation (even if it is only documenting what "We"
> - for some definition of "we" - believe is existing common practice.
Documenting common practice is fine for a document seeking to be a BCP.
For a document specifying a protocol, it is best to be simpler and more
definitive.
Define the boundaries of the protocol. Try to put everything in
terms of MUST or MUST NOT. Allows SHOULD [NOT] when it is understood
that some exceptions by knowledgeable actors can reasonably be
tolerated. Include MAY (MAY NOT isn't really meaningful IMO) to permit
benign flexibility that the community consider plausibly useful.
But discussion of what an actor might do outside of the boundaries of
the protocol really are outside of the protocol.
Especially in the context of DMARC, most references to "local policy"
have tended to serve to blur the demarcation between what is inside the
protocol and what is outside.
What is really meant, when we say "local policy" for DMARC is:
Outside of the DMARC spec, you can do what you want.
This is, of course, a tautology, but we keep talking as if it isn't.
DMARC has a pretty simple model.
If you are a domain owner participating in DMARC, you publish an
associated record and state your desires. If you are a receiver
participating in DMARC, you attend to that record, after performing some
tests on the message.
The tests are also pretty simple, at the level of DMARC. We have
discussed them at length. Since they involve some sequencing, we've had
some fun getting the exact language right, but none of that has been a
debate about the actual algorithm; it's strictly wordsmithing.
So DMARC's conditions for asserting the requests by a domain owner
are crisp and simple.
What is inherently fuzzy is how to handle a temporary failure. Unlike a
transport-level timeout, the handling of temporary failures at the
application level often are a matter taste.
(Note that some of the original Arpanet specs including guidance such as
"wait for something to change". So guidance can indeed be fuzzy.)
It might help to distinguish between the detection of a temporary
failure versus what to do in the event of a temp failure.
The occurrence of a temporary failure is objective and needs to be
specified within the protocol. We need to state what qualifies as a
temp fail and then simply label it as such.
For the /handling/ of a temp fail, we need to decide whether a
DMARC participant is obligated to try again versus obligated /not/ to
try again. The nature of 'conformance' we might specify can be nicely
distinguished by choosing one of MUST, SHOULD or MAY, possibly with some
justification text.
After that, any discussion of possible receiver actions moves into the
realm of BCP operational preferences. As long as the text is clear that
this all really is outside the protocol and rather moves into local
preferences for how to use DMARC within the local system, that's fine.
Instead of saying 'local policies' or 'local overrides', we ought to
help ourr clarity by saying something like "ad hoc, non-DMARC policies"
or the like.
That is, 'local policy' means 'independent of the DMARC specification.'
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
