ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Getting resolution on the "double header" issue

2010-11-08 08:55:24
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