IMO, the scope should be implicit from the specification.
"Implicit" instructions in specifications have historically meant
inter-operability problems, and security flaws.
The specifications exist to make scope/intent explicit. Adding a
few more sentences to clarify the scope would be a good idea for any
specification.
Of course and I my suggestion is completely consistent. Read on below to the
end...
The point I am making is not against specifying the scope of the data being
exposed, but against specifying multiple scopes in multiple records, because
this will lead to confusion, fragmentation, etc.. Some examples of possible
confusion:
1. "Why are there two different ways to specify the approved mail servers for
my domain?"
2. "Which is better?"
3. "Which is required?"
etc..
You create a proliferation of issues, proliferation of debate, proliferation of
DNS records, proliferation of competitive issues, ... in short, you do not
create a useful standard.
If there is a compelling technical reason to need multiple scopes on the DNS
record, then you can consider the tradeoffs. There is no compelling technical
reason.
And if so, do you actually think it is better for the receiver to have
to guess the intended scope of the sender?
Yes because inherent in the design of the specification should be
acknowledged the *REALITY* that the sender can not control the
receiver (verifier).
Control is different from intent. MX records in DNS are intended to
be used as destination IP's for SMTP traffic to a domain, and that
intent is explicit in the specifications. Yet nothing stops anyone
from doing:
$ ping `host -t mx example.com`
Your analogy is comparing apples to oranges. In the case of MX records, the
scope specified is a 100% solution to the need that it is for.
In the case of per-domain anti-forgery authentication, all the current
algorithms for processing the approved mail servers DNS record do not give a
100% result. Thus it is impossible to declare the *FINAL* scope. No one knows
today what the *FINAL* scope will be.
Instead the best we can do is declare what the data that is being exposed means
and what it is intended to be used for.
In short, with MX there is no compelling need to use the data in any other way
than the exact scope specified. Whereas in our case, the data is going to be
used in creative ways to accomplish the goals of the receiver.
And I assert that by fragmenting the scope into multiple DNS records, you will
actually have the reverse of the intended effect. Instead of limiting scope,
you will cause all sorts of adhoc algorithms to try to give the anti-forgery
results desired by recipient based on multiple records.
It seems your logic above assumes that recipient will only deal with one DNS
record orthogonally. So what does recipient do with multiple scopes? What
does recipient do when the result from scope(s) is neutral or error or
inconclusive?
For MARID issues, the intent of the publisher of the records should
be made explicit in the specifications, if not the protocol. For the
vast majority of recipients who use the records as expected, having
that intent explicit makes their jobs easier. For the recipients who
don't follow the publishers intent, it makes no difference to have
that intent explicit, because they won't follow it.
Make explicit how I can deal with the case with PRA where the Resent-Sender: is
not forged but the From: header is forged? Ditto for MAILFROM: and From: in
SPF?
Make explicit how I can use the the results from either scope algorithm to help
fight spam?
Make explicit how I can combine multiple results from multiple scopes?
I think it would be folly and brittle for us to attempt to specify
*ALL* the ways that the data in the DNS record can be used and
interpreted, ...
Similarly, it would be follow to specify *no* standard way for the
data to be used and interpreted.
We should specify what we can specify. But adding uncompelling scopes when it
is the same underlying data is not useful.
There is a happy medium. We should find it, and use it.
Agreed. I think that happy consensus medium would be to specify the approved
mail servers for a domain, and then specify some of the possible algorithms
that might be applied by receivers.