Section 6.3 req 7
I don't see what this is driving at at all and at most it should be a SHOULD.
I don't know if my proposal allows for a new mechanism for delegation or not.
Making it impossible to use it in this fashion strikes me as special pleading
for the existing proposal.
In particular I don't see a single positive reason given for the requirement.
Instead what I see is an argument that 'you can do delegation this way'. That
may be so but the mechanism proposed is not simple.
What I am proposing is that we jettison the existing proposal and replace it
with a simple unordered sequence of tag value pairs, each of which describes a
constraint that is met by all mail sent.
The tags being:
NULL
NOMAIL
DKIM [=selectorprefix]
The NULL tag is equivalent to an empty list but may help readability (this
policy intentionally left blank). The NOMAIL tag has the obvious meaning.
If the DKIM tag has no parameter it means 'there is always a DKIM record with a
selector corresponding to the email address'.
If a parameter is specified then the selector on the signature must match the
selector.
I see no reason to artificially constrain the selector, writing the constraint
rules is itself a difficult issue.
Nor do I see the logic here. If I am delegating my mail service to Fred then I
want to write a single DNS record that says 'Fred is responsible for
everything' and have done with it for all time. The requirements draft is
misworded, if we follow that approach we require the party performing the
delegation to maintain key records.
This is a bogus requirement, it should be eliminated. What it seems to be
intended to say is not necessary to say. All things being equal people will
choose the simpler solution.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html