I have a filter running at a large shop that is configured for signing only (via "Mode s" in opendkim.conf) and uses a SigningTable and KeyTable.
Until recently, this job was done by another open-source package that's no longer supported. While monitoring logs after cutting over to our OpenDKIM configuration, I noticed messages like this in my mail log with the "opendkim" process:
can't determine message sender; accepting
They're accompanied by Sendmail messages like this:
These messages are either lacking a From header entirely or are using an address that doesn't match our SigningTable. Nonetheless, I was surprised to see us inserting Authentication-Results header when we have Mode set to "s" only. (I did confirm by checking a received message that they're legitimately being inserted.)
I would think that no A-R headers would be inserted when the mode is "s" only.
I believe the problem is the block from lines 11636-11650 of opendkim.c (in mlfi_eoh()); this checks the length of addr and, if it's 0, sets mctx_status to DKIMF_STATUS_BADFORMAT and addheader/headeronly to TRUE without any further checks of the filter configuration.
It may be that there are people who desire this behavior for identifying problematic messages; if that's the case, maybe a config option could be added to toggle the insertion of this header (or another, more appropriate x-header). I'm happy to submit a PR implementing such a solution, but I think the change to that block of mlfi_eoh() is probably just a couple of lines, so it's probably not that helpful until someone decides if there should be a config option and how it should work.
I have a filter running at a large shop that is configured for signing only (via "Mode s" in opendkim.conf) and uses a SigningTable and KeyTable.
Until recently, this job was done by another open-source package that's no longer supported. While monitoring logs after cutting over to our OpenDKIM configuration, I noticed messages like this in my mail log with the "opendkim" process:
They're accompanied by Sendmail messages like this:
These messages are either lacking a From header entirely or are using an address that doesn't match our SigningTable. Nonetheless, I was surprised to see us inserting Authentication-Results header when we have Mode set to "s" only. (I did confirm by checking a received message that they're legitimately being inserted.)
I would think that no A-R headers would be inserted when the mode is "s" only.
I believe the problem is the block from lines 11636-11650 of opendkim.c (in mlfi_eoh()); this checks the length of addr and, if it's 0, sets mctx_status to DKIMF_STATUS_BADFORMAT and addheader/headeronly to TRUE without any further checks of the filter configuration.
It may be that there are people who desire this behavior for identifying problematic messages; if that's the case, maybe a config option could be added to toggle the insertion of this header (or another, more appropriate x-header). I'm happy to submit a PR implementing such a solution, but I think the change to that block of mlfi_eoh() is probably just a couple of lines, so it's probably not that helpful until someone decides if there should be a config option and how it should work.