[pfx] Re: [off-topic] aarch inclusion in Linux distros (was: IPv6 and Cloud server CPU)
On 24/11/23 19:52, Peter via Postfix-users wrote: It's not the distro. It's common for Linux distros to fully support ARM, but that does not put any obligation on 3rd-party distros, just like if someone were to create a 3rd-party distro for BSD it would be up to them to decide which arches they want to support and that does not reflect on the support by the distro itself. That was meant to say "3rd party repos", not distros. Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] [off-topic] aarch inclusion in Linux distros (was: IPv6 and Cloud server CPU)
On 23/11/23 21:08, Charles Sprickman via Postfix-users wrote: This ^. Specifically if you want to run an EL distro there are good choices that offer ARM support and come with stock postfix and dovecot packages, but if you want to run the GhettoForge packages (which have newer versions of Postfix and Dovecot than that offered by the stock distros) then I'm afraid you're stuck with x86_64 for now. Similarily you might have issues with other supporting software that is only available from 3rd-party repos or where 3rd-party repos have newer versions taht you want to use, but not for ARM. Is this a common thing with Linux distros? I've not dabbled there in ages, but on the various *BSDs they tend to have a designation for each architecture, for example FreeBSD at some point moved most ARM variants to "Tier 1" which generally means there's parity with x86 for the average user. It's not the distro. It's common for Linux distros to fully support ARM, but that does not put any obligation on 3rd-party distros, just like if someone were to create a 3rd-party distro for BSD it would be up to them to decide which arches they want to support and that does not reflect on the support by the distro itself. Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.
Thanks Victor - so more t-shooting on our end, then - cool On 24/11/2023 04:16, Viktor Dukhovni via Postfix-users wrote: On Thu, Nov 23, 2023 at 07:48:33PM +1100, duluxoz via Postfix-users wrote: Hi All, This may be a stupid Q, but we're getting a `postfix/tlsproxy[89206]: TLS handshake failed for service=smtp peer=[104.199.96.85]:25` error in our logs when trying to relay via an SMTP Relay Service (both Mailjet and Brevo/SendInBlue). Could our issue be related to this LE issue? No, failure to complete the TLS handshake is not related to any issues with the certificates. That said, the handshake works for me: posttls-finger: Untrusted TLS connection established to 104.199.96.85[104.199.96.85]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 posttls-finger: > EHLO straasha.imrryr.org posttls-finger: < 250-smtpin.mailjet.com posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 15728640 posttls-finger: < 250-VRFY posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 posttls-finger: < 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250-SMTPUTF8 posttls-finger: < 250 CHUNKING posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye Unclear why your tlsproxy is having issues. Perhaps the same problem as Patrick was having with SELinux? Don't configure any client certificates on your end, or don't enable SELinux? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.
On Thu, Nov 23, 2023 at 07:48:33PM +1100, duluxoz via Postfix-users wrote: > Hi All, > > This may be a stupid Q, but we're getting a `postfix/tlsproxy[89206]: TLS > handshake failed for service=smtp peer=[104.199.96.85]:25` error in our logs > when trying to relay via an SMTP Relay Service (both Mailjet and > Brevo/SendInBlue). Could our issue be related to this LE issue? No, failure to complete the TLS handshake is not related to any issues with the certificates. That said, the handshake works for me: posttls-finger: Untrusted TLS connection established to 104.199.96.85[104.199.96.85]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 posttls-finger: > EHLO straasha.imrryr.org posttls-finger: < 250-smtpin.mailjet.com posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 15728640 posttls-finger: < 250-VRFY posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 posttls-finger: < 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250-SMTPUTF8 posttls-finger: < 250 CHUNKING posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye Unclear why your tlsproxy is having issues. Perhaps the same problem as Patrick was having with SELinux? Don't configure any client certificates on your end, or don't enable SELinux? -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.
On Thu, Nov 23, 2023 at 12:25:19PM +, Alan Munday via Postfix-users wrote: > > > It may be prudent to mark your calendar to check the Let's Encrypt > > > certificate page once or twice a year, and make appropriate changes if > > > new intermediate issuer CAs are introduced, or extant ones retired. > > > > > > https://letsencrypt.org/certificates/ > > Can I check I have not missed something here. > > > When I use Viktor's chaingen.sh I get a TLSA 3 1 1 which matches the > TLSA 2 1 1 above. That's because you're trying to use "chaingen.sh" on just the chain file with the issuer CAs, rather than the complete chain with the server certificate *followed* by the issuer CAs. For Let's Encrypt, the therefore, you need either concatenate the "cert" and "fullchain" (not really) files: h=$(uname -n) # or whatever MX hostname you use l=$(uname -n) # or whatever "lineage" name is pertinent d=/etc/letsencrypt/live/$l eechain=$(mktemp -t fullchain.XX) cat $d/cert.pem $d/fullchain.pem > $eechain chaingen.sh $eechain $h rm $eechain or just know that all the issuer CA usages should be "2" not "3" when running "chaingen" on a partial chain that is missing the end-entity (EE, i.e. leaf or server) certificate. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
Ralph Seichter via Postfix-users: > * Wietse Venema via Postfix-users: > > >> Now that I think of it again, I wonder if the reload command is even > >> necessary? > > > > Yes, because it is implemented in the queue manager which is a > > long-running process. > > Thank you. I have been using the reload step for so long, but I could > not recall why I did it. It might have been a belt-and-suspenders kind > of situation. ;-) > > > If you use defer_transports to freeze mail deliveries, then some > > messages may get close to the bounce_queue_lifetime, meaning that > > Postfix will try to deliver them only once. > > Interesting. Given the default bounce_queue_lifetime of five days, a > value I rarely touch in Postfix setups, I would not intuitively consider > this a possible reason for concern? It's unlikely to be a problem, especially for local deliveries which rarely require a retry. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS server certificate verification fails
On 11/20/23 19:57, Viktor Dukhovni via Postfix-users wrote: This mail comes from external sender! On Mon, Nov 20, 2023 at 04:01:05PM +0100, Marc Dierksen via Postfix-users wrote: For the domain 'shieldersme.com' outbound TLS is configured via this entry in the TLS policy map: shieldersme.com verify match=hostname:nexthop:dot-nexthop ciphers=high protocols=>=TLSv1.2 When trying to send mail I am getting the following error: Nov 17 12:23:50 postfix-outbound/smtp[11269]: server certificate verification failed for shieldersme.com[5.79.80.155]:25: num=62:hostname mismatch This is easily reproducible: $ posttls-finger -c -Lsummary -lsecure "shieldersme.com" hostname nexthop dot-nexthop posttls-finger: server certificate verification failed for shieldersme.com[5.79.80.155]:25: num=62:hostname mismatch posttls-finger: Untrusted TLS connection established to shieldersme.com[5.79.80.155]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) And expected (i.e. works as indended and specified in all relevant RFCs): $ posttls-finger -cC -Lsummary -lsecure "shieldersme.com" hostname nexthop dot-nexthop 2>&1 | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -text | grep -E 'Subject:|DNS:' Subject: CN=liger.hibridmena.com DNS:liger.hibridmena.com Subject: C=US, ST=TX, L=Houston, O=cPanel, Inc., CN=cPanel, Inc. Certification Authority Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority The actual certificate presented to Postfix is for: liger.hibridmena.com Your tests with "openssl s_client" sent a default SNI etension, but Postfix does not by default. With SMTP, it is unclear, in general, what the SNI should be, and sending the "wrong" SNI can sometimes cause connection aborts. Therefore, if you want to solicit a particular certificate, you have to configure the SNI explicitly. $ posttls-finger -cC -s shieldersme.com -Lsummary -lsecure "shieldersme.com" hostname nexthop dot-nexthop 2>&1 | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -text | grep -E 'Subject:|DNS:' Subject: CN=*.shieldersme.com DNS:*.shieldersme.com, DNS:shieldersme.com Subject: C=US, O=Let's Encrypt, CN=R3 Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1 Relevant documentation: posttls-finger(1): -s servername The server name to send with the TLS Server Name Indication (SNI) extension. When the server has DANE TLSA records, this parameter is ignored and the TLSA base domain is used instead. Otherwise, SNI is not used by default, but can be enabled by specifying the desired value with this option. postconf(5): mayOpportunistic TLS. Since sending in the clear is acceptable, demanding stronger than default TLS security merely reduces interoperability. The optional "ciphers", "exclude", and "protocols" attributes (available for opportunistic TLS with Postfix >= 2.6) and "connection_reuse" attribute (Postfix >= 3.4) override the "smtp_tls_ciphers", "smtp_tls_exclude_ciphers", "smtp_tls_protocols", and "smtp_tls_connection_reuse" configuration parameters. In the policy table, multiple ciphers, protocols or excluded ciphers must be separated by colons, as attribute values may not contain >whitespace or commas. At this level and higher, the optional >"servername" attribute (available with Postfix >= 3.4) overrides >the global "smtp_tls_servername" parameter, enabling >per-destination configuration of the SNI extension sent to the >remote SMTP server. The optional "enable_rpk" attribute (Postfix >= 3.9) overrides the main.cf smtp_tls_enable_rpk parameter. When opportunistic TLS handshakes fail, Postfix retries the connection with TLS disabled. This allows mail delivery to sites with non-interoperable TLS implementations. You need to add "servername=shieldersme.com" to the policy table entry. Also, in this case, using "hostname" is a bad idea, it means you'd trust insecurely obtained forged MX records to tell the client what name to match, so any active attacker can compromise the connection by sending a suitably crafted MX response. The match pattern you want here is nexthop:dot-nexthop *without* "hostname". Or (less fungible) even just "nexthop", if by mutual agreement with the receiving system, you're sure that the cert will "always" include the domain. Viktor, thank you for your explanation. Now
[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.
On 19/11/2023 06:24, Viktor Dukhovni via Postfix-users wrote: On Sat, Nov 18, 2023 at 04:33:46PM +0900, Byung-Hee HWANG via Postfix-users wrote: or if you prefer: _25._tcp.mx1.org.example. IN CNAME _25._tlsa.org.example. _25._tcp.mx2.org.example. IN CNAME _25._tlsa.org.example. ... _25._tcp.mxN.org.example. IN CNAME _25._tlsa.org.example. ; _25._tlsa.org.example. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; R3 _25._tlsa.org.example. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; R4 _25._tlsa.org.example. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; E1 _25._tlsa.org.example. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; E2 Thank you for the clear summary. I did update all again. Good job, you're set until some future change a few years down the line. _25._tcp.yw-0919.doraji.xyz. IN CNAME rfc7671.doraji.xyz. _25._tcp.yw-1204.doraji.xyz. IN CNAME rfc7671.doraji.xyz. rfc7671.doraji.xyz. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d rfc7671.doraji.xyz. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 rfc7671.doraji.xyz. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 rfc7671.doraji.xyz. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 It may be prudent to mark your calendar to check the Let's Encrypt certificate page once or twice a year, and make appropriate changes if new intermediate issuer CAs are introduced, or extant ones retired. https://letsencrypt.org/certificates/ Can I check I have not missed something here. When I use Viktor's changen.sh I get a TLSA 3 1 1 which matches the TLSA 2 1 1 above. ;; subject=C = US, O = Let's Encrypt, CN = R3 ;; issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1 ;; notBefore=Sep 4 00:00:00 2020 GMT ;; notAfter=Sep 15 16:00:00 2025 GMT ;; _25._tcp.mx.org.example. IN TLSA 3 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d And I get a TLSA 2 1 1 which is not listed: ;; subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1 ;; issuer=O = Digital Signature Trust Co., CN = DST Root CA X3 ;; notBefore=Jan 20 19:14:03 2021 GMT ;; notAfter=Sep 30 18:14:03 2024 GMT ;; _25._tcp.mx.org.example. IN TLSA 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
* Wietse Venema via Postfix-users: >> Now that I think of it again, I wonder if the reload command is even >> necessary? > > Yes, because it is implemented in the queue manager which is a > long-running process. Thank you. I have been using the reload step for so long, but I could not recall why I did it. It might have been a belt-and-suspenders kind of situation. ;-) > If you use defer_transports to freeze mail deliveries, then some > messages may get close to the bounce_queue_lifetime, meaning that > Postfix will try to deliver them only once. Interesting. Given the default bounce_queue_lifetime of five days, a value I rarely touch in Postfix setups, I would not intuitively consider this a possible reason for concern? -Ralph ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.
Hi All, This may be a stupid Q, but we're getting a `postfix/tlsproxy[89206]: TLS handshake failed for service=smtp peer=[104.199.96.85]:25` error in our logs when trying to relay via an SMTP Relay Service (both Mailjet and Brevo/SendInBlue). Could our issue be related to this LE issue? On 19/11/2023 06:24, Viktor Dukhovni via Postfix-users wrote: On Sat, Nov 18, 2023 at 04:33:46PM +0900, Byung-Hee HWANG via Postfix-users wrote: or if you prefer: _25._tcp.mx1.org.example. IN CNAME _25._tlsa.org.example. _25._tcp.mx2.org.example. IN CNAME _25._tlsa.org.example. ... _25._tcp.mxN.org.example. IN CNAME _25._tlsa.org.example. ; _25._tlsa.org.example. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; R3 _25._tlsa.org.example. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; R4 _25._tlsa.org.example. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; E1 _25._tlsa.org.example. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; E2 Thank you for the clear summary. I did update all again. Good job, you're set until some future change a few years down the line. _25._tcp.yw-0919.doraji.xyz. IN CNAME rfc7671.doraji.xyz. _25._tcp.yw-1204.doraji.xyz. IN CNAME rfc7671.doraji.xyz. rfc7671.doraji.xyz. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d rfc7671.doraji.xyz. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 rfc7671.doraji.xyz. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 rfc7671.doraji.xyz. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 It may be prudent to mark your calendar to check the Let's Encrypt certificate page once or twice a year, and make appropriate changes if new intermediate issuer CAs are introduced, or extant ones retired. https://letsencrypt.org/certificates/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IPv6 and Cloud server CPU
About Docker, you may want to do some research on it, because it may not be desirable for production systems due to its monolithic design, it uses a single Docker daemon, while competitors like podman use a daemonless architecture. Look how "easy" it is to secure Docker: https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html On Thu, 23 Nov 2023 19:01:56 +1300 DL Neil via Postfix-users wrote: > New to me was Docker Mailserver. This appears to be more cut-down, but > also gives (me) the impression that main.cf and master.cf are either > hidden-away or totally-inaccessible. Nr1 difference is 'no RDBMS', which > I guess I could live-with (am quite at-home with SQL and such) and don't > need it for (eg) the web-site side of things, so... > > Do you have experience using this package? > (is it sufficiently "Postfix" to be suitable conversation on this list?) > > -- > Regards =dn > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IPv6 and Cloud server CPU
> On Nov 22, 2023, at 11:20 PM, Peter via Postfix-users > wrote: > > On 23/11/23 14:22, Gerald Galster via Postfix-users wrote: >>> Q2: >>> given the minuscule work-load, is there any preference/preclusion between >>> employing the 'usual' x86 processor or 2 Arm Ampere processors? Both offer >>> Linux. Cost is effectively same. >> You should check if the software you want to use is available >> for the desired platform. Distributions might provide dovecot >> packages for ARM while the official dovecot repository might >> not. Then you would have to compile the sources yourself. > > This ^. Specifically if you want to run an EL distro there are good > choices that offer ARM support and come with stock postfix and dovecot > packages, but if you want to run the GhettoForge packages (which have newer > versions of Postfix and Dovecot than that offered by the stock distros) then > I'm afraid you're stuck with x86_64 for now. Similarily you might have > issues with other supporting software that is only available from 3rd-party > repos or where 3rd-party repos have newer versions taht you want to use, but > not for ARM. Is this a common thing with Linux distros? I've not dabbled there in ages, but on the various *BSDs they tend to have a designation for each architecture, for example FreeBSD at some point moved most ARM variants to "Tier 1" which generally means there's parity with x86 for the average user. Charles > k > > Peter > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
