Alessandro Vesely wrote:
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. Enforcing some RFC conformance is a task that many MTAs can
(optionally) do natively.
But DKIM can not make that presumption that is the prevailing nature
of "many" MTAs. At best, it can RECOMMEND that integration DKIM into
a mail system that for BEST results, a general filter would address
this issue. But it can't assume that will be possible as it might
mean a software change. Hence the better DKIM software will offer a
direct solution that COULD be turned off when the MTA is capable of
doing the filter itself.
For example, OpenDKIM is a package mainly for the Sendmail MTA. It may
have or will have a MTA milter to check for RFC 5322 compliance.
However, the I believe the software also allows has a DKIM only
component that can be used in other MTAs. You don't know if these
other MTAs will have the same kind of filter DKIM is expecting in
order to have clean results.
Now take Alt-N pure C/C++ DKIM API with no tie-ins to any MTA. It has
an non-overhead DKIM verifier option that deals this multiple
5322.From issue directly and independently from any other layered
requirement.
To me, the latter is the best approach for the specification to take.
Allow Readers of this document to decide how they will implement DKIM
based on the MTA they are using or MTAs they are targeting.
Perhaps this is an issue about MTA
configuration, rather than specifically for the signing module.
Which is just as equal of saying MTAs may or may having RFC5322
compliance checking. DKIM can not be dependent for providing valid
results only when working with MTA that have RFC5322 compliance checking.
For
example, I'm quite happy that such tweaking occurs before signing, so
that the signer signs the revised version.
Tampering with mail is not justified here. Either the mail is good
to sign or bad to sign when it comes to DKIM signing.
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.
This is again a question of roles. John has (correctly) recommended
that verifiers don't tamper with the message content, except for
possibly adding an A-R field. However, a DKIM verifier does not
/have/ to act as a verifier only. An additional role is the umbrella
under which a filter module may discard suspicious messages, suppress
unsigned singleton fields that occur more than once, or anything it
deems cool.
Generally, the caller of the DKIM procedure would act on its results.
I prefer to see a "blackbox" model for DKIM where its interface points
are well defined. Its input was well described with stated boundary
conditions and its output is well defined and described with a view on
being a feed for possible message filters/handlers.
--
Sincerely
Hector Santos
http://www.santronics.com
--
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