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
