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
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 12.05.
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 a
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 exa
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 ac
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 a
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 mim
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 "empty_address_recipien
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 trans
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 fi
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 suggesti
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
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 interface
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 juggle
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 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 pers
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 bu
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,
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
> mysql:/etc/postfix/sql/mysq
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 = /etc/postf
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
[ 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 Po
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
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: SSL_get_
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..."
>htt
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 l
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 21:56:38
>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 /us
Hi Wietse
using your suggestion with valgrind I found that the main-stacksize
seems to be the problem. By using --main-stacksize with different values
I found that the last working value is 59449345, changing to ...344 let
postmap segfault:
> valgrind -s --main-stacksize=59449344 --tool=memcheck
On Thu, May 14, 2020 at 07:48:27AM +0200, Matus UHLAR - fantomas wrote:
> Can't that be kind of sender verification where the SMTP client doesn't
> cleanly close TLS connection?
>
> shouldn't we focus on failed client connections? [No we should not]
Would I be wasting my time and the OP's chasi
30 matches
Mail list logo
