[pfx] Re: [ext] list.sys4.de fails with starttls
Viktor Dukhovni via Postfix-users: > > > The best solution is [to] configure client certs *sparingly*, only > > > for transports dedicated to destinations that definitely need the > > > client certs, and not otherwise. > > > > Why? I feel a little like I was feeling in the early 2000s when we had > > to justify offering STARTTLS on the server side. IMHO TLS should be > > default on both ends and any service not complying should need to > > explain why. > > Client certificates serve no purpose unless the server requests them and > knows what to do with them. That's pretty much just: > > - submission servers that use client certs instead of passwords. > - dedicated mail store servers that restrict delivery (or skip > spam filters, ...) to just authorised sources. In other words, where the server expects to know the client. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] list.sys4.de fails with starttls
On Mon, Sep 25, 2023 at 04:24:55PM +0200, Patrick Ben Koetter via Postfix-users wrote: > > Do you have SMTP client TLS connection reuse enabled? If so, TLS > > connections are made via tlsproxy(8), with the smtp(8) client > > unaware of any initialisation issues until STARTTLS. > > Well spotted and that was the reason Postfix failed. We've added a SELinux > policy to let tlsproxy do what it wants and things went back to normal. Thanks for the confirmation. I feel some pride in intuiting the cause in this case, the link with the reported symptoms was fairly subtle. > Also: As of today list.sys4.de offers and uses RSA *and* ECDSA certificates. > TLSA RRs had been extended before we activated the new certs. No worries, I trust you'll be able to manage the TLSA records accordingly, and have monitoring in place that tests both algorihtms. > > If you also have TLS client certs configured (typically without just > > cause) to be sent to servers that happen to request them (also typically > > without just cause), then a failure to load the client certs breaks TLS > > support in tlsproxy(8), which makes all attempts at "STARTTLS" fail. > > Yes, list.sys4.de also uses TLS client certs and I'm not really sure I like > you writing "typically without just cause". I'd rather have it the other way > around and be irritated if clients do not identify themselves in TLS sessions > as well. But then this leads to another discussion about mutual DANE-based > identification where the client side need to identify itself to a > DANE-verifying server as well. Well, very few servers will actually request the client certificates, so you can configure them to your heart's content, but they'll almost never be sent. The few servers that do ask, won't in practice know what to do with them. So, unfortunate as it may seem, they just increase opportunities for failure, without adding anything by way of security. > > The best solution is [to] configure client certs *sparingly*, only > > for transports dedicated to destinations that definitely need the > > client certs, and not otherwise. > > Why? I feel a little like I was feeling in the early 2000s when we had > to justify offering STARTTLS on the server side. IMHO TLS should be > default on both ends and any service not complying should need to > explain why. Client certificates serve no purpose unless the server requests them and knows what to do with them. That's pretty much just: - submission servers that use client certs instead of passwords. - dedicated mail store servers that restrict delivery (or skip spam filters, ...) to just authorised sources. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] list.sys4.de fails with starttls
* Viktor Dukhovni via Postfix-users : > On Sun, Sep 17, 2023 at 06:20:53PM +0200, Patrick Ben Koetter via > Postfix-users wrote: > > > Yesterday we upgraded LE certs and it seems – we haven't had time to > > investigate in that yet – SELinux bite Postfix where it shouldn't. > > Astonishingly SELinux has been running like that for 193 days and the > > problem > > should have occurred long time before we exchanged the LE cert. But all of > > what I'm writing is rumor and none has been proven. I'll write more when we > > have proven what went wrong. > > Do you have SMTP client TLS connection reuse enabled? If so, TLS > connections are made via tlsproxy(8), with the smtp(8) client unaware of > any initialisation issues until STARTTLS. Well spotted and that was the reason Postfix failed. We've added a SELinux policy to let tlsproxy do what it wants and things went back to normal. Also: As of today list.sys4.de offers and uses RSA *and* ECDSA certificates. TLSA RRs had been extended before we activated the new certs. > If you also have TLS client certs configured (typically without just > cause) to be sent to servers that happen to request them (also typically > without just cause), then a failure to load the client certs breaks TLS > support in tlsproxy(8), which makes all attempts at "STARTTLS" fail. Yes, list.sys4.de also uses TLS client certs and I'm not really sure I like you writing "typically without just cause". I'd rather have it the other way around and be irritated if clients do not identify themselves in TLS sessions as well. But then this leads to another discussion about mutual DANE-based identification where the client side need to identify itself to a DANE-verifying server as well. > We could perhaps consider soft-failing failure to load certificates in > the SMTP client (tls_client_init()). But this requires care, because > mail could bounce when the server is a submission relay that optionally > authenticates the client via its X.509 certificate, but doesn't > terminate the handshake when a client certificate is not presented > (perhaps it also supports SASL as an alternative). > > The best solution is configure client certs *sparingly*, only for > transports dedicated to destinations that definitely need the client > certs, and not otherwise. Why? I feel a little like I was feeling in the early 2000s when we had to justify offering STARTTLS on the server side. IMHO TLS should be default on both ends and any service not complying should need to explain why. > It is not possible to make an educated guess as to why tlsproxy(8) may > not have been able to load the certs, if that's what happened, without > some additional context from the server. > > Of course the problem could be entirely unrelated to tlsproxy(8), but > there are fewer obvious opportunities for late failure when TLS is > used directly by the smtp(8) client. You spotted the problem perfectly. It was tlsproxy being hindered by SELinux. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] list.sys4.de fails with starttls
On Sun, Sep 17, 2023 at 06:20:53PM +0200, Patrick Ben Koetter via Postfix-users wrote: > Yesterday we upgraded LE certs and it seems – we haven't had time to > investigate in that yet – SELinux bite Postfix where it shouldn't. > Astonishingly SELinux has been running like that for 193 days and the problem > should have occurred long time before we exchanged the LE cert. But all of > what I'm writing is rumor and none has been proven. I'll write more when we > have proven what went wrong. Do you have SMTP client TLS connection reuse enabled? If so, TLS connections are made via tlsproxy(8), with the smtp(8) client unaware of any initialisation issues until STARTTLS. If you also have TLS client certs configured (typically without just cause) to be sent to servers that happen to request them (also typically without just cause), then a failure to load the client certs breaks TLS support in tlsproxy(8), which makes all attempts at "STARTTLS" fail. We could perhaps consider soft-failing failure to load certificates in the SMTP client (tls_client_init()). But this requires care, because mail could bounce when the server is a submission relay that optionally authenticates the client via its X.509 certificate, but doesn't terminate the handshake when a client certificate is not presented (perhaps it also supports SASL as an alternative). The best solution is configure client certs *sparingly*, only for transports dedicated to destinations that definitely need the client certs, and not otherwise. It is not possible to make an educated guess as to why tlsproxy(8) may not have been able to load the certs, if that's what happened, without some additional context from the server. Of course the problem could be entirely unrelated to tlsproxy(8), but there are fewer obvious opportunities for late failure when TLS is used directly by the smtp(8) client. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] list.sys4.de fails with starttls
STARTTLS should be back to normal again. My tests suceeded and I'll give it
another shot when I'm home. At the moment I'm on a rather longish train ride
and internet is shaky - at best.
Yesterday we upgraded LE certs and it seems – we haven't had time to
investigate in that yet – SELinux bite Postfix where it shouldn't.
Astonishingly SELinux has been running like that for 193 days and the problem
should have occurred long time before we exchanged the LE cert. But all of
what I'm writing is rumor and none has been proven. I'll write more when we
have proven what went wrong.
p@rick
* Wietse Venema via Postfix-users :
> In my case, all STARTTLS commands fail. Delivery succeeds after re-connecting
> with plaintext.
> Apparently, not all connections are retried in plaintext.
>
> To work around one could say:
>
> smtpd_discard_ehlo_keyword_address_maps = cidr:{
> {188.68.34.52 starttls}
> {2a03:4000:10:51d:b8ce:63ff:feca:a5a0 starttls}}
>
> I'll reach out to sys4.de people.
>
> Wietse
>
> SMTP server logging shows that all STARTTLS commands fail (starttls=0/1)
> and that plaintext succeeds (no starttls= logging).
>
> $ grep 'disconnect from list.sys4.de' /var/log/maillog
> Sep 17 01:58:07 spike postfix/smtpd[53249]: disconnect from
> list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
> Sep 17 01:58:08 spike postfix/smtpd[53249]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 02:07:57 spike postfix/smtpd[53309]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 02:07:58 spike postfix/smtpd[53309]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1
> data=1 quit=1 commands=5
> Sep 17 08:27:52 spike postfix/smtpd[56501]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 08:27:53 spike postfix/smtpd[56501]: disconnect from
> list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
> Sep 17 08:37:49 spike postfix/smtpd[56537]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 08:37:50 spike postfix/smtpd[56537]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1
> data=1 quit=1 commands=5
> Sep 17 09:08:54 spike postfix/smtpd[56707]: disconnect from
> list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
> Sep 17 09:08:55 spike postfix/smtpd[56707]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 09:19:01 spike postfix/smtpd[56772]: disconnect from
> list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
> Sep 17 09:19:02 spike postfix/smtpd[56772]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 09:22:12 spike postfix/smtpd[56805]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 09:22:13 spike postfix/smtpd[56805]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1
> data=1 quit=1 commands=5
> Sep 17 09:25:49 spike postfix/smtpd[56825]: disconnect from
> list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
> Sep 17 09:25:50 spike postfix/smtpd[56825]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 09:27:01 spike postfix/smtpd[56825]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 09:27:04 spike postfix/smtpd[56825]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1
> data=1 quit=1 commands=5
> Sep 17 09:37:30 spike postfix/smtpd[56866]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 09:37:31 spike postfix/smtpd[56866]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1
> data=1 quit=1 commands=5
> Sep 17 09:49:18 spike postfix/smtpd[56909]: disconnect from
> list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
> commands=1/2
> Sep 17 09:49:19 spike postfix/smtpd[56909]: disconnect from
> list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
> Sep 17 09:57:20 spike postfix/smtpd[56945]: disconnect from
> list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
> Sep 17 09:57:22 spike postfix/smtpd[56945]: disconnect from
> list.sys4.de[188.68.34.52] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
>
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333
[pfx] Re: [ext] list.sys4.de fails with starttls
In my case, all STARTTLS commands fail. Delivery succeeds after re-connecting
with plaintext.
Apparently, not all connections are retried in plaintext.
To work around one could say:
smtpd_discard_ehlo_keyword_address_maps = cidr:{
{188.68.34.52 starttls}
{2a03:4000:10:51d:b8ce:63ff:feca:a5a0 starttls}}
I'll reach out to sys4.de people.
Wietse
SMTP server logging shows that all STARTTLS commands fail (starttls=0/1)
and that plaintext succeeds (no starttls= logging).
$ grep 'disconnect from list.sys4.de' /var/log/maillog
Sep 17 01:58:07 spike postfix/smtpd[53249]: disconnect from
list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
Sep 17 01:58:08 spike postfix/smtpd[53249]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 02:07:57 spike postfix/smtpd[53309]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 02:07:58 spike postfix/smtpd[53309]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1 data=1
quit=1 commands=5
Sep 17 08:27:52 spike postfix/smtpd[56501]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 08:27:53 spike postfix/smtpd[56501]: disconnect from
list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
Sep 17 08:37:49 spike postfix/smtpd[56537]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 08:37:50 spike postfix/smtpd[56537]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1 data=1
quit=1 commands=5
Sep 17 09:08:54 spike postfix/smtpd[56707]: disconnect from
list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
Sep 17 09:08:55 spike postfix/smtpd[56707]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 09:19:01 spike postfix/smtpd[56772]: disconnect from
list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
Sep 17 09:19:02 spike postfix/smtpd[56772]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 09:22:12 spike postfix/smtpd[56805]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 09:22:13 spike postfix/smtpd[56805]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1 data=1
quit=1 commands=5
Sep 17 09:25:49 spike postfix/smtpd[56825]: disconnect from
list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
Sep 17 09:25:50 spike postfix/smtpd[56825]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 09:27:01 spike postfix/smtpd[56825]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 09:27:04 spike postfix/smtpd[56825]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1 data=1
quit=1 commands=5
Sep 17 09:37:30 spike postfix/smtpd[56866]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 09:37:31 spike postfix/smtpd[56866]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 mail=1 rcpt=1 data=1
quit=1 commands=5
Sep 17 09:49:18 spike postfix/smtpd[56909]: disconnect from
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1
commands=1/2
Sep 17 09:49:19 spike postfix/smtpd[56909]: disconnect from
list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
Sep 17 09:57:20 spike postfix/smtpd[56945]: disconnect from
list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2
Sep 17 09:57:22 spike postfix/smtpd[56945]: disconnect from
list.sys4.de[188.68.34.52] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] list.sys4.de fails with starttls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2023-09-17 at 15:24 +0200, Herbert J. Skuhra via Postfix-users wrote: > On Fri, 17 Mar 2023 14:32:06 +0100, Ralf Hildebrandt via Postfix-users > wrote: > > > > * Benny Pedersen via Postfix-users : > > > Mar 17 11:38:31 localhost postfix/smtpd[22150]: lost connection > > > after STARTTLS from > > > list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] > > > Mar 17 12:09:10 localhost postfix/smtpd[23415]: lost connection > > > after STARTTLS from > > > list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] > > > > > > maybe it works ? > > > > I'll check. Which IP is that? > > Since yesterday the same happens again. > > Sep 17 15:08:36 mail postfix/smtpd[97630]: SSL_accept error from > list.sys4.de[188.68.34.52]: lost connection > Sep 17 15:08:36 mail postfix/smtpd[97630]: lost connection after > STARTTLS from list.sys4.de[188.68.34.52] I see the same on Debian Bullseye (oldstable) with Postfix v3.5.18 Sep 17 13:25:41 mx1.domainmail.net postfix/smtpd[2306]: connect from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: SSL_accept error from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0]: lost connection Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: lost connection after STARTTLS from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: disconnect from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1 commands=1/2 Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: connect from list.sys4.de[188.68.34.52] Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: SSL_accept error from list.sys4.de[188.68.34.52]: lost connection Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: lost connection after STARTTLS from list.sys4.de[188.68.34.52] Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: disconnect from list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2 - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAmUHA5gACgkQPcxbabkK GJ활䀂围ꪁ刁⢬鱀牫㲒㤄쯖负��롏㤒�翻抍맍㌌ A7mEj86oVv/N7kbDQTClxBkK6JrZD0ZokIsjX7holTVWQcHUOvD6Xq9jGlS6N5Je toLI⸢楌韹쫕㱷쳍ࡆ陎勏忁ᨾ野囸ိ㯅틕纤櫐 uJzℂ끫뙝嬀⒘܃윋㕲㧬噜祦⟺㏜ѹỜ餵퉵겣魀殦寶 K76tMzC8KtEE72rTeBnxMEuQfX/XUWVWmo7OPb0g3IbIvArxhi駧ꓳᨫ gl0DyYyJA5x7vzGwn8wITzbQP9pszbYG3vNjL3FC2sCwLMW8KmvZ3PRGvAw/OrJ6 mG3mgbNdEO5JRllZHNVykzud3bwRO3A8k9T2OLDnvc4Dh2FrYMRY6UoJMHn479aA GtnoKEZHX3TN70VQXuQcprMx6ohb2Yb1s2qv6mdDY9BZwj62d5HGXrrFTk3ZVxSB k4zbPL7GfVnvDrsaLe8ptCvSwxlxOraVehuMm1gsuDxvU8lK6fsNdZ1MUdZhBx/c G6Ua36Xe70StWx0lRx00FAw6xfpldnghSstHVOpGCChmzjOKwuhwZNoAstIZUX3d w9k汚壍⢏郪뗑츏ΰ耿ⳍ㵙짡䑘㫮= =kk38 -END PGP SIGNATURE- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] list.sys4.de fails with starttls
On Fri, 17 Mar 2023 14:32:06 +0100, Ralf Hildebrandt via Postfix-users wrote: > > * Benny Pedersen via Postfix-users : > > Mar 17 11:38:31 localhost postfix/smtpd[22150]: lost connection after > > STARTTLS from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] > > Mar 17 12:09:10 localhost postfix/smtpd[23415]: lost connection after > > STARTTLS from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] > > > > maybe it works ? > > I'll check. Which IP is that? Since yesterday the same happens again. Sep 17 15:08:36 mail postfix/smtpd[97630]: SSL_accept error from list.sys4.de[188.68.34.52]: lost connection Sep 17 15:08:36 mail postfix/smtpd[97630]: lost connection after STARTTLS from list.sys4.de[188.68.34.52] I see the same with a mailbox.org address: Received: from list.sys4.de (list.sys4.de [188.68.34.52]) by mx1.mailbox.org (Postfix) with ESMTP id DDCDE4040F for < @mailbox.org>; Sun, 17 Sep 2023 15:07:02 +0200 (CEST) -- Herbert ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] list.sys4.de fails with starttls
* Benny Pedersen via Postfix-users : > Mar 17 11:38:31 localhost postfix/smtpd[22150]: lost connection after > STARTTLS from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] > Mar 17 12:09:10 localhost postfix/smtpd[23415]: lost connection after > STARTTLS from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] > > maybe it works ? I'll check. Which IP is that? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
