On Thu, May 17, 2012 at 11:05:30AM -0400, Wietse Venema wrote:
> > > Use $data_directory instead.
> >
> > That's likely not the direct cause of the problem, rather the
> > existing cache likely contains entries from different OpenSSL
> > version, and OpenSSL segfaults when one imports a cached session
> > from an older (different) OpenSSL library.
> >
> > The cache lookup keys are by transport+destination, so sending mail
> > to an address in the cache, causes an incompatible session to be
> > loaded even if it is from a different library version. So we should
> > probably add the library version to the lookup key.
>
> Something along this line should do the job:
>
> #define GEN_CACHE_ID(buf, id, len, service) \
> do { \
> buf = vstring_alloc(2 * (len) + 1 + strlen(service) + 3); \
> hex_encode(buf, (char *) (id), (len)); \
> vstring_sprintf_append(buf, "&s=%s", (service)); \
> + vstring_sprintf_append(buf, "&l=%ld", (long)
> OPENSSL_VERSION_NUMBER); \
> } while (0)
I think this is the server's cache key, the OP had issues with the
SMTP client, so we probably need to "salt" that lookup also. It
has a bunch more data in it already, related the the destination,
and various client policy settings, one more bit of fluff will not
do any harm.
This would not be necessary if users "postfix reload" when installing
binaries linked with a new library.
Perhaps the OP can confirm that the problem started immediately after
an upgrade to a new version without a restart or reload, and that the
upgrade is linked with a newer OpenSSL library.
It is thus far a working theory, likely correct, but not verified.
--
Viktor.
