[pfx] Some TLS connections untrusted in postfix but trusted with posttls-finger
Hi, There is something strange with delivering mail from my mailserver to github, it complains about the github server certificate not verified on an outgoing TLS connection. My main.cf contains the same certs-path for smtp and smtpd TLS connections: ---snip--- # grep CApath main.cf smtp_tls_CApath = /etc/ssl/certs smtpd_tls_CApath = /etc/ssl/certs ---snip--- What I see in the failure case is: ---snip--- Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: CONNECT to [140.82.112.31]:25 Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: server certificate verification failed for in-9.smtp.github.com[140.82.112.31]:25: num=62:hostname mismatch Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: Untrusted TLS connection established to in-9.smtp.github.com[140.82.112.31]: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 Nov 30 11:18:40 mailgate postfix/smtp[98296]: Untrusted TLS connection established to in-9.smtp.github.com[140.82.112.31]: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 Nov 30 11:18:40 mailgate postfix/smtp[98296]: 43213239F0: to=, relay=in-9.smtp.github.com[140.82.112.31]:25, delay=180939, delays=180930/4/5.4/0, dsn=4.7.5, status=deferred (Server certificate not verified) Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: DISCONNECT [140.82.112.31]:25 ---snip--- The github cert is signed by "DigiCert TLS RSA SHA256 2020 CA1" (included in the cert-chain the server sends). This is signed by "DigiCert Global Root CA" which is not in the chain, but in my trust store (which is configured as CApath in postfix as can be seen above). The DigiCert Global Root CA is in the trust store with hash /etc/ssl/certs/3513523f.0. What postfix tries to lookup is /etc/ssl/certs/e83d98dd.0, which doesn't exist. Other outgoing TLS connections work (since years), so the generic TLS setup is correct: ---snip--- Nov 30 11:28:03 mailgate postfix/tlsproxy[99594]: CONNECT to [96.47.72.80]:25 Nov 30 11:28:04 mailgate postfix/tlsproxy[99594]: Verified TLS connection established to mx1.freebsd.org[96.47.72.80]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256 Nov 30 11:28:04 mailgate postfix/smtp[99562]: Verified TLS connection established to mx1.freebsd.org[96.47.72.80]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256 Nov 30 11:28:06 mailgate postfix/smtp[99562]: E93042202C: to=, relay=mx1.freebsd.org[96.47.72.80]:25, delay=28, delays=8.4/6.9/11/1.1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4SgspY18rqz3KXr) Nov 30 11:28:06 mailgate postfix/tlsproxy[99594]: DISCONNECT [96.47.72.80]:25 ---snip--- Debugging the github issue with more tls verbosity (note that the server certs is presented two times, once at the beginning, once at the end, one time with verify=0, one time with verify=1, whatever this means here): ---snip--- Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: SSL_connect:TLSv1.3 read encrypted extensions Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: in-8.smtp.github.com[140.82.114.32]:25: depth=0 verify=0 subject=/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=*.smtp.github.com Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: in-8.smtp.github.com[140.82.114.32]:25: depth=2 verify=1 subject=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: in-8.smtp.github.com[140.82.114.32]325C depth=1 verify=1 subject=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1 Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: in-8.smtp.github.com[140.82.114.32]:25: depth=0 verify=1 subject=/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=*.smtp.github.com ... Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: server certificate verification failed for in-8.smtp.github.com[140.82.114.32]:25: num=62:hostname mismatch Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: in-8.smtp.github.com[140.82.114.32]:25: subject_CN=*.smtp.github.com, issuer_CN=DigiCert TLS RSA SHA256 2020 CA1, fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:91:07:32:90:A5:EC:39:54:10:C3:40:E0:93:D0:3B:43:36:A0:45:1B, pkey_fingerprint=8E:41:0A:98:75:E4:25:83:7A:02:32:67.6A.30:A4:13:7C:E3:C7:61:16:99:E9:CF:3B:0F:58:02:72:FA:F3:48 ---snip--- With the same tls verbosity the FreeBSD.org server above does not provide the server cert two times. If I now use posttls-finger I'm able to get a verified connection if I specify -P to the cert-store: ---snip--- # posttls-finger -c reply.github.com posttls-finger: certificate verification failed for in-10.smtp.gith
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-11-30 15:03, schrieb Bill Cole via Postfix-users: On 2023-11-30 at 08:03:09 UTC-0500 (Thu, 30 Nov 2023 14:03:09 +0100) Alexander Leidinger via Postfix-users is rumored to have said: My main.cf contains the same certs-path for smtp and smtpd TLS connections: ---snip--- # grep CApath main.cf smtp_tls_CApath = /etc/ssl/certs smtpd_tls_CApath = /etc/ssl/certs ---snip--- What I see in the failure case is: ---snip--- Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: CONNECT to [140.82.112.31]:25 Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: server certificate verification failed for in-9.smtp.github.com[140.82.112.31]:25: num=62:hostname mismatch That is the error. The hostname your TLS configuration is probably expecting for that connection is reply.github.com, but that's apparently just a mail domain, not a hostname, and the machines acting as MXs for it don't use a certificate with that name. Why should it expect reply.github.com? The MX record lists in-9.smtp.github.com as a MX, postfix is connecting to it, the cert has *.smtp.github.com, and as such it should match the hostname. This has nothing to do with the email address I want to deliver to this server. I can let point the MX of leidinger.net to generic.imaginary.mail.provider.com, and as long as this provider has a valid cert for itself, the TLS connection should verify, no matter if this mail server acceps mail for leidinger.net or not. The same is true for the working connection to freebsd.org. It is connecting to mx1.freebsd.org which is not at all the same as the maildomain @freebsd.org I used, and it doesn't fail. You can probably make it work for this case with suitable special-casing in your configuration, but your configuration is a total mystery to us... Also, I wouldn't consider it a worthwhile effort for most systems, but that's your call for your environment. You removed the part where posttls-finger is able to verify the connection if I add -P /etc/ssl/cert, but postfix isn't, and it is using the same cert store. So there is a mismatch between postfix and postls-finger on a TLS connection level which to my understanding shall not happen. The config: ---snip--- # postconf -n | grep tls smtp_tls_CApath = /etc/ssl/certs smtp_tls_chain_files = $smtpd_tls_chain_files smtp_tls_connection_reuse = yes smtp_tls_fingerprint_digest = sha256 smtp_tls_mandatory_ciphers = high smtp_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtp_tls_note_starttls_offer = yes smtp_tls_policy_maps = hash:/my/tls_policy, mysql:/my/tls-policy.cf smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:$data_directory/smtp_scache smtp_tls_session_cache_timeout = 36000s smtpd_tls_CApath = /etc/ssl/certs smtpd_tls_ask_ccert = yes smtpd_tls_auth_only = yes smtpd_tls_chain_files = /my/keys_and_chain_files smtpd_tls_dh1024_param_file = /my/dh_2048.pem smtpd_tls_dh512_param_file = /my/dh_512.pem smtpd_tls_eecdh_grade = auto smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_exclude_ciphers = export, weak, medium, low, SEED, RSA, CAMELIA, aNULL, eNULL, 3DES, MD5, EXP, PSK, SRP, DSS, RC4, SHA1 smtpd_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtpd_tls_protocols = !SSLv2, !SSLv3 , !TLSv1 , !TLSv1.1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/my/smtpd_scache smtpd_tls_session_cache_timeout = 36000s tls_high_cipherlist = ALL:!RSA:!CAMELLIA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SHA1:!SHA256:!SHA384; tls_preempt_cipherlist = yes tls_random_source = dev:/dev/urandom tls_ssl_options = NO_COMPRESSION ---snip--- And the tls policy map contains nothing for github. This is with postfix 3.8.3. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-11-30 16:53, schrieb Wietse Venema via Postfix-users: Alexander Leidinger via Postfix-users: What is wrong here that [tlsproxy] doesn't establish a trusted connection to the github mailservers when posttls-finger is able to do that with the same cert store? Because there are differences between tlsproxy and posttls-finger. 1) Different executable files may be subject to different SeLinux, AppArmor etc. policies. This is FreeBSD, no different policies. 2) Different privileges: tlsproxy runs as the "postfix" user, posttls-finger as "root". Ok. The cert store permissions are OK. Any ordinary user is able to read it. posttls-finger as any other user (incl. postfix) produces the same output. With -P it verifies the cert, without it it doesn't. So still the question why the same configured cert store (posttls-finger + postfix + @FreeBSD.org + @reply.github.com) works for sending mail to FreeBSD.org but not to github.com. 3) Different certificate stores, when tlsproxy may runs chrooted, and posttls-finger does not. No chroot-difference between both. This runs in a FreeBSD jail (like a container or a Solaris zone) and I was logged into this container, so both have seen the same filesystem content. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-11-30 18:36, schrieb Viktor Dukhovni via Postfix-users: On Thu, Nov 30, 2023 at 03:37:02PM +0100, Alexander Leidinger via Postfix-users wrote: > > Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: server certificate > > verification failed for in-9.smtp.github.com[140.82.112.31]:25: > > num=62:hostname mismatch > > That is the error. Indeed that's the issue. The SANs in the certificate don't match the name matching settings for this destination. > The hostname your TLS configuration is probably expecting for that > connection is reply.github.com, but that's apparently just a mail > domain, not a hostname, and the machines acting as MXs for it don't use > a certificate with that name. Why should it expect reply.github.com? Because that name is securely known from the recipient address. But it doesn't matter. If I use a commercial spam filter solution in the cloud, I would have to set my MX to a hostname I can't control and which is not in any relation to my own domain name. If then someone send mails to alexan...@leidinger.net, why should it match the hostname against leidinger.net? My MX is mailgate.leidinger.net, it has a SAN with mailgate.leidinger.net, and I expect the sending MTA to match the hostname in the MX against the SAN of the cert. I do not expect it to match against leidinger.net. If I set the MX of leidinger.net to smtp.google.com, I expect the delivering MTA to check the SAN against smtp.google.com, and not against leidinger.net. How else can you use a Google workspace offering as a MX for your own domain (https://support.google.com/a/answer/9222085?hl=en#zippy=%2Cstep-sign-in-to-your-domain-host%2Cstep-add-the-mx-record)? The MX record lists in-9.smtp.github.com as a MX, http://www.postfix.org/TLS_README.html#client_tls_limits The MX hostname is typically obtained via an insecure (subjet to MiTM tampering) DNS lookup, so you lose all security when validating certificates against the payloads of MX records. You (and the link) are talking about trust. I talk about the technical operation of establishing a TLS connection and verifying the certificate. The validation itself has nothing to do with trust. The technical operation takes a hostname to validate the SAN in the cert against, and a cert-chain to validate it against. Trust is orthogonal to this. I agree with all what is written in the link and what you said about insecure (if no DNSSEC is used), but this is trust, not technical validation. The technical problem I have is that postfix seems to use parts of the cert store (it validates the MX of FreeBSD, but not the MX of github), whereas posttls-finger uses the complete cert store. As answered to Wietse, the cert store is readable no permission problem, no user access problem, no security polcies, no chroot. He didn't tell that posttls-finger uses a different validation policy than postfix. If I understand it correctly: if both have the same access to the cert store and the network, they should produce the same result (valid or not valid). They don't. I want to solve this technical problem and let them both agree, that the cert is valid (which it is, the SAN of the MX of github has *.smtp.github.com, and this is a match from a certificate validation point of view with the hostname the MX presents). This has nothing to do with the email address I want to deliver to this server. See above. You're missing the point. I agree that we are talking about 2 different things. Please tell me what is wrong about: - the MX of domain A.c points to a.B.c - a sending MTA has to take a.B.c and match it against the SAN the server a.B.c provides (ignoring details of doing a reverse lookup and resolving the resulting IP and validating that too) In HTTP the name to match against what is provided by the user in the URL, in SMTP it is the MX, as the domain part of the email address is not at all significant for the name of the MX (see above the Google workspace example). So there is a mismatch between postfix and postls-finger on a TLS connection level which to my understanding shall not happen. No, there's a mismatch between the configuration of your Postfix SMTP client and what you posttls-finger was asked to do. That's the reason why I come her and ask what I do wrong. I agree that there is a difference between the operation of both. I want to have both to agree. What do I have to do to the MTA, to let it agree with the result of posttls-finger? Where shall I look for which problem? Which part of my config is affecting that and should check for X or provide for inspection? What can I do to drill down more? Tracing which part of postfix (ktrace (like strace), dtrace... whatever), looking for what action/access/...? smtp_tls_policy_maps = hash:/my/tls_policy, mysql:/my/tls-policy.cf This must be matching "repl
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 09:34, schrieb Tom Hendrikx via Postfix-users: On 01-12-2023 08:59, Alexander Leidinger via Postfix-users wrote: Am 2023-11-30 16:53, schrieb Wietse Venema via Postfix-users: Alexander Leidinger via Postfix-users: What is wrong here that [tlsproxy] doesn't establish a trusted connection to the github mailservers when posttls-finger is able to do that with the same cert store? Because there are differences between tlsproxy and posttls-finger. 1) Different executable files may be subject to different SeLinux, AppArmor etc. policies. This is FreeBSD, no different policies. 2) Different privileges: tlsproxy runs as the "postfix" user, posttls-finger as "root". Ok. The cert store permissions are OK. Any ordinary user is able to read it. posttls-finger as any other user (incl. postfix) produces the same output. With -P it verifies the cert, without it it doesn't. So still the question why the same configured cert store (posttls-finger + postfix + @FreeBSD.org + @reply.github.com) works for sending mail to FreeBSD.org but not to github.com. 3) Different certificate stores, when tlsproxy may runs chrooted, and posttls-finger does not. No chroot-difference between both. This runs in a FreeBSD jail (like a container or a Solaris zone) and I was logged into this container, so both have seen the same filesystem content. There still seems to be a disconnect in communication here, as you didn't quote Viktors response on 'smtp_tls_policy_maps', which seems to be the key issue here. The policy in your connection to github seems to be 'verify' or higher. I was simply not fast enough for you to answer to his mail. :) I just answered. In short: no this is not the key issue here. I don't care right now if my mail to github is deliverd. My point right now is the TLS communication only. See my answer to his mail for the details. Maybe you could test again with an empty 'smtp_tls_policy_maps' parameter in postfix config, or show all values in your policy map explicitly (which might be difficult due to mysql usage)? Short: I overlooked a line in the DB. But right now the delivery is not my concern. I could easily change the DB but will let it as it is to not need to change something somewhere to test the TLS part against github. More in my other answer. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 12:08, schrieb Byung-Hee HWANG via Postfix-users: ... Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: server certificate verification failed for in-8.smtp.github.com[140.82.114.32]:25: num=62:hostname mismatch ... Maybe you check? root@yw-1204:/etc/postfix# postconf -n | grep CAfile smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt # postconf -n | grep tls_CA smtp_tls_CApath = /etc/ssl/certs smtpd_tls_CApath = /etc/ssl/certs Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 11:22, schrieb Viktor Dukhovni via Postfix-users: On Fri, Dec 01, 2023 at 09:53:25AM +0100, Alexander Leidinger via Postfix-users wrote: > > Why should it expect reply.github.com? > > Because that name is securely known from the recipient address. Because, whether you're willing to understand the point or prefer to "dig in", verifying a certificate against an attacker-supplied name is pointless. You gain no security by checking attacker-supplied names. You want to deposit a bunch of cash into your bank account, I meet you in a bar wearing a name tag that says I'm the manager of your bank, you give me a hefty sum of money in cash to deposit into your account... This is not a problem which can be solved in a purely technical manner for SMTP in an automated way (= deploy this new MTA and it works). It needs an incompatible redesign of sending "email" with the buy-in of the world. I'm well aware of that. If then someone send mails to alexan...@leidinger.net, why should it match the hostname against leidinger.net? Because that's the only name worth verifying, otherwise skip the potential delivery issues and don't verify. My MX is mailgate.leidinger.net, it has a SAN with mailgate.leidinger.net, and I expect the sending MTA to match the hostname in the MX against the SAN of the cert. An active attacker can replace "your" MX with "send.money.now" for which he has a handy certificate from Let's Encrypt. Yes. I'm fully aware of that. TLS in SMTP can not make sure it delivers to the person I intended it to be delivered to. It also doesn't make sure nobody else than the recipient is able to read the mail. The same way a snail mail can not prevent someone from intercepting the envelope, and having a look inside. But like a double-envelope in snail mail, TLS is able to prevent a bystander (e.g. my ISP) besides the post-delivery-person to have a peek at what is written (like the difference between a postcard and a letter in an envelope). > The MX hostname is typically obtained via an insecure (subjet to MiTM > tampering) DNS lookup, so you lose all security when validating > certificates against the payloads of MX records. You (and the link) are talking about trust. Really about the futility of going through the motions of verifying certificates in the absence of trustworthy "reference identifiers". An attacker has to go through a lot of hops to break DNSSEC to make a man in the middle attack (yes, github is not DNSSEC protected, leidinger.net isn't either). There are cases where it is good enough for my use case. For my use case with github, I do not depend on validating the authenticity of the remote host. I'm even not depending on the privacy feature of TLS in terms of github. I talk about the technical operation of establishing a TLS connection and verifying the certificate. You can go through the motions if you want, but it won't achieve any security goals. Not with github. I fully agree. With github it was about the technical issues I wanted to understand and solve (and it is solved now, see below). The technical problem I have is that postfix seems to use parts of the cert store (it validates the MX of FreeBSD, but not the MX of github), whereas posttls-finger uses the complete cert store. No. The problem you're reporting is with name matching. If the certificate chain failed to be constructed, that'd be reported instead. You'll only see name match errors if the chain construction succeeds, but the peer name matching fails. Great to know. I didn't before you told me. Can I suggest to add this information to the TLS readme? As answered to Wietse, the cert store is readable no permission problem, no user access problem, no security polcies, no chroot. As evidenced by the fact that you got a name matching problem. He didn't tell that posttls-finger uses a different validation policy than postfix. The "postls-finger" program will default to "dane" or (absent DANE TLSA records) "secure", rather than "may" in order to improve your odds of meaningfully testing the remote cert chain. github is not DNSSEC protected, as such - if I understand the TLS readme correctly, postfix will not use DANE. As such I assume, posttls-finger will not use DANE too. The tls policy for github.com was secure in postfix, but I may have overlooked what posttls-finger is doing if there is no dane record. By experimantation I now think it is falling back to "verify" in that case. At least the output between "-l may", "-l secure" and "-l verify" lead me to this assumption. May I suggest to add a comment to the man page of posttls-finger in this regard? Otherwise, it uses default settings, but you have a policy
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 12:40, schrieb Byung-Hee HWANG via Postfix-users: Alexander Leidinger via Postfix-users writes: Am 2023-12-01 12:08, schrieb Byung-Hee HWANG via Postfix-users: ... Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: server certificate verification failed for in-8.smtp.github.com[140.82.114.32]:25: num=62:hostname mismatch ... Maybe you check? root@yw-1204:/etc/postfix# postconf -n | grep CAfile smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt # postconf -n | grep tls_CA smtp_tls_CApath = /etc/ssl/certs smtpd_tls_CApath = /etc/ssl/certs My test logshot: Dec 1 11:33:07 yw-1204 postfix/pickup[57397]: 7AB329A3: uid=1000 from= Dec 1 11:33:07 yw-1204 postfix/cleanup[59196]: 7AB329A3: message-id=<20231201113307.7ab32...@yw-1204.doraji.xyz> Dec 1 11:33:07 yw-1204 opendkim[637]: RFC2822-From: Byung-Hee HWANG Dec 1 11:33:07 yw-1204 opendkim[637]: RFC2821-From: soyeo...@yw.doraji.xyz Dec 1 11:33:07 yw-1204 opendkim[637]: RFC2821-To: devn...@reply.github.com Dec 1 11:33:07 yw-1204 opendkim[637]: 7AB329A3: DKIM-Signature field added (s=yw-1204-doraji-xyz, d=doraji.xyz) Dec 1 11:33:07 yw-1204 postfix/qmgr[54966]: 7AB329A3: from=, size=394, nrcpt=1 (queue active) Dec 1 11:33:08 yw-1204 postfix/smtp[59204]: Trusted TLS connection established to in-5.smtp.github.com[140.82.113.31]: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 Dec 1 11:33:09 yw-1204 postfix/smtp[59204]: 7AB329A3: to=, relay=in-5.smtp.github.com[140.82.113.31]:25, delay=1.6, delays=0.01/0.01/1.2/0.34, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as BE91F5E034E) Dec 1 11:33:09 yw-1204 postfix/qmgr[54966]: 7AB329A3: removed Actually i have no problem. So Again you need to do double check CAfile things in main.cf ;;; No, it's a pure security policy thing and an overlooked line in the mysql tls policy table. The policy "secure" (and I assume "dane-only") doesn't work, as github is not using DNSSEC. Valid policies which make this work are "verify", "may" and I assume "dane" (if you have "smtp_tls_security_level = may" or verify resp. "smtpd_tls_security_level = may" or verify). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 13:44, schrieb Wietse Venema: Alexander Leidinger: Am 2023-11-30 16:53, schrieb Wietse Venema via Postfix-users: > Alexander Leidinger via Postfix-users: >> What is wrong here that [tlsproxy] doesn't establish a trusted >> connection >> to the github mailservers when posttls-finger is able to do that with >> the same cert store? > > Because there are differences between tlsproxy and posttls-finger. > > 1) Different executable files may be subject to different SeLinux, > AppArmor etc. policies. This is FreeBSD, no different policies. > 2) Different privileges: tlsproxy runs as the "postfix" user, > posttls-finger as "root". ... > 3) Different certificate stores, when tlsproxy may runs chrooted, > and posttls-finger does not. As Viktor poointed out 4) Diferent certificate match expectations. May I suggest to add a note or two to the man page of posttls-finger in the sense that posttls-finger doesn't look at the postfix config and is standalone, and that if configure with TLS support the default is (as documented) "-l dane" but that this fall back to "-l verify" (at least according to my experiment) if the domein is not DNSSEC enabled? I also suggest to add a note to the TLS readme that if the policy is secure and the chain validates, but the hostname doesn't match what postfix expects (it would also be good if it would print the hostname it expects in the default log level), that it prints the hostname mismatch error. It would also be nice if it is documented what it prints when the certificate chain doesn't validate in that case. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 18:51, schrieb Viktor Dukhovni via Postfix-users:
On Fri, Dec 01, 2023 at 01:52:19PM +0100, Alexander Leidinger wrote:
> No. The problem you're reporting is with name matching. If the
> certificate chain failed to be constructed, that'd be reported instead.
> You'll only see name match errors if the chain construction succeeds,
> but the peer name matching fails.
Great to know. I didn't before you told me. Can I suggest to add this
information to the TLS readme?
That would Postfix documenting OpenSSL library behaviour, and is not
something we can promise as a stable Postfix feature. It just so
happens that OpenSSL first builds a chain, and then verifies various
conditions. Perhaps building the chain first is unavoidable, because
that can bring in name constraints, or other limitations that make the
leaf certififate invalid. So this is unlikely to change, but is not
something Postfix implements or influences.
But it's something postfix uses and it would be possible to tell that at
the time of writing the docs, this is the behavior and that this is
something which is not controlled by postfix but openssl. The info this
would provide is very valuable to understand at which level the problem
happens (in this case the chain was ok, but the hostname didn't match
the expectation). In an ideal world, postfix would even print the info
that this is because of the "secure" policy and that the lower "verify"
policy would have resulted in success.
> The "postls-finger" program will default to "dane" or (absent DANE TLSA
> records) "secure", rather than "may" in order to improve your odds of
> meaningfully testing the remote cert chain.
github is not DNSSEC protected, as such - if I understand the TLS
readme
correctly, postfix will not use DANE. As such I assume, posttls-finger
will
not use DANE too.
Correct. Therefore "posttls-finger" will use the "secure" level, and
its matching policy:
This doesn't match my testing. See below.
The tls policy for github.com was secure in postfix, but I may have
overlooked what posttls-finger is doing if there is no dane record. By
experimantation I now think it is falling back to "verify" in that
case.
Actually "secure", which means that the match strategy is
"nexthop:dot-nexthop" unless you specify additional command-line
arguments to override the match list.
switch (state->level) {
case TLS_LEV_SECURE:
state->match = argv_alloc(2);
while (*argv)
argv_add(state->match, *argv++, ARGV_END);
if (state->match->argc == 0)
argv_add(state->match, "nexthop", "dot-nexthop", ARGV_END);
break;
case TLS_LEV_VERIFY:
state->match = argv_alloc(1);
while (*argv)
argv_add(state->match, *argv++, ARGV_END);
if (state->match->argc == 0)
argv_add(state->match, "hostname", ARGV_END);
break;
case TLS_LEV_FPRINT:
state->dane = tls_dane_alloc();
while (*argv)
tls_dane_add_fpt_digests(state->dane,
state->options.enable_rpk,
*argv++, "", smtp_mode);
break;
...
This would suggest that no -l option should show the same behavior than
"-l secure". This is not the case for the situation I tested (no DNSSEC
for github, as such DANE can not be used, and the default of "secure"
should print "Untrusted" instead of "Verified"):
---snip---
# posttls-finger -c -P /etc/ssl/certs reply.github.com
posttls-finger: in-5.smtp.github.com[140.82.113.31]:25: matched
peername: *.smtp.github.com
posttls-finger: in-5.smtp.github.com[140.82.113.31]:25:
subject_CN=*.smtp.github.com, issuer_CN=DigiCert TLS RSA SHA256 2020
CA1,
fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:91:07:32:90:A5:EC:39:54:10:C3:40:E0:93:D0:3B:43:36:A0:45:1B,
pkey_fingerprint=8E:41:0A:98:75:E4:25:83:7A:02:32:67:6A:30:A4:13:7C:E3:C7:61:16:99:E9:CF:3B:0F:58:02:72:FA:F3:48
posttls-finger: Verified TLS connection established to
in-5.smtp.github.com[140.82.113.31]: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 -c -l secure -P /etc/ssl/certs reply.github.com
posttls-finger: server certificate verification failed for
in-7.smtp.github.com[140.82.114.31]:25: num=62:hostname mismatch
posttls-finger: in-7.smtp.github.com[140.82.114.31]:25:
subject_CN=*.smtp.github.com, issuer_CN=DigiCert TLS RSA SHA256 2020
CA1,
fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:91:07:32:90:A5:EC:39:54:10:C3:40:E0:93:D0:3B:43:36:A0:45:1B,
pkey_fingerprint=8E:41:0A:98:75:E4:25:83:7A:02:32:67:6A:30:A4:13:7C:E3:C7:61:16:99:E9:CF:3B:0F:58:02:72:FA:F3:48
posttls-finger: Untrusted TLS connection established to
in-7.smtp.github.com[140.82.114.31]: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
---snip---
At least the ou
[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers
Am 2024-02-28 14:55, schrieb Scott Hollenbeck via Postfix-users:
Would someone please describe the configuration settings needed to
support
TLS 1.2 and 1.3 with no weak ciphers? Here's what I currently have in
my
That depends on your definition of "weak".
configuration files:
main.cf:
smtpd_tls_cert_file=/etc/letsencrypt/live/mysite.net/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/mysite.net/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_mandatory_ciphers = high
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_dh1024_param_file = /etc/ssl/private/dh2048.pem
smtpd_tls_dh512_param_file = /etc/ssl/private/dh512.pem
Don't take the following as-is. Research what each option is doing, your
milage may vary. Others may have other opinions.
# grep tls main.cf | grep -vE '^#'
smtp_tls_session_cache_database = btree:$data_directory/smtp_scache
smtp_tls_security_level = encrypt
smtp_tls_session_cache_timeout = 3600s
smtp_tls_mandatory_ciphers = high
smtp_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1
smtp_tls_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1
tls_random_source = dev:/dev/urandom
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_connection_reuse = yes
smtpd_tls_chain_files = /usr/local/etc/postfix/ssl/outgoing_key.pem
smtp_tls_chain_files = $smtpd_tls_chain_files
smtpd_tls_dh1024_param_file = /usr/local/etc/postfix/ssl/dh_2048.pem
smtpd_tls_dh512_param_file = /usr/local/etc/postfix/ssl/dh_512.pem
smtpd_tls_ask_ccert = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_CApath = $smtp_tls_CApath
smtpd_tls_eecdh_grade = auto
smtpd_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1
smtpd_tls_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1
smtpd_tls_mandatory_ciphers=high
smtp_tls_policy_maps = hash:/usr/local/etc/postfix/tls_policy
smtp_tls_fingerprint_digest = sha256
tls_high_cipherlist=ALL:!RSA:!CAMELLIA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SHA1:!SHA256:!SHA384;
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION
This gives (nmap 7.94):
PORT STATE SERVICE VERSION
25/tcp open smtpPostfix smtpd
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (ecdh_x25519) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CCM (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_AES_256_CCM_8 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CCM_8 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CCM (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (ecdh_x25519) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CCM (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_AES_128_CCM_8 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| T
[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers
Am 2024-02-29 10:27, schrieb Viktor Dukhovni via Postfix-users: On Thu, Feb 29, 2024 at 08:59:44AM +0100, Alexander Leidinger via Postfix-users wrote: # grep tls main.cf | grep -vE '^#' smtp_tls_security_level = encrypt smtpd_tls_ask_ccert = yes smtpd_tls_CApath = $smtp_tls_CApath Not generally applicable. I agree. Therefore my comment to not take it blindly. What is good for the partiuclar server where I took this from, may not be suitable for everyone. smtp_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtp_tls_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtpd_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtpd_tls_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 Obsolete syntax. This config has history... tls_random_source = dev:/dev/urandom smtpd_tls_eecdh_grade = auto Best defaulted. smtp_tls_CApath = /etc/ssl/certs Pointless except when the security level is "secure" (or "verify"). You deleted the smtp_tls_policy_maps setting where this may or may not make sense for users... tls_high_cipherlist=ALL:!RSA:!CAMELLIA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SHA1:!SHA256:!SHA384; Not recommended. It disables all non-AEAD ciphers, and aNULL ciphers, which are fine to use. From the OpenSSL man page: ---snip--- aNULL The cipher suites offering no authentication. This is currently the anonymous DH algorithms and anonymous ECDH algorithms. These cipher suites are vulnerable to "man in the middle" attacks and so their use is discouraged. These are excluded from the DEFAULT ciphers, but included in the ALL ciphers. Be careful when building cipherlists out of lower-level primitives such as kDHE or AES as these do overlap with the aNULL ciphers. When in doubt, include !aNULL in your cipherlist. ---snip--- As I said, this should not be taken blindly. Best is to adapt it to the local security guidelines. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers
Am 2024-02-29 13:46, schrieb Viktor Dukhovni via Postfix-users: On Thu, Feb 29, 2024 at 06:36:09AM -0500, Scott Hollenbeck wrote: > What do you consider weak? All of the anonymous Diffie-Hellman suites with an "F" score. How can eliminate the following: Who's assigning the "F" scores? Nmap is telling this about the scores: ---snip--- Each ciphersuite is shown with a letter grade (A through F) indicating the strength of the connection. The grade is based on the cryptographic strength of the key exchange and of the stream cipher. The message integrity (hash) algorithm choice is not a factor. The output line beginning with Least strength shows the strength of the weakest cipher offered. The scoring is based on the Qualys SSL Labs SSL Server Rating Guide, but does not take protocol support (TLS version) into account, which makes up 30% of the SSL Labs rating. ---snip--- The corresponding Qualys reference is: https://www.ssllabs.com/projects/rating-guide/ Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix + Dovecot FreeBSD - a problem
Am 2024-03-11 05:19, schrieb Glenn Tenney via Postfix-users: (2) Postfix sends to gmail, but does not encrypt when sending. You only tell the receiving side of postfix to set the encrypt level to "may". For the sending side you do not have such a setting: smtp_tls_security_level = ... Maybe you also want to set the TLS protocols for the sending side (sending and receiving side have different config options, "smtp_..." vs "smtpd_..."): smtp_tls_protocols = ... smtp_tls_CApath = /etc/ssl/certs smtp_tls_loglevel = 1 smtpd_tls_cert_file = /usr/local/etc/letsencrypt/live/domain.name/fullchain.pem smtpd_tls_key_file = /usr/local/etc/letsencrypt/live/domain.name/privkey.pem smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_security_level = may smtpd_use_tls = yes Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix + Dovecot FreeBSD - a problem
Am 2024-03-12 07:08, schrieb Viktor Dukhovni via Postfix-users: Where is your configuration directory? Are you editing "/etc/postfix/main.cf", or /usr/local/etc/postfix/main.cf? Which "postfix" command are you running, "/usr/sbin/postfix" or "/usr/local/sbin/postfix"? You probably have Postfix both in the base system and from ports. Make sure you're editing the files and using the commands from /usr/local... And that the Postfix that is running (master process, and service daemons) are also the ones from /usr/local/libexec... If there is postfix not only in /usr/local/, but also in /, there is a big problem. There is no postfix supposed to be in / in FreeBSD, it shall only be in /usr/local/. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?
Am 2024-03-23 15:58, schrieb Matthias Nagel via Postfix-users: I wonder whether setting `smtpd_tls_dh1024_param_file` to a custom 2048-bit DH group would help? But from my understanding of the docs that should not be necessary as Postfix 3.8.5 uses a built-in 2048bit group if left empty. Postfix doesn't complain if you configure it this way (I tried). I don't know if it does what you want to do (I have a custom cipher spec I allow). You could install a test-instance and test with nmap: - "nmap -p --script ssl-enum-ciphers ", pay attention to the part "(dh ...)" in the output Do a scan before and after the smtpd_tls_dh1024_param_file change. PS: As of January 2024, the German BSI has tighten its recommendation for asymmetric algorithms over finite fields to at least 3000 bits (i.e. RSA encryption, RSA signatures and FFDH). If this is as a result of an audit, or in preparation of an audit: have a look if it helps to talk with the auditors. Sometimes they are open to arguments (cleartext is allowed, dh 1024 is better than cleartext). If they only look at checkboxes to tick, see the part above or disabling the parts as you suggested (you could increase the smtpd_tls_loglevel to 1 and check over a suitable amount of time if someone is using those ciphers you want to disable before you actually disable them). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?
Am 2024-03-23 17:17, schrieb Viktor Dukhovni via Postfix-users: PS: As of January 2024, the German BSI has tighten its recommendation for asymmetric algorithms over finite fields to at least 3000 bits (i.e. RSA encryption, RSA signatures and FFDH). With little thought about the opportunistic TLS use-case. I'm not claiming to know what the rationale is, but one possible thought-chain could be: IF there is no MITM, and IF the session is encrypted, then at least use good encrpytion so that an attacker which is only able to listen, is not able to get the content. Also: this is not a specific recommendation for SMTP, it is a generic recommendation for encrypted communication independent from the context it is used in, so there may be no thought at all about opportunistic TLS. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Is there a way to just quickly deliver "everything" to a file somewhere
Am 2024-04-11 05:39, schrieb Dan Mahoney via Postfix-users: I guess I missed something. — I also want it to null route (or route to a maildir) all *outbound* mail — so we can examine what our ticket system *would* send, is there something in here to do that, or is the above only for inbound? Would this work for your use case? https://serverfault.com/questions/219173/configure-postfix-to-filter-email-into-hold-queue Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy
Am 2024-05-22 01:22, schrieb Greg Sims via Postfix-users: TLS connection reuse is being used. About 10% of the connections are reused for large volume ISPs. Small volume ISPs do not see connection reuse. I believe this is as expected. I did some testing of our DNS setup. A DNS query using dig is less than 20 msec for both our primary and secondary dns servers in /etc/resolv.conf -- see below. If all else fails: The truth can often be seen on the wire. Make a packet trace which covers the time from "here is the mail you have to send to google" to a successful delivery and inspect it in wireshark. For TLS traffic you need the cert/key in wireshark. Do not only trace the smtp traffic, but all traffic. Inspect what the system is doing (e.g. DNS lookups) and correlate that to the traffic you see (you can change how timestamps are displayed in wireshark). This may indicate where those 25 seconds are spend. This is a steep learning curve if you are not familiar already with interpreting network packets, the smtp protocol, DNS, and wireshark. If those skills are already available, it may lead to detecting the cause of what you see faster than the back and forth with guesses here on the mailinglist. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Troubleshooting roundcube connections to postfix
Am 2024-06-17 06:49, schrieb Paul Schmehl via Postfix-users: On Jun 16, 2024, at 10:30 PM, Peter via Postfix-users wrote: It's likely that roundcube is not configured for TLS and postfix is (as it should be) configured not to offer AUTH until TLS is established. Yes, postfix is configured to use TLS, and no roundcube is not. When I configure roundcube to connect using TLS it can’t even connect to the server. I don’t understand what’s going on with roundcube, but it’s definitely not behavior I would expect. It’s had me pulling my hair out for two days, and I don’t even have any hair. This makes roundcube use STARTTLS on port 587 (submission): ---snip--- $config['smtp_host'] = 'tls://your.smtp.server'; $config['smtp_port'] = 587; ---snip--- Other useful stuff for roundcube: ---snip--- // SMTP username (if required) if you use %u as the username Roundcube // will use the current username for login $config['smtp_user'] = '%u'; // SMTP password (if required) if you use %p as the password Roundcube // will use the current user's password for login $config['smtp_pass'] = '%p'; // Log sent messages to /sendmail.log or to syslog $config['smtp_log'] = true; ---snip--- I’m hoping I have solved the problem. I have roundcube sending mail on port 25 with no auth (all daemons are running on the same server), and it is sending mail. Gmail rejects it, but I’ve altered my spf record to include localhost. I hope once that propagates my problems with be solved. Probably not related to the gmail issue: you may want to remove some headers. I have those header checks to not expose some stuff from roundcube: main.cf: ---snip--- smtp_header_checks = pcre:$config_directory/header_checks ---snip--- $config_directory/header_checks: ---snip--- /^Received: by your\.smtp\.server .*from userid [0-9]+\)/ IGNORE /^Received: from www \(uid 80.*/ IGNORE /^(Received: from your\.roundcube\.server)[^\n]*(.*)/ REPLACE $1 (localhost [127.0.0.1])$2 ---snip--- Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REJECT sending mails to no-reply accounts
Am 2024-06-20 08:21, schrieb Peter via Postfix-users: On 20/06/24 17:47, Tan Mientras via Postfix-users wrote: So many replies! @Ralph Is an automated/unattended email notifying the user about something, providing proper ways of contacting. As this email is not read in any way, rejecting the mail would be a better way to handle than an automatic response. IMHO. A better way would be to set the From: address to someone that will actually respond from your organization (e.g. info@, help@, etc). This implies that the organization / company is willing to spend money on having someone available to actually respond / provide support. For a lot of the use cases I would say even a mail to ticket system gateway is out of the willingness to spend money on. So any technical solution you can propose here, will be way out of the area of interest of those people which will make those decisions. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and STS
Am 2024-06-25 08:44, schrieb Jeff Pang via Postfix-users: Hello sorry for the beginner question. how to deploy the following email security features? RFC 7672 SMTP-DANE Outgoing: # validate DANE smtp_dns_support_level = dnssec smtp_tls_security_level = dane # or dane-only (https://www.postfix.org/TLS_README.html) Incoming: - setup DNSSEC for your domain (out of scope here on the postfix list) - publish TLSA records e.g. https://www.sidn.nl/en/news-and-blogs/hands-on-implementing-dane-in-postfix (not everything there is endorsed by several people on this list, specially not the TLS settings in part IV (interoperability vs. "do you really know what you are doing"), what you have to do depends on what you need to protect against (or which checkboxes you have to tick in a report), I provide this link as it gives a good overview about what is involved, not about the particular settings (e.g. you may want to skip large parts of part IV), you may want to use letsencrypt or similar instead of a self-signed cert, you may want to use the PKI cert in the TLSA record (or not), ...). RFC 8461 MTA-STS Incoming (out of scope for the postfix list): - setup of webserver which serves the MTA-STS file - DNS records e.g. https://www.digitalocean.com/community/tutorials/how-to-configure-mta-sts-and-tls-reporting-for-your-domain-using-apache-on-ubuntu-18-04 (info: there exist online services and local tools to investigate TLSA reports) Outgoing: Postfix doesn't come with support for this out of the box. There is https://github.com/Snawoot/postfix-mta-sts-resolver but it has drawbacks (pointed out in the docu). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure
Am 2024-06-28 09:01, schrieb Curtis J Blank via Postfix-users: What I am looking for is pretty simple. How to get it to work with "inet_protocols = all" like my existing server is currently set up to do and not be limited to ipv4 only. And it is already set to use 127.0.0.1 so why it is using [::1] instead when the old server uses 127.0.01, that is part of the mystery. The configs are exactly the same yet they operate differently. I want to know why. If you don't know and understand the root cause of something that is not a good position to be in going forward. Good enough is not good enough... Did you already validate (netstat -tnl) that spamassassin listens on both addresses, 127.0.0.1 and ::1? Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Documentation Prefix
Am 2024-07-08 06:52, schrieb Ralph Seichter via Postfix-users: * Allen Coates via Postfix-users: I am blocking 2001:db8::/32 (of course); it's the Teredo prefix which I am allowing. I misunderstood the word "these" in your OP, and the subject line only referenced the documentation prefix, but no harm done. I don't have any numbers for connections from Teredo addresses at hand either, but the services I am hosting are not aimed at specific client platforms anyway. Similar to you I am mildly curious if Teredo has any relevance beyond Xbox and a smattering of remaining Windows 10 installations these days. Windows 10 version 1803 and later disable Teredo by default. https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features -> IPv4/6 Transition Technologies As Teredo is a MS thing (invented and propagated by them), I would call it dead. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
