On Jun 2, 2009, at 3:16 PM, John Levine wrote:
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.
The concern being raised is in regard to message annotation. As Mike
indicated, this parameter can be used can suppress false indications
of invalid signatures. The alternative of not having the l= feature
results in MORE false indications of invalid signatures. As such,
removal of the feature is not justified by an effort seeking to
improve interoperability!
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.
This advise belongs in a BCP document and not in a document intended
to define the general application of a signature. Again, this is not
about interoperability. This is more about how messages might be
better annotated. Unsigned headers or message portions should either
not be visible, or should be highlighted in a manner that indicates
they were added after the signature or perhaps not signed. In some
cases, the separate annotation of appended notifications can better
preserve the initial message's format. Our company adds their legal
foo at the end of every received message, without checking DKIM
signatures. In this case, only after forwarding, can these DKIM
signatures be checked. This is not much different from the mailing
list issue that Mike confronts.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html