Barry Leiba wrote:
Who is responsible for dealing with this situation? If the DKIM spec
is at least partially responsible, to what extent, and what should it
say?
Whether we have the guts to do what is correct as oppose of trying to
"work it in" due to IETF meeting mile stones and time deadlines, is
entirely different issue.
IMO, DKIM is responsible for the input that are part of is formula.
Parts it MUST make sure are RFC5322 correct for consumption with its
"purported trust" signature, especially its sole single input header
requirement, 5322.From.
Proposal:
1. The DKIM spec is responsible for describing the problem in terms of
how it relates to signed and unsigned versions of the fields. That's
the stuff in 8.14.
Who's version?
2. The DKIM spec should probably say that signers need to sign valid
messages, and, therefore, SHOULD NOT sign things like this. Text
along the line of this might work well:
"Signers SHOULD take reasonable steps to ensure
that the messages they're signing are valid according to [RFC 5322,
etc]." Leaving the definition of "reasonable" out allows flexibility. It
may be waffly, but I like the approach in this case.
+1
3. It'd be reasonable for the DKIM spec to remind verifiers that
signers aren't supposed to sign stuff like this, so they might
consider that when deciding what to do with it after verification.
It'd be reasonable to remind them of this particular case. But
I think that all ought to be informative text.
+1
4. We should agree to this or some variant of it, and then move on.
This is not meant to satisfy everyone. In fact, it isn't what I'd prefer,
if I had my full choice. But it takes care of the problem in a way
that I think is sufficient, and allows us to resolve the issue.
+1
I believe I provided good text with the original ISSUE posting I made
and also modifications along the threads. This focus mainly with
following up with the logic for the "last header" begins in Section
5.4 and where the corrective text should be made. Its a "do this
...., but keep in mind that ...." semantic.
Overall I prefer to see an updated specification that will help
developers write software consider options to deal with this
correctness issue directly and independently from another protocol
logic. IMO, this is the proper Software Engineering approach to
maximize a fix across all MTA of all kinds. I prefer not to read
text that tries to pass the buck, push the burden on to MTAs or MUAs
solely. That will minimize the adoption rate because they could be
legitimate MTAs that are not capable to satisfy the "outside RFC5322
correctness requirement or mandate" in order for DKIM to provide
workable results.
At the end of the day, I believe that it is major goal to get ALL DKIM
software to work with the same expectation here and not get into
situations in the future where there are deviations. It MUST become a
mandate in order to build the initial trust required for DKIM.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html