I'm Cc:ing [EMAIL PROTECTED] but that may be rejected as I'm not a subscriber. Feel free to forward this if needed.
On Fri, 8 Feb 2008, Daniel Black wrote: > Had some trouble deploying dkim-milter-2.4.4 on postfix-2.4.6 (debian > etch backports - tried etch 2.3.8 and had the same troubles) and > mailman_2.1.9-7. > > DKIM-milter is deployed and signing and verifing mode with its primary > intent to sign emails on lists.cacert.org mailing lists. > > Feb 7 09:27:09 lists postfix/master[22912]: daemon started -- version 2.4.6, > configuration /etc/postfix > I deployed it as a typical and sole milter > smtpd_milters = unix:extern-milter/dkim-filter.sock > non_smtpd_milters = $smtpd_milters > > Testing on a tiny email list and the email came through signed by dkim. > > Feb 7 10:28:29 an email when through to a larger email list > [EMAIL PROTECTED] without any error > > after a significant number of hours without a peep out of dkim-filter I > start to get. > > Feb 7 14:40:05 lists postfix/cleanup[15075]: F13C6108238: message-id=<[EMAIL > PROTECTED]> > Feb 7 14:40:05 lists postfix/cleanup[15075]: warning: milter > unix:extern-milter/dkim-filter.sock: can't read SMFIC_HEADER reply packet > header: Connection reset by peer > Feb 7 14:40:05 lists postfix/cleanup[15075]: F13C6108238: milter-reject: > END-OF-MESSAGE from lists.cacert.org[172.16.2.17]: 4.7.1 Service unavailable > - try again later; from=<[EMAIL PROTECTED]> to=<[EMAIL PROTECTED]> > proto=ESMTP helo=<lists.cacert.org> > Feb 7 14:40:05 lists postfix/smtpd[15071]: disconnect from > lists.cacert.org[172.16.2.17] > Feb 7 14:40:05 lists postfix/smtpd[15071]: connect from > lists.cacert.org[172.16.2.17] > Feb 7 14:40:05 lists postfix/smtpd[15071]: 05DE1108238: > client=lists.cacert.org[172.16.2.17] > Feb 7 14:40:05 lists postfix/cleanup[15075]: 05DE1108238: message-id=<[EMAIL > PROTECTED]> > Feb 7 14:40:05 lists postfix/cleanup[15075]: warning: milter > unix:extern-milter/dkim-filter.sock: can't read SMFIC_HEADER reply packet > header: Connection reset by peer > Feb 7 14:40:05 lists postfix/cleanup[15075]: 05DE1108238: milter-reject: > END-OF-MESSAGE from lists.cacert.org[172.16.2.17]: 4.7.1 Service unavailable > - try again later; from=<[EMAIL PROTECTED]> to=<[EMAIL PROTECTED]> > proto=ESMTP helo=<lists.cacert.org> Version 2.5.0 of dkim-milter is now in beta and has a configuration file option called "MilterDebug" which requests libmilter debugging be written to standard output. Higher values produce more output (of course). This might help you at least see whether or not the filter is seeing the SMFIC_HEADER message from the MTA in the first place, and what state changes it's triggering inside the filter. Unfortunately libmilter doesn't (currently) log the replies it sends, but that would be fairly simple to patch in as well so you can see those go back. I might suggest using "tcpdump" to capture packets sent between the MTA and the filter, but I'm not sure if that's possible while using UNIX domain sockets. "Connection reset by peer" is returned when a program calls read() on a socket, gets EOF, and then calls read() again, or calls write() on a socket when the far end has closed the connection. This suggests either postfix and the filter have fallen out-of-sync, the filter has crashed, or there's a bug hiding someplace. I recall though someone saying that the filter had not changed process ID, so that leaves me thinking there's a bug someplace. Unfortunately without seeing more forensics (especially a detailed walk-through of the code when the problem is happening), I'm left to guess for now. You might try the "MilterDebug" feature. It was helpful in finding a problem with libmilter earlier today that I hadn't hit before. Its output can be a little cryptic, but I can help translate if you can capture some output while you're seeing the problem. Finally, the header handling code chunks in both dkim-filter and libdkim simply make a copy of the header (or choose to ignore it) and return a status. There's no path I can find, including errors, that don't either return SMFIS_CONTINUE or SMFIS_TEMPFAIL, both of which should be returned immediately to the MTA. So give the data we have so far, I think we're looking at a problem either in libmilter or in postfix. -MSK ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
