On 09.05.2014 18:44, Andreas Schulze wrote:
> Viktor Dukhovni:
>> It may be simpler to upgrade your system.
> yes, upgrade would be best but sometimes,
> older crypto is not as painfull as it should be
Although older crypto saves you from heartbleeds. I think there are some
good reasons (not that
On Sun, May 11, 2014 at 10:53:05PM -0500, Larry Stone wrote:
> Viktor, thanks, that greatly improves my understanding of how
> those options work. And also serves as a reminder not to put to
> much trust in other people's "how to" documents since if I now
> understand it correctly, the '-I/usr/inc
On May 11, 2014, at 9:04 PM, Viktor Dukhovni wrote:
> On Sun, May 11, 2014 at 08:57:29PM -0500, Larry Stone wrote:
>
>>> The above syntax is incorrect. Try
>>>
>>> ... CCARGS='
>>> -DUSE_TLS -I/usr/local/ssl/include
>>> -DUSE_SASL_AUTH
>>> -DDEF_COMMAND_DIR=\"/usr/local/sbin\"
>>
On Sun, May 11, 2014 at 08:57:29PM -0500, Larry Stone wrote:
> > The above syntax is incorrect. Try
> >
> > ... CCARGS='
> > -DUSE_TLS -I/usr/local/ssl/include
> > -DUSE_SASL_AUTH
> > -DDEF_COMMAND_DIR=\"/usr/local/sbin\"
> > -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"
> > -
On May 11, 2014, at 6:34 PM, Viktor Dukhovni wrote:
> On Sun, May 11, 2014 at 06:00:38PM -0500, Larry Stone wrote:
>
>> On the test system, trying to force the new version of OpenSSL (1.0.1g), I
>> used:
>> make -f Makefile.init makefiles \
>> CCARGS='-DUSE_TLS /usr/local/ssl/include/opens
On Sun, May 11, 2014 at 06:00:38PM -0500, Larry Stone wrote:
> On the test system, trying to force the new version of OpenSSL (1.0.1g), I
> used:
> make -f Makefile.init makefiles \
> CCARGS='-DUSE_TLS /usr/local/ssl/include/openssl \
> -DUSE_SASL_AUTH \
> -DDEF_COMMAND_DIR=\"/usr/
This thread got my intrigued as I have my system (OS X “Client” doing lots of
server stuff) almost entirely independent of Apple provided stuff in favor of
building from source. OpenSSL is one I have not done. So I decided to try it on
my test system (which is really my laptop booted from an alt
Viktor Dukhovni:
> It may be simpler to upgrade your system.
yes, upgrade would be best but sometimes,
older crypto is not as painfull as it should be
Andreas
On Fri, May 09, 2014 at 10:58:30AM -0400, Wietse Venema wrote:
> > Any hint's to build postfix + openssl-1.x on a system based on
> > openssl-0.9.x ??? I also avoided building openssl from source for
> > good reasons over the last years.
It is rather easy to build on Unix-like systems.
Unpack t
Andreas Schulze:
> Robert Schetterer:
> > > openssl 0.9.8j and Postfix 2.11.1.
> > maybe a suboptimal mixture
>
> any hint's to build postfix + openssl-1.x on a system based on
> openssl-0.9.x ??? I also avoided building openssl from source for
> good reasons over the last years.
>
> But I'm open
Robert Schetterer:
> > openssl 0.9.8j and Postfix 2.11.1.
> maybe a suboptimal mixture
any hint's to build postfix + openssl-1.x on a system based on openssl-0.9.x ???
I also avoided building openssl from source for good reasons over the last
years.
But I'm open to try.
Andreas
Am 08.05.2014 22:45, schrieb Markus Petri:
> openssl 0.9.8j and Postfix 2.11.1.
maybe a suboptimal mixture
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 1992
On Thu, May 08, 2014 at 10:45:28PM +0200, Markus Petri wrote:
> I'm trying to get client side TLSA/DANE working on a SLES11 SP3 system
> with openssl 0.9.8j and Postfix 2.11.1.
You need at least OpenSSL 1.0.0.
> When the smtp client tries to connect to the destination system, the
> following is
Hi,
I'm trying to get client side TLSA/DANE working on a SLES11 SP3 system
with openssl 0.9.8j and Postfix 2.11.1.
When the smtp client tries to connect to the destination system, the
following is logged:
May 8 22:23:11 mail postfix-rz-out/smtp[22203]: warning: cannot generate TA
certificates,
14 matches
Mail list logo
