[dmarc-ietf] Debugging and preventing DKIM failures- suggestion

["Douglas E. Foster" <[e-mail]>]

 
  Problem
  
 DKIM verification failures are difficult to debug because the recipient 
cannot detect where the problem occurred or why.
  
 Proposed Solutions
  
 1) Identify the point of failure
  
 It would seem helpful to support a DKIM trace record that a device can use 
to indicate that it detected a DKIM failure.  I am suggesting a header of 
the form "DKIM-InputFail", followed by the contents of the signature header 
that could not be verified.  This puts an upper bound on the location of 
the problem.  (Once the failure is documented, it should not be repeated by 
downstream servers.)
  
 A downstream MTA is still free to evaluate the original signature.   For 
example, an intermediate MTA may have reported the failure incorrectly 
because of a software bug.   
  
 2) Recover from Subject header changes that break signatures.
  
 One expected cause of DKIM verification errors is Subject header 
modification, either by spam filters or by list servers.   These types of 
changes can also be mitigated by trace headers.   If a device makes a 
change to the subject, it should add headers for "Subject-AsReceived" and 
"Subject-AsSent".  Any downstream system can then reconstruct which header 
text was in place when any signature was applied, regardless of how many 
Subject header changes occur during transmission.
  
 Downstream servers would also have the option of restoring the Subject 
header to its original value.   This would be appropriate when the Subject 
was tagged by the spam filter upon arrival to an administrative domain, and 
then is auto-forwarded to a different administrative domain.   If the 
outbound MTA restores the original subject, it increases the likelihood 
that the message will be accepted downstream.  
  
 The concept could be applied to other headers.   For example, I have seen 
messages with DKIM failures because an auto-forward server replaced the 
internal Message-ID with one of its own.   I don't know if there are 
legitimate reasons for intermediate MTAs to tamper with other headers.