[pfx] Re: IP protocol inconsistency
Polarian via Postfix-users: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. > Hello, > > This seems to clarify it a lot, I hope that it is added to the current > manpages. It's already on-line. PS it never hurts to choose an accurate subject line. 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
* 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 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] Value of client certificates, was: Re: Re: [ext] list.sys4.de fails with starttls
Am 25.09.23 um 22:11 schrieb Viktor Dukhovni via Postfix-users: ... So, unfortunate as it may seem, they just increase opportunities for failure, without adding anything by way of security. ... Client certificates serve no purpose unless the server requests them and knows what to do with them. Hello Viktor, OK, so far I can follow your arguments. But there is one thing that don't match in that picture: It's how I see Google's outbound servers operate. ¹) If I read my mail archive right, Google use client certificates at least since 2015! If operating SMTP clients with a client certificate is so dangerous and has no value, why would google go that? Andreas ¹) grep 'Trusted TLS connection established from' /var/log/mail | grep '.google.com\[' ___ 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: > > > 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: Value of client certificates, was: Re: Re: [ext] list.sys4.de fails with starttls
A. Schulze via Postfix-users: > Am 25.09.23 um 22:11 schrieb Viktor Dukhovni via Postfix-users: > > ... > > So, unfortunate as it may seem, they just increase > > opportunities for failure, without adding anything by way of security. > > ... > > Client certificates serve no purpose unless the server requests them and > > knows what to do with them. > > Hello Viktor, > > OK, so far I can follow your arguments. But there is one thing that don't > match in that picture: > It's how I see Google's outbound servers operate. ?) > If I read my mail archive right, Google use client certificates at least > since 2015! > > If operating SMTP clients with a client certificate is so dangerous and has > no value, > why would google go that? Client certs are useful when the server knows the client. Everyone knows Google. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Value of client certificates, was: Re: Re: [ext] list.sys4.de fails with starttls
On Mon, Sep 25, 2023 at 10:47:44PM +0200, A. Schulze via Postfix-users wrote: > If operating SMTP clients with a client certificate is so dangerous > and has no value, why would google go that? Not, dangerous, just largely pointless, with *potential* complications, unless there are servers that can actually make use of said certificates. In the case of Google's outbound SMTP, perhaps various servers in fact do verify their client certificates. Or perhaps the TLS layer used by Gmail was configured with the same certs inbound and outbound without much analysis as to whether both are required. If the certs are always available and current, they'll generally just go unused without getting in the way. More pointless than harmful. > ¹) grep 'Trusted TLS connection established from' /var/log/mail | grep > '.google.com\[' That won't do any good on my end, my SMTP server does not request client certificates. :-) -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
On Sun, Sep 24, 2023 at 06:25:36PM -0400, Wietse Venema via Postfix-users wrote: > Wietse Venema via Postfix-users: > > It's a rather long explanation for "why not do X". like several > > times longer than the text that explains what protocol preferences > > do. And this is the only place where adding that text would help. > > I updated the text a little: > > Notes for mail delivery between sites that have both IPv4 and IPv6 > connectivity: > > * The setting "smtp_address_preference = ipv6" is unsafe. All > deliveries will suffer delays when IPv6 is not available even > while the destination is still reachable over IPv4. Mail may > be stuck in the queue with Postfix versions < 3.3 that do > not implement "smtp_balance_inet_protocols". For similar reasons, > the setting "smtp_address_preference = ipv4" is also unsafe. > > * The setting "smtp_address_preference = any" is safe. With this, > and "smtp_balance_inet_protocols = yes" (the default), only > half of deliveries will suffer delays if there is an outage > that affects IPv6 or IPv4, as long as it does not affect both. > > I added smtp_balance_inet_protocols to the discussion, because it > mitigates the safety issue somewhat, perhaps to the point that some > people with low email volume are willing to suffer the delays. > > Wietse > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org Sadly, I need smtp_address_preference = ipv4 because some reputation systems (spamhaus, I think) don't realise that an entity might only have a single ipv6 address. They seem to think that everyone has at least 64 addresses. So, when an unrelated tenant near my VPS sent spam from their ipv6 address, it tainted my ipv6 address's reputation. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
On Tue, Sep 26, 2023 at 11:12:53AM +1000, raf via Postfix-users wrote: > Sadly, I need smtp_address_preference = ipv4 because some > reputation systems (spamhaus, I think) don't realise > that an entity might only have a single ipv6 address. > They seem to think that everyone has at least 64 addresses. > So, when an unrelated tenant near my VPS sent spam from their > ipv6 address, it tainted my ipv6 address's reputation. The choice is understandable, otherwise an spammer with a /64 or /56 can switch to a new IP address every second and not run out until well after the Sun is a red giant and the Earth is no more. So if a single IPv6 address is all you have, sadly you do need good neighbours. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
Wietse Venema via Postfix-users: > It's a rather long explanation for "why not do X". like several > times longer than the text that explains what protocol preferences > do. And this is the only place where adding that text would help. On Sun, Sep 24, 2023 at 06:25:36PM -0400, Wietse Venema via Postfix-users wrote: I updated the text a little: Notes for mail delivery between sites that have both IPv4 and IPv6 connectivity: * The setting "smtp_address_preference = ipv6" is unsafe. All deliveries will suffer delays when IPv6 is not available even while the destination is still reachable over IPv4. Mail may be stuck in the queue with Postfix versions < 3.3 that do not implement "smtp_balance_inet_protocols". For similar reasons, the setting "smtp_address_preference = ipv4" is also unsafe. * The setting "smtp_address_preference = any" is safe. With this, and "smtp_balance_inet_protocols = yes" (the default), only half of deliveries will suffer delays if there is an outage that affects IPv6 or IPv4, as long as it does not affect both. I added smtp_balance_inet_protocols to the discussion, because it mitigates the safety issue somewhat, perhaps to the point that some people with low email volume are willing to suffer the delays. On 26.09.23 11:12, raf via Postfix-users wrote: Sadly, I need smtp_address_preference = ipv4 because some reputation systems (spamhaus, I think) don't realise that an entity might only have a single ipv6 address. They seem to think that everyone has at least 64 addresses. So, when an unrelated tenant near my VPS sent spam from their ipv6 address, it tainted my ipv6 address's reputation. I wait yet to see some nice way to create reputation systems like DNSBLs for IPv6 that will work as reliably as for IPv4. I remember some proposals but no real example with explanation how it works. -- 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 wonder how much deeper the ocean would be without sponges. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
