On 04/22/2013 11:00 PM, Murray S. Kucherawy wrote:
> On Mon, 22 Apr 2013, Jim Fenton wrote:
>>> This is the LogWhy stuff we're looking for. Was it not added for
>>> your other message? When LogWhy is enabled it should be there for
>>> all messages regardless of mode, because it's explaining the logic
>>> it's using to make the sign vs. verify decision before it makes its
>>> conclusion.
>>
>> That's right; it's not being added. Just for fun, I tried changing
>> my mail client back to port localhost:25 and here's what happened:
>
> Since you have the "MTA" setting matching, the absence of signatures
> could only be caused by an error (which should be logged), a non-match
> with the domains-to-sign list (which would also be logged), or the
> fact that signing mode is disabled.
>
> Basically, you should be seeing a lot of LogWhy data, or a signature.
> I can't say why you're not seeing one or the other. I'd have to see
> it happen inside gdb to figure out what's going on beyond here.
>
> You could try this to see if it reproduces your problem:
>
> 1) copy your config file someplace
>
> 2) change the macro name you search for in the config file to be
> "DEBUG-mta_name" (to be compatible with the test harness)
>
> 3) put a sample message that should be signed into a file, in RFC5322
> format (i.e., no leading "From " line)
>
> 4) run "opendkim -x <configfile> -v -v -v -t <messagefile>"
>
> This should result in output representing a bunch of calls to mlfi_*()
> functions and their results. If a header field is added (whether it's
> DKIM-Signature or Authentication-Results), you'll see it happen.
> You'll also see the final milter result code, which is an SMFIS_*
> constant.
Eureka!
It looks like it doesn't like signing with my 768-bit key:
root_at_kernel:/home/fenton# opendkim -x /etc/opendkim.conf -v -v -v -t
testmsg.txt
opendkim: mlfi_connect() returned SMFIS_CONTINUE
opendkim: testmsg.txt: mlfi_envfrom() returned SMFIS_CONTINUE
opendkim: testmsg.txt: mlfi_envrcpt() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 1: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 2: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 3: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 4: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 5: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 6: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 7: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 8: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 9: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: line 10: mlfi_header() returned SMFIS_CONTINUE
opendkim: testmsg.txt: mlfi_eoh() returned SMFIS_CONTINUE
opendkim: testmsg.txt: mlfi_body() returned SMFIS_CONTINUE
opendkim: testmsg.txt: mlfi_eom() returned SMFIS_CONTINUE
opendkim: testmsg.txt: no signature added: private key too small (768
bits, need at least 1024)
opendkim: mlfi_close() returned SMFIS_CONTINUE
Irony: After blogging about DKIM key lengths in 2010
(
http://blogs.cisco.com/security/key_lengths_for_dkim_signatures/)
almost three years later I discover that I'm one of "those" domains!
I think I'm all set now with my shiny new 1024 bit key. I'm still
getting some verification errors but I think that's because a few slave
name servers don't have the key record yet.
Thanks for all the help! I wonder if this "private key too small" error
needs to be syslogged a bit more loudly.
-Jim
>
> If you still don't get the expected result, then your config file and
> that message file together are what I need to try to reproduce the
> problem. (I suggest using tar+gzip to prevent any space weirdness
> from creeping in.) If you do get the epxected result, then the filter
> is telling the MTA what it's supposed to, and it's not happening for
> some reason.
>
> -MSK
Received on Wed Apr 24 2013 - 06:31:07 PST