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

[Дилян Палаузов <[e-mail]>]

Hello Douglas,

1) Check the Authentication-Results header. An implementation could put there additional information as comment. A downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt trust the previous hop. Common case: aliases to random servers.

2) Check ARC, https://tools.ietf.org/wg/dmarc/ .

3) To fix the origin of a bad dkim signature problem the sender has to be notified about the inconsistencies so that the sender can take actions and correct the signing process, asuming the problem is not on verifier’s side. Propagating and logging the mismatched signature does not help correcting the source of the problem.

Part of the DKIM magic is the volume of papers one has to read in order to understand it, and fix whenever something goes wrong. Here come other email protocols: submit, mta-sts, dane for smtp, dmarc, https://starttls-everywhere.org/, wrong certificate purpose … and you end having very few people being able to understand and correct a problem, even when all the necessary informarion can be extracted from logs or error reports. If you cannot run different dkim verifiers towards a single dkim-signature with corresponding message, and if the sender repeatedly does not answer on emails, no further normative text helps you.

By the way, why writing you directly earlier today I got as reply '“reason: 550 Sender IP reverse lookup rejected”?

Regards
  Дилян

On May 26, 2019 3:22:25 PM GMT+03:00, "Douglas E. Foster" <[e-mail]> wrote:
> 
>  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.
>  
>  
>
>