>Is this the stock OpenSSL for your system, or your own build?
There's just one OpenSSL library installed on the system, the stock
version supplied by the OS's package manager.
$ ldd | grep ssl
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1
(0x7f13e45fe000)
$ strings
On Wed, May 13, 2020 at 10:01:24PM -0700, Alexander Vasarab wrote:
> May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil),
> rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(36) = 0
> May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success
> May 13
On 13/05/20 20:40 -0400, Viktor Dukhovni wrote:
Your OpenSSL library looks busted. Do you have more than one set of
OpenSSL libraries installed on your system? What ldd report for the
"smtpd" executable?
Is this the stock OpenSSL for your system, or your own build?
There's just one OpenSSL
On 07.05.20 12:26, Matus UHLAR - fantomas wrote:
>I ust received mail where user specified destination address:
>@example@example.com
>
>the mail was accepted and forwarded to "empty_address_recipient",
>
>which docs' say:
>
>"...Postfix does not accept such addresses in SMTP commands..."
On 13/05/20 16:20 -0400, Viktor Dukhovni wrote:
Try the below. Note, if build as below, it will not replace your system
The output is attached.
Alexander
May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: connect from []
May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio:
On Wed, May 13, 2020 at 04:37:29PM -0700, Alexander Vasarab wrote:
> On 13/05/20 16:20 -0400, Viktor Dukhovni wrote:
> >Try the below. Note, if build as below, it will not replace your system
>
> The output is attached.
I pushed one more commit on the tsl-debug branch, that shows the address
of
[ Kurt, I don't know whether you've been following this thread, but the
OP's system is exhibiting rather unexpected TLS session termination
with "out of the blue" SSL_R_SHUTDOWN_WHILE_IN_INIT errors, even though
I see no opportunity for Postfix to attempt to tear down the session,
indeed
On Wed, May 13, 2020 at 04:37:29PM -0700, Alexander Vasarab wrote:
> The output is attached.
>
> May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio:
> SSL_get_error(-1) = 2
> May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for
> readable socket
> May 13 16:31:24
On Wed, May 13, 2020 at 03:42:47PM -0500, Thomas Strike wrote:
> Postfix is trying to access the aliases table in the postfix db with a
> wrong file name and directory. I thought I had this fixed yesterday but
> it is showing up again today.
> I changed the property,
>
> alias_maps =
Thomas Strike:
> Postfix is trying to access the aliases table in the postfix db with a
> wrong file name and directory. I thought I had this fixed yesterday but
> it is showing up again today. I changed the property, alias_maps =
> /etc/postfix/mysql-aliases.cf to
>
Postfix is trying to access the aliases table in the postfix db with a
wrong file name and directory. I thought I had this fixed yesterday but
it is showing up again today. I changed the property, alias_maps =
/etc/postfix/mysql-aliases.cf to
mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf,
On Wed, May 13, 2020 at 12:05:24PM -0700, Alexander Vasarab wrote:
> On 13/05/20 13:56 -0400, Viktor Dukhovni wrote:
> >If you're willing to rebuild Postfix from source, then I can provide
> >a patch that would log more details.
>
> Yes, absolutely willing. Thank you.
Try the below. Note, if
On 13/05/20 00:34 -0400, Viktor Dukhovni wrote:
an SSL_ERROR_WANT_READ. You need to try an updated OpenSSL.
Thanks for your insights. I'm trying new things to try to improve my
understanding of the issue.
I juggled around some versions. Bumped to libssl 1.1.1g, restarted
postfix, problem
On 13/05/20 13:56 -0400, Viktor Dukhovni wrote:
If you're willing to rebuild Postfix from source, then I can provide
a patch that would log more details.
Yes, absolutely willing. Thank you.
Alexander
On Wed, May 13, 2020 at 08:45:49AM -0700, Alexander Vasarab wrote:
> On 13/05/20 00:34 -0400, Viktor Dukhovni wrote:
> >an SSL_ERROR_WANT_READ. You need to try an updated OpenSSL.
>
> Thanks for your insights. I'm trying new things to try to improve my
> understanding of the issue.
>
> I
Gerard E. Seibert:
> I am considering running 'mlmmj' on my FreeBSD system. There is a
> document that shows how to configure Postfix with 'mlmmj' available.
> http://mlmmj.org/docs/readme-postfix/ That document is dated 1/28/2012.
> I tend to think it is outdated.
It uses stable Postfix
On 2020-05-13 19:09, Gerard E. Seibert wrote:
Does anyone here use this application and have any suggestions on how
to
configure it and/or Postfix to work happily together?
its dokumented imho on that page how to make it work
I am considering running 'mlmmj' on my FreeBSD system. There is a
document that shows how to configure Postfix with 'mlmmj' available.
http://mlmmj.org/docs/readme-postfix/ That document is dated 1/28/2012.
I tend to think it is outdated.
Does anyone here use this application and have any
One example of 'stateful' behavior is the way that modern operating
systems cache file data in memory. If a bit goes bad in userland,
then that may persist across executions by different processes that
get their code and initial data from the same file, until the memory
page is reloaded from the
Linkcheck:
> May 13 12:16:25 BRISTOLWEB postfix/submission/smtpd[12960]: warning: TLS
> library problem: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
> failed or bad record mac:s3_pkt.c:532:
Choose one or more.
1: broken TCP or broken proxy.
The TCP content was modified in
Matus UHLAR - fantomas:
> Hello,
>
> Any idea if I can disable these attempts?
>
>
> On 07.05.20 12:26, Matus UHLAR - fantomas wrote:
> >I ust received mail where user specified destination address:
> >@example@example.com
> >
> >the mail was accepted and forwarded to
Tobi:
> Hi
>
> as usual: thanks to Wietse :-)
>
> Adding the info rule to the pcre maps solved more than expected. After
> adding the info rule postfix cleanup did not segfault anymore and the
> mail could be accepted --> we have the source now.
> From what I see that is a massively oversized
I have had a few complaints about emails bouncing over the past
week-ish, specifically from a single dynamic IP. Have now found a few
lines in the logs that seem to indicate the problem. Nothing has been
changed (that I know of) apart from a point or two of the Ubuntu
version, so why is there
Hello,
Any idea if I can disable these attempts?
On 07.05.20 12:26, Matus UHLAR - fantomas wrote:
I ust received mail where user specified destination address:
@example@example.com
the mail was accepted and forwarded to "empty_address_recipient",
which docs' say:
"...Postfix does not
Dnia 13.05.2020 o godz. 07:54:34 Tobi pisze:
> My 5 cents: never rely on the reputation of a domain if you do not have
> control over parent domain. So if others from eu.org zone sending spam
> one should not wonder why the own subdomain of eu.org might be
> listed/blocked/seen as spam.
That's
Zitat von "@lbutlr" :
On 11 May 2020, at 04:24, Jaroslaw Rafa wrote:
Someone told me… that Google is more likely to classify email from
small senders as spam if they are sent via IPv6, and less likely if
they are sent via IPv4.
Short of Google publishing this information, I doubt that
On 12/05/20 05:40 -0400, Viktor Dukhovni wrote:
Indeed the server slams the TCP socket closed after receiving the
client's RCPT command. Unclear why. You might try debug_peer_list
next, to see whether the server can log enough cleartext traffic
to expose the SMTP traffic inside TLS.
On
On 12/05/20 23:27 -0400, Viktor Dukhovni wrote:
Once again out of the blue, a lost connection. The SMTP server is
trying to read the next command after sending "RCPT TO" and encounters
an EOF condition, for no apparent reason. At this point, I'd guess
your SSL library is broken...
I was able
Hi
as usual: thanks to Wietse :-)
Adding the info rule to the pcre maps solved more than expected. After
adding the info rule postfix cleanup did not segfault anymore and the
mail could be accepted --> we have the source now.
From what I see that is a massively oversized mime part header. I
29 matches
Mail list logo
