I don't have a legalistic definition of interoperability; I want
implementations to, you know, interoperate. When I sign and send a
message, it'd be nice if I could expect recipients to interpret the
signature consistently. If assessors are likely to do inconsistent
things with parts of the signature, if I want my mail to work, I'd better
avoid those parts.
So you are indeed trying to make predictions or assertions about assessors.
I don't think that's possible in any context.
Then we're screwed, since it'll be impossible to do anything at all that
makes it more likely to get your mail delivered.
Your point about some assessors requring a signed subject is a good
example. It tells me that 4871 section 5.4 is underspecified, and
4871bis should strengthen it to say that you MUST sign the headers that
every message is supposed to have.
Subject: isn't a mandatory header per RFC5322, if you're using that as a
specific example.
Remember that a header doesn't have to be present to be signed. It'd be an
egregious spamability hole to let people add signatures and replay without
breaking the signature.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html