This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DKIM not signing NDR from internal servers

Hi,

I have recently configured DMARC and DKIM on our XG450 Units (18.0.1 MR-1-Build396), currently no policy is being applied while I monitor results.

I have noticed most, if not all, of the responses to failure reports are NDR's generated by our internal exchange servers. It appears that the XG is passing these emails without applying the DKIM signature.

Exchange has a rule configured to "reject the message and include the explanation 'User Account is disabled' with the status code: '5.7.1'"

Examining the header information of the copy of the email returned in the failure report shows other Sophos header information but no sign of DKIM, normal email sent are working as expected.

Please let me know if you require examples or any log content to identify the cause.



This thread was automatically locked due to age.
  • Just had one as a result of an Out of Office automatic reply, same result no DKIM signature. At the moment the bulk of my Failure Reports are from linkedin as most vendors don't issue them.

    I have also completed a test using gmail to send an email to a known disabled account and the NDR does return, but it is not DKIM signed.

  • Hello IT Services17,

    Thank you for contacting the Sophos Community!

    Did you update the TXT record on the DNS server? 

    You should be able to find information about the email under the /log/smtpd_main.log

    You might need to put it in debug mode 

    service smtpd:debug -ds nosync

    Regards,

  • Thanks for the reply, yes all DNS TXT records are updated and working, as mentioned above all my standard emails are being signed as expected, it is just NDRs and Out of Office responses generated by the internal exchange system that seem to pass through the sophos without DKIM signing.

    I'll see if I can get some results with debug logging enabled.

  • Hi,

    Could you advise some syntax to look for, even with debug enabled I can only see DKIM lookups for external emails, I can't see any signing taking place in smtpd_main.log for working or non working emails.

    Thanks,

    Beau

  • Hello IT Services17,

    I don't have a syntax, other than you could try to grep for DKIM for an email that works and one that doesn't. 

    I thought none of the emails were working when I first read, then after reading the second time and you pointing it out, realized only are the NDR, would it be possible for you, to send my via PM, one of the NDRs and the smtpd_main.log in debug mode.

    I would expect all emails would be signed regardless of type, however, NDRs are a bit different. 

    Regards,

  • I have the same problem. I think the reason is that NDR and OOF are delivered by exchange without a sender so that sophos xg (exim) is not able to apply the DKIM-Signing. 

    However, I does not know how to solve it...

    We already are listed to the backscatter blacklist because of that issue.

  • Having a blank sender on a NDR is a requirement of RFC 2821, section 3.7, so I don't think this should be "fixed", I am still waiting on a response to my Support Case.

  • DKIM on the XG is pretty buggy still. You'll get DKIM verification problems on inbound e-mail where there are multiple DKIM signatures for example.

    I've found it easier to turn off DKIM on the XG and use dkim-exchange on the Exchange Server.

    If you do want DKIM signing for everything else except the Exchange Server, create a rule prior to the auto-created rule that scans SMTP/SMTPS and have this new rule configured for the Exchange Server as a source and SMTP/SMTPS for the destination protocol and to not scan SMTP/SMTPS.

  • Thanks for the tips, I haven't even got to the step of enabling DKIM Verification, I was just looking to clean up all outgoing sources first, so I am just monitoring outgoing email at the moment. The bulk, if not all our email is exchange generated so it sounds like that might be our best course of action.

  • Hello,

    This case got to development and is being currently investigated under NC-66068

    Regards,