RE: opendkim 2.5.1 crash

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Thu, 5 Apr 2012 21:15:19 +0000

> -----Original Message-----
> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-bounce_at_lists.opendkim.org] On Behalf Of ????? ????????
> Sent: Thursday, April 05, 2012 12:44 PM
> To: Murray S. Kucherawy
> Cc: opendkim-users_at_lists.opendkim.org
> Subject: Re: opendkim 2.5.1 crash
>
> I mean, when a message is submitted from the MUA to the Mail-
> Submission-Agent/MSA/MTA, the MSA is supposed to add an
> Authenication-Results: header, that indicates both the authentication
> result of the SMTP session, and verification of the submitted message
> (if it is is signed by the MUA before submission). This could be done,
> when the MTA adds an Authentication-Results header for the SMTP-
> Authentication and opendkim adds another Authentication-Results header,
> immediately near the first one, to indicate the DKIM-Verification. It
> would be more practical, if the MTA does not add Authentication-Results
> for the SMTP-Authentication, but opendkim adds a single Authentication-
> Results, accumulating both SMTP-Authentication and DKIM-Verification
> results.

It's not the function of opendkim to record authentication results from other protocols. I don't think this would be good to add here. What if some other inline filter does the same thing, for example, and those two results somehow disagree? A consumer would be confused.

If you want to do this in your own setup, the Lua scripts have the hooks for you, but I don't think we should do it natively in this package.

> I cannot send the message, which caused the problem, since I do not
> have it. Just today from time to time opendkim stops working and I
> have not figured out right now which message causes this. I sent you
> what I had and I found useful. When it happens again, I will try to
> gather more information (I run now exact opendkim-2.5.1 without any
> changes) and will let you know again. I know know such reports make
> sense, when they are reproducible, but on the other side if I could
> solve the problem myself, I would probably just have sent you a patch.

Similarly, I can't solve the problem if I can't reproduce it. Changing the assertion failure to an "if" block would alleviate the crash but would do so without understanding the problem.

If you're using sendmail, you can tell it to keep the message that causes the crash in quarantine by running your daemon with the "-d71.100" flag. Then when you see the crash, you should see the queue files preserved, renamed so the queue runner won't process them. You can capture those and send them over, and then I should be able to replay the problem.

There may be a postfix equivalent but I don't know what it is.

> Anyway, another question: In configure.ac it is assumed, that
> libunbound is in a directory, which name ends with /lib, e.g. /usr/lib
> .
> However my libunbound is only in /usr/lib64, and my /etc/config.site
> contains
>
> export lv_cv_sys_lib_search_path_spec="/lib64 /usr/lib64"
> export lv_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64"
>
> so basically these variables shall be honoured somehow when searching
> for the exact location of libunbound and -L/usr/lib shall not be added
> to the compiler parameters, just because /usr/include/unbound.h exists
> and I use ./configure --with-unbound . I personally would use
> AC_CHECK_LIB instead to determine, if libunbound is installed.

AC_CHECK_LIB only works if the library is located inside the default search rules for the compiler, which isn't always the case. We could add /usr/lib64 to the search list in a future version if you like.

-MSK
Received on Thu Apr 05 2012 - 21:15:28 PST