Hi, The code did not change, but there is a configuration method: Can you try adjusting your sendmail.cf to have: ServerSSLOptions -SSL_OP_ALL ClientSSLOptions -SSL_OP_ALL This will disable all default work around options including the PADDING one. (Currently cannot test this, my last sendmail installation is long gone ;) Ciao, Marcus On Thu, Mar 26, 2015 at 09:23:43AM -0700, Linda Walsh wrote:
Marcus Meissner wrote:
Hi Linda,
I was mostly wondering what mailserver program and openssl version you use.
I am now assuming sendmail and whatever we released as openssl online updates for 13.1/13.2.
The problem described is real, and related to the SSL PADDING extensions that was introduced in 1.0.1g. :(
So why would I only get it with (well, that I notice) with one receiver (almost any email going to 'dell.com').
Since I haven't upgraded my sendmail program yet, I'm guessing it has to do with my updating openssl to the current 13.2 version (aka openssl-1.0.1i-2.1.4.x86_64)?
Is there a bug already filed on that (I'd assume? -- don't want to create a 'dup'). What bothered me a bit is that my sendmail automatically started using the "new and improved, faulty transport.
I.e. to me, it seems a bit 'buggy' that sendmail would automatically start using whatever new transport layer is installed -- for exactly situations like this -- where, the new transport layer isn't quite "ready" to be a drop-in replacement....
Any idea how I turn off an auto-upgrade feature like that in sendmail?
BTW -- I don't _exactly_ have the latest online updates installed, I tend to download a copy of the repos, then update local "interdependent" chunks at one time.
I have gotten into too much trouble going for auto-installed updates because I couldn't keep up with all that was changed and couldn't figure out if I broke something or if some new update was causing the problem.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org