Re: dkim-filter and milter problem

> Good day all, I have been trying to test signing messages with DKIM and
> libmilter. So far have had little luck. From the debug log below I see
> the mta interacting with the milter daemon but messages are not being
> signed. I am sure I'm missing something obvious. Technical and debug
> info below...

> For the milter s/w I am using dkim-milter-2.3.2. Running on a different
> host with the following args: -l -p inet:8076 -d monkor.us -s
> monkor.localhost -k /var/opt/monkor.us.private -v

> Those logs provide no real info...

No, unfortunately the dkim-milter doesn't seem to give very good diagnostic
output.

> Oct 27 16:27:35 monkor dkim-filter[29673]: 0JQL00G0L89XIA00 external
> host monkor.localhost attempted to send as monkor.us
> Oct 27 16:34:17 monkor dkim-filter[29673]: 0JQL00G028L4K500 external
> host monkor.localhost attempted to send as monkor.us
> Oct 27 16:42:15 monkor dkim-filter[29673]: 0JQL00G078YDK500 external
> host monkor attempted to send as monkor.us
> Oct 27 16:43:09 monkor dkim-filter[29673]: 0JQL00G0A8ZVK500 external
> host monkor attempted to send as monkor.us

That said, this doesn't look right. I think something is going wrong with host
selection here. Looking at my own options, I have a "-S host" in there. Perhaps
a "-S monkor" would help? I also have a "-b s" to force it into signing mode,
but perhaps signing is enabled by default and you don't need that.

> bash-2.05# imsimta version
> Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug  3 2007; 32bit)
> libimta.so 6.3-4.01 (built 17:13:29, Aug  3 2007; 32bit)
> SunOS homer 5.9 Generic_112233-03 sun4u sparc SUNW,Ultra-2

> option.dat settings
> spamfilter2_library=/opt/SUNWmsgsr/lib/libmilter.so
> spamfilter2_config_file=/opt/SUNWmsgsr/config/milter.opt
> spamfilter2_string_action=data:,$M

> bash-2.05# more milter.opt
> HOST=192.168.0.2
> PORT=8076
> DEBUG=2

> imta.cnf opt-in setting

> !
> ! tcp_intranet
> tcp_intranet smtp mx single_sys subdirs 20 dequeue_removeroute maxjobs 2
> pool SMTP_POOL maytlsserver allowswitchchannel saslswitchchanne
> l tcp_auth missingrecipientpolicy 4 sourcespamfilter2optin spam
> tcp_intranet-daemon

> I have tried applying the same to tcp_local with the same lack of
> success. Is it possible the sourcespamfilterXoptin setting requires a
> different keyword?

I'm afraif this has nothing to do with your MTA milter settings. According to
your logs, the milter is activating and getting all the data it is supposed to.
However, once it gets to the end of the message it then says:

> 16:59:56.02: Milter plugin end body called
> 16:59:56.02: Sending Milter server the BODYEOB command length 1
> 16:59:56.02: send_milter_command: [10] sent 5 bytes
>       > 00000001 45                          ....E
> 16:59:56.02:   Checking size limits.
> 16:59:56.02:     Rough message size is 1
> 16:59:56.02:   Message size is OK
> 16:59:56.02: Milter plugin end message called
> 16:59:56.03: read_milter_response: [10] received 5 bytes
>       < 00000001 61                          ....a
> 16:59:56.03: Received milter response 'a'
> 16:59:56.03:   Accepting message without further processing
> 16:59:56.03:   Closing connection after accept
> 16:59:56.03: Sending Milter server the QUIT command length 1
> 16:59:56.03: send_milter_command: [10] sent 5 bytes
>       > 00000001 51                          ....Q

Had it generated a DKIM header you would have seen that here. It elected not
to and the reason for that has to lie in the dkim-milter's own settings.

                                Ned