Re: (Calling Kurt Roeckx, Postfix + OpenSSL on Debian buster) (was: "SSL_Shutdown:shutdown while in init" while sending and receiving)
>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 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 | grep 'OpenSSL' OpenSSL 1.1.1d 10 Sep 2019 >What OS are you running? On Wed, May 13, 2020 at 06:03:42PM -0700, Alexander Vasarab wrote: Debian GNU/Linux 10 (buster aka stable). Yesterday, I bumped libssl1.1 to the version available in the testing distribution, which is 1.1.1g, and noticed no change in the faulty behavior. Now I'm back to stable's 1.1.1d. On 13.05.20 21:32, Viktor Dukhovni wrote: At this point it becomes interesting what Debian-specific changes there may be in OpenSSL 1.1.1. Perhaps Kurt Roeckx (I believe he's on this list), might comment. The behaviour you're reporting exhibits issues below Postfix. Are any other Debian users seeing similar issues? none so far on those few debian 10 systems I checked. 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? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. We are but packets in the Internet of life (userfriendly.org)
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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 vasaconsulting postfix/smtpd[25599]: AEF2F102C03E: > client=[], sasl_method=LOGIN, > sasl_username= > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), > rfunc=(nil), wfunc=0x7f310ef37090, SSL_get_error(14) = 0 > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), > rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(-1) = 1 > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS layer error This proves Postfix attempting to call SSL_read, and had not called SSL_shutdown(), which is also only called via the tls_bio() function, and would have shown up as a non-nil (NULL pointer) value of "hsfunc". With a bit of luck Kurt might have something to say some time soon. I'm out of ideas on the Postfix side, and while I'm also an OpenSSL committer, I don't know of anything in OpenSSL that would account for the symptoms you're reporting. Somehow a call to SSL_read() is returning SSL_ERROR_SSL, with reportedly untimely calls to SSL_shutdown() on the error stack. I'f you're comfortable with gdb, and willing to build both Postfix and OpenSSL from source with debugging symbols, then you could add a "-D" flag to the "smtpd" entry in the /opt/postfix/etc/master.cf file, and attach to a "screen" running a debugger on smtpd, setting a breakpoint in SSL_shutdown, and continue. Then report a stack trace... http://www.postfix.org/DEBUG_README.html#screen I can't expect you're that curious, but if you are, go for it. This is rather a weird case. You may be able to install the debian debug symbol package for at least OpenSSL, saving the hassle of building the package yourself. Don't know whether there is also a debug symbol package for Postfix. > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: warning: TLS library > problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in > init:../ssl/ssl_lib.c:2086: > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: lost connection after > RCPT from [] This set of symptoms is not consistent with the expected behaviour of any version OpenSSL I've come across. All the evidence so far looks quite exculpatory for Postfix. Leaving a possibly mispatched OpenSSL, or flakey hardware as potential suspects. -- Viktor.
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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 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 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 | grep 'OpenSSL' OpenSSL 1.1.1d 10 Sep 2019 What OS are you running? Debian GNU/Linux 10 (buster aka stable). Yesterday, I bumped libssl1.1 to the version available in the testing distribution, which is 1.1.1g, and noticed no change in the faulty behavior. Now I'm back to stable's 1.1.1d. Alexander
Re: null recipient "@example.com"@example.com accepted
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..." >http://www.postfix.org/postconf.5.html#empty_address_recipient On 13.05.20 10:14, Wietse Venema wrote: There was a malformed recipient that looked like "@some-local-domain"@some-local-damain See http://www.postfix.org/postconf.5.html#resolve_dequoted_address for why Postfix looks inside the quotes and tries to deliver to ""@some-local-domain. shouldn't this address be treated as empty and therefore rejected? at least when resolve_dequoted_address is set to yes (default) With empty_address_recipient=no, Postfix would reject the address with "unknown user", because there is no user named "@some-local-domain". isn't empty_address_recipient supposed to be the recipient, so empty_address_recipient=no just set it to local "no" user? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fucking windows! Bring Bill Gates! (Southpark the movie)
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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_error(-1) = 2 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for readable socket 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 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(1) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: Anonymous TLS connection established from []: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) 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 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(25) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(184) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success 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 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(12) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(18) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success 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 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(42) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(18) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success 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 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(22) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(37) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success 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 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(42) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(14) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success 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 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(36) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: C6917102C03E: client=[], sasl_method=LOGIN, sasl_username= May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(14) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 1 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS layer error May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: warning: TLS library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:../ssl/ssl_lib.c:2086: May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: lost connection after RCPT from [] May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: disconnect from [] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 commands=6
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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 the SSL function wrapped by tls_bio(). Just in case for some reason we're in fact unexpectedly passing SSL_shutdown() via "hsfunc". Please rebuild, and post another similar set of logs. -- Viktor.
Re: (Calling Kurt Roeckx, Postfix + OpenSSL on Debian buster) (was: "SSL_Shutdown:shutdown while in init" while sending and receiving)
[ 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 Postfix is trying to read the next command after "RCPT TO", so as far as the SMTP server was concerned the session was live when the error was unexpectedly reported. http://postfix.1071664.n5.nabble.com/quot-SSL-Shutdown-shutdown-while-in-init-quot-while-sending-and-receiving-td105822.html ] On Wed, May 13, 2020 at 06:03:42PM -0700, Alexander Vasarab wrote: > >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 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 | grep 'OpenSSL' > OpenSSL 1.1.1d 10 Sep 2019 > > >What OS are you running? > > Debian GNU/Linux 10 (buster aka stable). > > Yesterday, I bumped libssl1.1 to the version available in the testing > distribution, which is 1.1.1g, and noticed no change in the faulty > behavior. Now I'm back to stable's 1.1.1d. At this point it becomes interesting what Debian-specific changes there may be in OpenSSL 1.1.1. Perhaps Kurt Roeckx (I believe he's on this list), might comment. The behaviour you're reporting exhibits issues below Postfix. Are any other Debian users seeing similar issues? -- Viktor.
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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 vasaconsulting postfix/smtpd[14216]: tls_bio: > SSL_get_error(36) = 0 > May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success Finished reading "RCPT TO:<>\r\n" (36 bytes). > May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: C6917102C03E: > client=[], sasl_method=LOGIN, > sasl_username= Logged queue file creation. > May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: > SSL_get_error(14) = 0 > May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success Wrote a 14-byte response. > May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: > SSL_get_error(-1) = 1 > May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS layer error Went back to read more data, but got SSL_ERROR_SSL, with the error stack holding: > May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: warning: TLS library > problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in > init:../ssl/ssl_lib.c:2086: WTF? Postfix did not yet have any opportunity to call SSL_shutdown() (that should show up in the bio trace). Postfix calls ERR_clear_error() just before each new handshake, so we should not see spurious messages left over from previous sessions. 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? OpenSSL 1.1.1g on my FreeBSD system does not exhibit such symptoms. What OS are you running? -- Viktor.
Re: Postfix is trying to access the aliases table in my db with a wrong file name and directory. t.s.
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/postfix/mysql-aliases.cf Yes, that needs a table type prefix. > to: > > mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, This fails the sniff test, the lookup keys in virtual alias tables are fully-qualified (user@domain) and the RHS values support only lists of addresses, while "alias_maps" has bare keys (user) and supports a different RHS syntax with ":include:/path", "|command", ... So I would not expect virtual alias tables to be appropriate as alias tables. What problem are you actually trying to solve? > May 12 07:50:57 sleepyvalley postfix/smtps/smtpd[9495]: error: open > /etc/postfix/mysql-aliases.cf: No such file or directory Look in the output of "postconf -n" and "postconf -M". -- VIktor.
Re: Postfix is trying to access the aliases table in my db with a wrong file name and directory. t.s.
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/mysql_virtual_alias_maps.cf, the actual access > file to my aliases table. I searched the main.cf and master.cf files and > that file and directory is no longer there. What could be possibly > trying to use the wrong file? Perhaps because something changed the file? Look at the file last status change time. Perhaps that will provide a clue. ls -lc main.cf For the sake of sanity, Postfix does not spontaneously change its config files. There is only program, postconf, and that program makes changes only on request. Wietse
Postfix is trying to access the aliases table in my db with a wrong file name and directory. t.s.
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, the actual access file to my aliases table. I searched the main.cf and master.cf files and that file and directory is no longer there. What could be possibly trying to use the wrong file? May 12 07:50:57 sleepyvalley postfix/smtps/smtpd[9495]: error: open /etc/postfix/mysql-aliases.cf: No such file or directory Tom S.
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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 build as below, it will not replace your system Postfix, all the installation paths (including the queue directory) will be under /opt/postfix, you can then update /opt/postfix/etc/master.cf to spin up an SMTP listener on just a non-conflicting port (comment out port 25) and run both the system Postfix for real mail, and this one for testing: : Adjust CCARGS and AUXLIBS as needed $ git clone -b tls-debug https://github.com/vdukhovni/postfix.git $ cd postfix/postfix $ make -f Makefile.init \ 'CCARGS=-DUSE_TLS -DHAS_PCRE -DHAS_CDB' \ 'AUXLIBS= -lssl -lcrypto -ldb' \ 'AUXLIBS_PCRE=-lpcre' \ 'AUXLIBS_CDB=-lcdb' \ 'dynamicmaps=yes' \ command_directory=/opt/postfix/sbin \ config_directory=/opt/postfix/etc \ daemon_directory=/opt/postfix/libexec \ data_directory=/opt/postfix/data\ mailq_path=/opt/postfix/sbin/mailq \ newaliases_path=/opt/postfix/sbin/newaliases\ queue_directory=/opt/postfix/spool \ sendmail_path=/opt/postfix/sbin/sendmail\ shlib_directory=/opt/postfix/lib/MAIL_VERSION \ html_directory=/opt/postfix/html\ manpage_directory=/opt/postfix/man \ readme_directory=/opt/postfix/readme\ makefiles $ make $ su # PATH=/opt/postfix/sbin:$PATH # make upgrade # postconf -MX smtp/inet # postconf -e 'smtpd_tls_loglevel = summary,io' -e 'smtpd_tls_security_level = may' ... add submission clone service on some new port ... in /opt/postfix/etc/master.cf ... configure certificates, etc. # postfix start Don't confuse the two Postfix installations, make sure your PATH is set correctly to list /opt/postfix/sbin first if and only if managing the debug install in /opt/postfix. -- Viktor.
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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 persisted. I also went to postfix 3.5.1 (out of curiosity, after downgrading back to libssl 1.1.1d) to no avail. I'm not experiencing any other issues (that I know of) on the machine in which TLS is used heavily by other programs with greater activity than postfix. This problem distinctly began immediately after the upgrade (postfix 3.1.14 -> 3.4.10, libssl 1.1.0l -> 1.1.1d). This is not to say that the issue is definitely with postfix, just to give more information. The pattern in which an email fails due to this issue, and then succeeds upon immediately being resent is most perplexing. This is repeatable and suggests that there's some state persisting somewhere. Further, I just tried sending an email from one address via a web-based client (it failed) and immediately sending from my normal MUA, to try to isolate where that state persistence might be. It failed on both, *however*, I realized that I had forgotten to change my MUA's port back to 587 (from 588). I changed it to 587, and repeated this test, and to my surprise, the web-based client failed but the MUA succeeded. It seems like one fix, which is beyond ugly, could be to set up an email to be sent every 5 seconds through the mail server to keep the "TLS warning" state warm, allowing real emails to get through via TLS on their first attempt. As not every mail server immediately retries not over TLS upon a TLS failure, this issue is impacting delivery to a non-insignificant extent. Alexander
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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 juggled around some versions. Bumped to libssl 1.1.1g, restarted > postfix, problem persisted. I also went to postfix 3.5.1 (out of > curiosity, after downgrading back to libssl 1.1.1d) to no avail. If you're willing to rebuild Postfix from source, then I can provide a patch that would log more details. -- Viktor.
Re: 'mlmmj' and Postfix configuration
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 interfaces: virtual_alias_maps, transport_maps, and the pipe delivery agent. Those work like 20 years ago. Except for the compatibility_level changes from Postfix 2 to Postfix 3, new behavior has been mostly additive. Wietse > Does anyone here use this application and have any suggestions on how to > configure it and/or Postfix to work happily together? > > Thanks! > > -- > Gerard -- End of PGP section, PGP failed!
Re: 'mlmmj' and Postfix configuration
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
'mlmmj' and Postfix configuration
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 suggestions on how to configure it and/or Postfix to work happily together? Thanks! -- Gerard pgp5uw2F_pffZ.pgp Description: OpenPGP digital signature
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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 file system. If that is the problem, then your attempts to keep state 'warm' could make the problem more persistent. Wietse
Re: TLS library problem
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 transit, resulting in TLS MAC mismatch. Something bad happens before the TCP checksum is (re)computed or after the TCP checksum is verified. The TCP stack would not pass packets whose TCP checksum don't match the TCP payload. This may include middleboxes that modify TCP in transit, for example, for traffic shaping purposes. For an example of TCP data corruption caused by a traffic shaping middlebox, see ftp://ftp.porcupine.org/pub/debugging 2: broken TLS. Something bad happened while the sending TLS encrypted data or computed the TLS MAC, or while the receiving TLS decrypted data or verified the TLS MAC. 3: data-dependent data corruption at any layer in the stack. Wietse
Re: null recipient "@example.com"@example.com accepted
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_recipient", > > > >which docs' say: > > > >"...Postfix does not accept such addresses in SMTP commands..." > >http://www.postfix.org/postconf.5.html#empty_address_recipient There was a malformed recipient that looked like "@some-local-domain"@some-local-damain See http://www.postfix.org/postconf.5.html#resolve_dequoted_address for why Postfix looks inside the quotes and tries to deliver to ""@some-local-domain. With empty_address_recipient=no, Postfix would reject the address with "unknown user", because there is no user named "@some-local-domain". Wietse > >however, the address is accepted from remote sites, when I enter destination > >domain this way. Even newer postfix versions (3.4.8 checked) accept it. > > > >Should such destination addresses be accepted? > > > >postfix 2.11.3, Debian 8 > > > >smtpd_recipient_restrictions = reject_non_fqdn_recipient, > >reject_unknown_recipient_domain, permit_mynetworks, > >permit_sasl_authenticated, reject_unauth_destination, > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > I don't have lysdexia. The Dog wouldn't allow that. >
Re: Segfaults libpcre in cleanup
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 mime part header. I > counted about 500 times the filename= in the mime part header as well as > name= contains hundreds of values. All nicely utf8 > > Like > > > Content-Type: image/png; name="=?UTF- > > 8?B?xILChMOCwoLEgsKCw4LChMOEwoLDgsKCxILCgsOCwoLEgsKEw4LCgsSC?= > > =?UTF-8?B?woLDgsKCw4TCgsOCwoLEgsKCw4LChMOEwoLDgsKExILCgsOCwoLDhMKC?= > > =?UTF-8?B?w4LCgsSCwoLDgsKCxILChMOCwoLEgsKCw4LCgsOEwoLDgsKCxILCgsOC?= > > and > > > Content-Disposition: inline; filename*0*=UTF-8''%C4%82%C2%84%C3%82%C2 > > %82%C4%82%C2%82%C3%82%C2%84%C3%84; > > filename*1*=%C2%82%C3%82%C2%82%C4%82%C2%82%C3%82%C2%82%C4%82%C2%84 > > %C3%82; > > First of all any idea why cleanup did not segfault with the info rule in > place? When something accesses wrong memory, what happens next is totally dependent on memory layout, execution history, and so on. For example the program may not crash (but still produce incorrect behavior). > 2nd: could such mime headers be the reason for a pcre pattern to let > libpcre segfault? Sure, there are sometimes bugfixes for libpcre. You can test such things. $ postmap -h -q - pcre:pattern-file < data-file $ valgrind --tool=memcheck postmap -h -q - pcre:pattern-file < data-file where data-file contains the complete crashing message header and pattern-file contains the crashing pattern. Note that Postfix logs only a limited portion of very large lines. You may need to "postcat" the original message if it is available. valgrind will report incorrect memory access even when a program does not crash. And yes, I do sometimes run Postfix daemons under valgrind to find non-crashing bugs. I'd be interested if you can reproduce the bug. Wietse
TLS library problem
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 problem, what is the cause and what can I do about it, please? Log lines are as below for two apparently immediate attempts (sender redacted): May 13 12:16:22 BRISTOLWEB postfix/submission/smtpd[12960]: connect from (redacted)] May 13 12:16:22 BRISTOLWEB postfix/submission/smtpd[12960]: Anonymous TLS connection established from (redacted): TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) May 13 12:16:24 BRISTOLWEB postfix/submission/smtpd[12960]: ACA963200DC: client=(redacted), sasl_method=PLAIN, sasl_username=(redacted) May 13 12:16:24 BRISTOLWEB postfix/cleanup[12927]: ACA963200DC: message-id= 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: May 13 12:16:25 BRISTOLWEB postfix/submission/smtpd[12960]: lost connection after DATA (16372 bytes) from (redacted) May 13 12:16:25 BRISTOLWEB postfix/submission/smtpd[12960]: disconnect from (redacted) ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=0/1 commands=6/7 May 13 12:16:35 BRISTOLWEB postfix/submission/smtpd[12960]: connect from (redacted) May 13 12:16:35 BRISTOLWEB postfix/submission/smtpd[12960]: Anonymous TLS connection established from (redacted): TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) May 13 12:16:35 BRISTOLWEB postfix/submission/smtpd[12960]: CE4553200DC: client=(redacted), sasl_method=PLAIN, sasl_username=(redacted) May 13 12:16:35 BRISTOLWEB postfix/cleanup[12927]: CE4553200DC: message-id=<388cf74f-ff63-70da-aa61-b65277af849a@(redacted)> May 13 12:16:37 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: May 13 12:16:37 BRISTOLWEB postfix/submission/smtpd[12960]: lost connection after DATA (139212 bytes) from (redacted) May 13 12:16:37 BRISTOLWEB postfix/submission/smtpd[12960]: disconnect from (redacted) ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=0/1 commands=6/7 Versions: server: Linux Mint 18.1 (Ubuntu 16.04.12) postfix: 3.1.0 openssl: 1.0.2g -- Dave Stiles
Re: null recipient "@example.com"@example.com accepted
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 accept such addresses in SMTP commands..." http://www.postfix.org/postconf.5.html#empty_address_recipient however, the address is accepted from remote sites, when I enter destination domain this way. Even newer postfix versions (3.4.8 checked) accept it. Should such destination addresses be accepted? postfix 2.11.3, Debian 8 smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I don't have lysdexia. The Dog wouldn't allow that.
Re: Postfix "IPv6-only" - experience/recommendation question
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 exactly what Public Suffix List is meant for: to make it possible to distinguish between domains whose subdomains belong to the same organization, company, customer connections to the same ISP etc. and therefore should be treated in common; and domains whose subdomains are publicly available to register and therefore are independent from each other and should NOT be treated in common. The former are not on PSL; the latter are. So if anybody (and especially a large provider like Google) wants to play with "domain reputation" thing, PSL is a must to be taken into account. How else would you distinguish between eg. something.ibm.com and something.co.uk ? :) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: Postfix "IPv6-only" - experience/recommendation question
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 anyone knows this, and suspect this was merely someone’s guess, possibly informed, but probably just a WAG. What is probably true is that Google is more likely to mark mail from servers without a valid rDNS as spam, and perhaps more IPv6 hosts do not do their rDNS correctly? At least some time ago Google had problems with IPv6 PTR temporary failures (on their side) translated into SMTP reject (hard fail). This was only for IPv6, in IPv4 they got it right and you would get a SMTP try later. But never seen this lately and most of our e-mail targeted Google accounts are transfered by IPv6. But as always you are at mercy of their content filter if you use their services for mail. Regards Andi
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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.20 15:08, Alexander Vasarab wrote: Thanks. Using debug_peer_list, I have a few more pieces of information. May 12 14:27:21 vasaconsulting postfix/smtpd[3482]: > []: 235 2.7.0 Authentication successful May 12 14:27:21 vasaconsulting postfix/smtpd[3482]: watchdog_pat: 0x55bec82e41e0 May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: < []: MAIL FROM:<> ...lots of debug info e.g. send attr, etc... May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: > []: 250 2.1.0 Ok May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: watchdog_pat: 0x55bec82e41e0 May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: < []: RCPT TO:<> ...lots of debug info e.g. config maps, etc... May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: > []: 250 2.1.5 Ok May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: watchdog_pat: 0x55bec82e41e0 May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: warning: TLS library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:../ssl/ssl_lib.c:2086: May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: smtp_get: EOF ...some match_hostname stuff, etc... May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: lost connection after RCPT from [] maybe some form of address veriification? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
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 to squeeze a bit more information out using smtpd_tls_loglevel=4. May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: > []: 250 2.1.5 Ok May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: watchdog_pat: 0x55e2224ca3f0 May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: vstream_fflush_some: fd 17 flush 14 May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: Write 14 chars: 250 2.1.5 Ok?? May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: write to 55E222534FF0 [55E222542173] (36 bytes => 36 (0x24)) May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: 17 03 03 00 1f df 3e 1c|66 4c e9 c5 07 39 56 6a ..>. fL...9Vj May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: 0010 ed 71 92 5b ee e6 8b e5|bd a6 9e 8f 33 68 38 74 .q.[ 3h8t May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: 0020 86 60 a1 32 .`.2 May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: read from 55E222534FF0 [55E22253E023] (5 bytes => -1 (0x)) May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: warning: TLS library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:../ssl/ssl_lib.c:2086: May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: smtp_get: EOF
Re: Segfaults libpcre in cleanup
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 counted about 500 times the filename= in the mime part header as well as name= contains hundreds of values. All nicely utf8 Like > Content-Type: image/png; name="=?UTF- > 8?B?xILChMOCwoLEgsKCw4LChMOEwoLDgsKCxILCgsOCwoLEgsKEw4LCgsSC?= > =?UTF-8?B?woLDgsKCw4TCgsOCwoLEgsKCw4LChMOEwoLDgsKExILCgsOCwoLDhMKC?= > =?UTF-8?B?w4LCgsSCwoLDgsKCxILChMOCwoLEgsKCw4LCgsOEwoLDgsKCxILCgsOC?= and > Content-Disposition: inline; filename*0*=UTF-8''%C4%82%C2%84%C3%82%C2 > %82%C4%82%C2%82%C3%82%C2%84%C3%84; > filename*1*=%C2%82%C3%82%C2%82%C4%82%C2%82%C3%82%C2%82%C4%82%C2%84 > %C3%82; First of all any idea why cleanup did not segfault with the info rule in place? 2nd: could such mime headers be the reason for a pcre pattern to let libpcre segfault? -- Cheers tobi Am 12.05.20 um 15:20 schrieb Wietse Venema: > Tobi: >> Hi list >> >> we have the very rare problem that cleanup "triggers" segfaults in >> libpcre. We're currently running postfix 3.5.1 but had the issue before >> updating (with postfix 3.4.4) as well. OS is a Centos7 with latest updates. >> >>> May 12 14:36:14 XXX kernel: cleanup[23927]: segfault at 7ffc5118ef78 >>> ip 7fd07913c98a sp 7ffc5118ef70 error 6 in >>> libpcre.so.1.2.0[7fd079129000+6] >> >> libpcre is of version 8.32 >> >> Unfortunately we do not have access to the message source. But it's >> always the same message that triggers the segfault. Every re-send try >> from sending server ends in that error. >> We highly assume that one of our pcre rules could be the culprit, but >> it's hard to find out which one it is. Postfix never complains about a >> broken pattern or something like that in logs. Also testing with postmap >> -vv -q works without any error/warning for all our pcre maps. There is >> no suspicious logging prior to cleanup "crash". >> >> Is there a way to narrow down which pcre rule may is problematic, given >> the fact that we do not have access to message source? > > Use dummy rules: > > /(.+)/info before foo: $1 > /foo/ action for foo > /(.+)/info before bar > /bar/ action for bar > > Wietse > signature.asc Description: OpenPGP digital signature
