>> >> Common examples of fields with addresses and fields with >> >> textual content related to the body are: >> >> >> >> o From >> >> -1 with the removal of the original text of: >> >> o From (REQUIRED in all signatures) >> >> The 5322.From header is a fundamental binding requirement in DKIM >> signatures. > > It is redundant to the first sentence in the text of Section 6.4 which already > says From MUST be signed; there's no reason to repeat it here, especially > since this section is clearly advisory in nature only, and thus there's no > harm in removing it.
Perhaps, but I agree that it would be useful to remind people. Why not leave it there, with a reference to the normative statement? >> > I'd actually like to add Authentication-Results because an agent >> > that wishes to claim that observed authentication meta-data should >> > become part of the message core certainly should sign such a field, >> > but that's not worth recycling at Proposed and basically RFC5451 >> > already says that anyway. ... > The issue is that adding things to DKIM now will prevent its progress toward > Draft Standard, which is something we're trying to avoid. Removing things, on > the other hand, doesn't introduce any backward compatibility issues, and so > that's allowed. I don't think so. This section is not normative -- we've already *removed* the SHOULD in it, and that's the removal. After that, anything we add is an idle suggestion, and doesn't affect conformance. I think we can put anything we want in here, informatively. We can even be general -- that is, we can say "Authentication-Results [tm]", or we can say, "any header field that conveys authentication results," or some such. Barry, as participant _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
