drop unwanted recipients
Hi all, We're using smtpd_recipient_restrictions to drop filter out unwanted recipients. The problem with this is, if the email has more recipients, noone gets the email, not only the unwanted is dropped. How should this be done properly? Thanks, Gino
postfix+tansport relay
Hi I have a postfix (for outgoing) and I have many vusers and vdomain (in mysql) Works fine but one of client have external spam fileter (like barracuda/sophos/others) and I need a filter all his outgoing e-mail (only one client vdomain or two vdomain) I thinking: cat /etc/postfix/senders.pcre /vdomain1.com/ relay:[smtp.private.fileter.barracuda] /cdomain2.com/ relay:[smtp2.private.fileter.sophos] main.cf transport_maps = regexp:/etc/postfix/senders.pcre Is a correct ? Or maybe better is hash ? --
Re: drop unwanted recipients
Gino Ferguson: > Hi all, > > > We're using smtpd_recipient_restrictions to drop filter out unwanted > recipients. > > The problem with this is, if the email has more recipients, noone > gets the email, not only the unwanted is dropped. > > How should this be done properly? If you cannot reject the recipient, discard the recipient, instead of discarding the message. /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport /etc/postfix/transport: u...@example.comdiscard: Do "postmap hash:/etc/postfix/transport" after editing the file. Wietse
Re: postfix+tansport relay
On Mon, Nov 21, 2022 at 12:08:31PM +0100, natan wrote: > one of client have external spam fileter (like > barracuda/sophos/others) and I need a filter all his outgoing e-mail > (only one client vdomain or two vdomain) > > I thinking: > > cat /etc/postfix/senders.pcre > /vdomain1.com/ relay:[smtp.private.fileter.barracuda] > /cdomain2.com/ relay:[smtp2.private.fileter.sophos] > > main.cf > transport_maps = regexp:/etc/postfix/senders.pcre > > Is a correct ? No. * Transport lookup is by recipient address, using "sender" in the file name does not magically change this. * Do not use regular expressions for transport lookups. * On what basis are barracuda or sophos willing to be an open relay for mail from this customer? I would expect some form of authentication to be required. Though perhaps your IP addresses are pinned at the provider as allowed to relay through the service. Do you understand how the filters are supposed to work? You'd have to use sender_dependent_default_transport_maps, avoid regular expressions (they are too fragile to be used correctly by most users, you included). To avoid potential loops, the settings in question should be configured only for an outbound MSA. DO NOT also process inbound mail on the same system. (Loops should not happen so long as the domains in question are not in the "default" address class, i.e. are delivered locally or are listed in "relay_domains", but best to be sure). -- VIktor.
Untrusted TLS connections where email domain does not support DNSSEC but MX server has DNSSEC/DANE records
Dear Postfix folks, With Postfix 3.6.0-RC1 and # postconf -n smtp_tls_security_level smtp_tls_security_level = dane the Postfix SMTP client logs several untrusted TLS connections for hosts with a good TLS certificate setup. It’s mainly German research organizations using the DFN-MailSupport, but also the ones using the SMTP servers of bund.de. postfix/smtp[27147]: Untrusted TLS connection established to mx1.bund.de[77.87.224.131]: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 postfix/smtp[27147]: X: to=, relay=mx1.bund.de[77.87.224.131]:25, delay=0.29, delays=0.04/0/0.07/0.18, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as XXXsomehash) posttls-finger works with level `verify`: $ posttls-finger -c -l verify -P /etc/ssl/certs rki.de posttls-finger: mx1.bund.de[77.87.224.131]:25: matched peername: mx1.bund.de posttls-finger: mx1.bund.de[77.87.224.131]:25: subject_CN=mx1.bund.de, issuer_CN=TeleSec ServerPass Class 2 CA, fingerprint=22:71:E5:D4:DB:06:07:74:0B:C5:D4:F9:7C:39:C1:C9, pkey_fingerprint=39:6E:16:A6:B6:42:14:9A:64:07:D2:E0:F6:B1:86:CF posttls-finger: Verified TLS connection established to mx1.bund.de[77.87.224.131]: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 After a while of head scratching, I thought it might have to do with the SMTP servers publishing TLSA records, but the domain in the email address does not support DNSSEC. Testing with level `dane` it indeed does mark the TLS connection as untrusted: $ posttls-finger -c -l dane -P /etc/ssl/certs rki.de posttls-finger: MX RRset insecure: log verified as trusted posttls-finger: mx1.bund.de[77.87.224.131]:25: Matched DANE EE certificate at depth 0: 3 0 1 2E5543C7522EDC151C65602F4541DC14D66182B49EA687EE9EFA2F6E3990186E posttls-finger: mx1.bund.de[77.87.224.131]:25: subject_CN=mx1.bund.de, issuer_CN=TeleSec ServerPass Class 2 CA, fingerprint=22:71:E5:D4:DB:06:07:74:0B:C5:D4:F9:7C:39:C1:C9, pkey_fingerprint=39:6E:16:A6:B6:42:14:9A:64:07:D2:E0:F6:B1:86:CF posttls-finger: Untrusted TLS connection established to mx1.bund.de[77.87.224.131]: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 My naive assumption would have been, if no DNSSEC is set up for the domain in the email address, that DANE would not be tried. The DANE SMTP Validator [1] seems to use that ordering too. Do you have suggestions how to deal with this issue? Kind regards, Paul [1]: https://dane.sys4.de/ PS: Best would be, if the operators would set up DNSSEC, but unfortunately, my attempts to convince them has been unsuccessful so far. PPS: Postfix log for helmholtz-muenchen.de with `smtp_tls_loglevel=2`: ``` 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: setting up TLS connection to c1491.mx.srv.dfn.de[194.95.238.86]:25 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH:!RC4:!aNULL:!aNULL" 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: SNI hostname: c1491.mx.srv.dfn.de 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:before SSL initialization 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write change cipher spec 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:TLSv1.3 read encrypted extensions 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: depth=0 verify=1 subject=/C=DE/ST=Berlin/O=Verein zur F\xC3\xB6rderung eines Deutschen Forschungsnetzes DFN-Verein/CN=mx .srv.dfn.de 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server certificate 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:TLSv1.3 read server certificate verify 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read finished 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write finished 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: Matched DANE EE certificate at depth 0: 3 0 1 B85BD6F
Re: Untrusted TLS connections where email domain does not support DNSSEC but MX server has DNSSEC/DANE records
On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100) Paul Menzel is rumored to have said: Dear Postfix folks, With Postfix 3.6.0-RC1 and # postconf -n smtp_tls_security_level smtp_tls_security_level = dane the Postfix SMTP client logs several untrusted TLS connections for hosts with a good TLS certificate setup. [...] I have no answer to your main question but I think I see the issue in the log below. The server sends a certificate with "issuer_CN=GEANT OV RSA CA 4" but it doesn't seem to send any intermediate certificate to build a chain back to a known root, so unless you have a trusted root locally for that issuer, the chain can't be verified. PPS: Postfix log for helmholtz-muenchen.de with `smtp_tls_loglevel=2`: ``` 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: setting up TLS connection to c1491.mx.srv.dfn.de[194.95.238.86]:25 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH:!RC4:!aNULL:!aNULL" 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: SNI hostname: c1491.mx.srv.dfn.de 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:before SSL initialization 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write change cipher spec 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:TLSv1.3 read encrypted extensions 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: depth=0 verify=1 subject=/C=DE/ST=Berlin/O=Verein zur F\xC3\xB6rderung eines Deutschen Forschungsnetzes DFN-Verein/CN=mx .srv.dfn.de 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server certificate 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:TLSv1.3 read server certificate verify 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read finished 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write finished 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: Matched DANE EE certificate at depth 0: 3 0 1 B85BD6FA275E5DE5748964BFBEBA198836ABAE5D6BF51A7D75756F888B3C08E7 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: subject_CN=mx.srv.dfn.de, issuer_CN=GEANT OV RSA CA 4, fingerprint=67:AA:4B:C1:2C:4B:AF:BA:82:12:A9:0E:E5:50:74:C3, pkey _fingerprint=98:E4:A8:E2:4C:C4:CA:3E:12:D8:77:B4:5C:4A:31:1B 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: Untrusted TLS connection established to c1491.mx.srv.dfn.de[194.95.238.86]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P- 384) server-signature RSA-PSS (4096 bits) server-digest SHA256 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSL negotiation finished successfully 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSL negotiation finished successfully 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server session ticket ``` -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: drop unwanted recipients
Gino Ferguson skrev den 2022-11-21 11:11: How should this be done properly? show postconf -nf and logs of event that fails
Re: (Patch "half-dane" logging corner case) Untrusted TLS connections where email domain does not support DNSSEC but MX server has DNSSEC/DANE records
On Mon, Nov 21, 2022 at 06:18:33PM +0100, Paul Menzel wrote:
> With Postfix 3.6.0-RC1 and
I am curious why you are using a rather dated release-candidate.
> After a while of head scratching, I thought it might have to do with the
> SMTP servers publishing TLSA records, but the domain in the email
> address does not support DNSSEC.
That's where "smtp_tls_dane_insecure_mx_policy" comes into play.
> Testing with level `dane` it indeed does mark the TLS connection as
> untrusted:
>
> $ posttls-finger -c -l dane -P /etc/ssl/certs rki.de
> posttls-finger: MX RRset insecure: log verified as trusted
> posttls-finger: mx1.bund.de[77.87.224.131]:25: Matched DANE EE
> certificate at depth 0: 3 0 1
> 2E5543C7522EDC151C65602F4541DC14D66182B49EA687EE9EFA2F6E3990186E
A matching "3 0 1" record was found, this should be logged as "Trusted"
per the preceding log message.
> posttls-finger: Untrusted TLS connection established to
> mx1.bund.de[77.87.224.131]: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
Unfortunately, that's not what actually happens.
> My naive assumption would have been, if no DNSSEC is set up for the
> domain in the email address, that DANE would not be tried. The
> DANE SMTP Validator [1] seems to use that ordering too.
>
> Do you have suggestions how to deal with this issue?
In general, don't stick with "-RC*" builds long past their use-by date.
However, in this case the issue is a minor oversight in the Postfix TLS
client code. The intended logging behaviour does not happen. Patch
below:
--
Viktor.
diff --git a/src/tls/tls_client.c b/src/tls/tls_client.c
index b6065649b..64c8da923 100644
--- a/src/tls/tls_client.c
+++ b/src/tls/tls_client.c
@@ -342,7 +342,8 @@ static void verify_extract_name(TLS_SESS_STATE *TLScontext,
X509 *peercert,
*/
if (!TLS_NEVER_SECURED(TLScontext->level))
TLScontext->peer_status |= TLS_CERT_FLAG_SECURED;
- TLScontext->peer_status |= TLS_CERT_FLAG_MATCHED;
+ TLScontext->peer_status |=
+ TLS_CERT_FLAG_TRUSTED | TLS_CERT_FLAG_MATCHED;
if (verbose) {
const char *peername = SSL_get0_peername(TLScontext->con);
Re: How do check DKIM and SPF on incoming email?
On Mon, Nov 21, 2022 at 12:48:49AM +, Scott Kitterman wrote: > On November 20, 2022 11:47:02 PM UTC, raf wrote: > > > >There are also Debian packages for policy server versions: > > > > postfix-policyd-spf-perl > > postfix-policyd-spf-python > > The Perl implementation is very rudimentary. Unless one is completely > allergic to Python for some reason, I definitely recommend the Python > one. > > The backend logic/code in pyspf-milter is shared with the policy > server. For Postfix, I don't think it matters much if you use the > milter or the policy server. > > Scott K Thanks for the tip. If I remember correctly, I tried both and preferred the headers created by the perl version. They were more detailed and informative. In what way is the python version better? cheers, raf
Re: drop unwanted recipients
On Mon, Nov 21, 2022 at 07:14:12PM +0100, Benny Pedersen wrote: > > How should this be done properly? > > show postconf -nf > > and logs of event that fails Nothing fails. The OP is asking how to selectively discard some recipients. Nothing in the OP's configuration is needed here, because nothing is wrong, this is a question about how to achieve a non-default behaviour. Wietse's answer is sufficient. I typically write "discard:silently" in the transport table, which is ever so slightly more efficient in some corner cases, and arguably makes the associated log entry a bit more clear. -- Viktor.
Re: Untrusted TLS connections where email domain does not support DNSSEC but MX server has DNSSEC/DANE records
Dear Bill, Thank you for your reply. Am 21.11.22 um 19:05 schrieb Bill Cole: On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100) Paul Menzel is rumored to have said: With Postfix 3.6.0-RC1 and # postconf -n smtp_tls_security_level smtp_tls_security_level = dane the Postfix SMTP client logs several untrusted TLS connections for hosts with a good TLS certificate setup. [...] I have no answer to your main question but I think I see the issue in the log below. The server sends a certificate with "issuer_CN=GEANT OV RSA CA 4" but it doesn't seem to send any intermediate certificate to build a chain back to a known root, so unless you have a trusted root locally for that issuer, the chain can't be verified. which SMTP server do you refer to? Both the mx1.bund.de and c1491.mx.srv.dfn.de return the full chain [1][2]. Kind regards, Paul [1]: https://www.hardenize.com/report/rki.de/1669019771 [2]: https://www.hardenize.com/report/helmholtz-muenchen.de PPPS: OpenSSL output: ``` $ openssl s_client -connect mx1.bund.de.:25 -starttls smtp CONNECTED(0003) Can't use SSL_get_servername depth=2 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 verify return:1 depth=1 C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA verify return:1 depth=0 C = DE, O = Bundesverwaltungsamt Koeln, OU = BUND, OU = SERVICE, ST = Nordrhein-Westfalen, L = Koeln, CN = mx1.bund.de verify return:1 --- Certificate chain 0 s:C = DE, O = Bundesverwaltungsamt Koeln, OU = BUND, OU = SERVICE, ST = Nordrhein-Westfalen, L = Koeln, CN = mx1.bund.de i:C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Aug 24 11:35:10 2022 GMT; NotAfter: Aug 28 23:59:59 2023 GMT 1 s:C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 11 14:39:10 2014 GMT; NotAfter: Feb 11 23:59:59 2024 GMT 2 s:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Oct 1 10:40:14 2008 GMT; NotAfter: Oct 1 23:59:59 2033 GMT --- Server certificate -BEGIN CERTIFICATE- MIIJ8TCCCNmgAwIBAgIQIKyFpxYJvhHPIJjx7MBJ+TANBgkqhkiG9w0BAQsFADCB 3zELMAkGA1UEBhMCREUxJTAjBgNVBAoMHFQtU3lzdGVtcyBJbnRlcm5hdGlvbmFs IEdtYkgxHzAdBgNVBAsMFlQtU3lzdGVtcyBUcnVzdCBDZW50ZXIxHDAaBgNVBAgM E05vcmRyaGVpbiBXZXN0ZmFsZW4xDjAMBgNVBBEMBTU3MjUwMRAwDgYDVQQHDAdO ZXRwaGVuMSAwHgYDVQQJDBdVbnRlcmUgSW5kdXN0cmllc3RyLiAyMDEmMCQGA1UE AwwdVGVsZVNlYyBTZXJ2ZXJQYXNzIENsYXNzIDIgQ0EwHhcNMjIwODI0MTEzNTEw WhcNMjMwODI4MjM1OTU5WjCBlzELMAkGA1UEBhMCREUxIzAhBgNVBAoTGkJ1bmRl c3ZlcndhbHR1bmdzYW10IEtvZWxuMQ0wCwYDVQQLEwRCVU5EMRAwDgYDVQQLEwdT RVJWSUNFMRwwGgYDVQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMQ4wDAYDVQQHEwVL b2VsbjEUMBIGA1UEAxMLbXgxLmJ1bmQuZGUwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDCUMRjT8RTr1Z/Dm1zoe8NV9+vjYsueoF0AAdWRB5HsLFmQI65 xiuNWfgCrUWPrpbbutLE1RAf1WQ003l82WskUdePCVIFy4GaEDe8Y4URzhF1ujKd oEbEcjpG+SCUWFdCvQmzvKf3+x/K2nIAczMwMQ4/CXDXEvhZP9nyi4/NKtEAWb6L 3j22mVudg+UO6qQ6gTf9vh13lzOoicO5WBbA1+nD8kmh+GuE9sejGD1fQPsx5whI Zwbbfl7+xD4D227PmmNGsm9IOgrUDgU0a+tQH9kE6mqb1nwv/0voMHZesRB4Q0UV lec1uV7Y21piHu1+3/cNzfz7aDHlq+D/ppRk+zNDR3SgjA4fQ+DbmoHwEV16ZIR/ yypfpqfEHUJ9to3GRHjpI3shiXuuMNY+e0HAGRbRimGbOydkQ1tqcylK1HSS1AJV 9cEE1OFd2h5LxBs5kBLwYhJAXks8k1ulIujvoTj0hyVQfIlFaJ/RV8cZ+ycL1k4L Xkrt54PBkY7AAlh8fPjCXFiRryHsiwPLKkmtO/vyf9rfhi5L+7Q1PIyxc7B7O60W Cq4LVwjkS07xU5bOT2w1wxeJne0QKMRJwf+pZul04/gAMTxeL27pnv+vuhqkvvvm DIUXgeqYLiS2A6FfBUa0KYclHpMMgw7moLXneEifQflDNPiKyQO0ZXXSCwIDAQAB o4IE7TCCBOkwHwYDVR0jBBgwFoAUlMh0RvU6tEZIJvgryjQeViYEEgAwDgYDVR0P AQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAdBgNVHQ4E FgQU9cN3EN1qX6S3h7SKduRlNoCX+kEwZQYDVR0gBF4wXDBQBgorBgEEAb1HDRcB MEIwQAYIKwYBBQUHAgEWNGh0dHA6Ly9kb2NzLnNlcnZlcnBhc3MudGVsZXNlYy5k ZS9jcHMvc2VydmVycGFzcy5odG0wCAYGZ4EMAQICMEsGA1UdHwREMEIwQKA+oDyG Omh0dHA6Ly9jcmwuc2VydmVycGFzcy50ZWxlc2VjLmRlL3JsL1NlcnZlclBhc3Nf Q2xhc3NfMi5jcmwwgZkGCCsGAQUFBwEBBIGMMIGJMDMGCCsGAQUFBzABhidodHRw Oi8vb2NzcC5zZXJ2ZXJwYXNzLnRlbGVzZWMuZGUvb2NzcHIwUgYIKwYBBQUHMAKG Rmh0dHA6Ly9jcmwuc2VydmVycGFzcy50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX1Nl cnZlclBhc3NfQ2xhc3NfMl9DQS5
Re: Untrusted TLS connections where email domain does not support DNSSEC but MX server has DNSSEC/DANE records
On 2022-11-21 at 14:45:52 UTC-0500 (Mon, 21 Nov 2022 20:45:52 +0100) Paul Menzel is rumored to have said: Dear Bill, Thank you for your reply. Am 21.11.22 um 19:05 schrieb Bill Cole: On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100) Paul Menzel is rumored to have said: With Postfix 3.6.0-RC1 and # postconf -n smtp_tls_security_level smtp_tls_security_level = dane the Postfix SMTP client logs several untrusted TLS connections for hosts with a good TLS certificate setup. [...] I have no answer to your main question but I think I see the issue in the log below. The server sends a certificate with "issuer_CN=GEANT OV RSA CA 4" but it doesn't seem to send any intermediate certificate to build a chain back to a known root, so unless you have a trusted root locally for that issuer, the chain can't be verified. which SMTP server do you refer to? Both the mx1.bund.de and c1491.mx.srv.dfn.de return the full chain [1][2]. I did not see any log line for the intermediate certificate from c1491.mx.srv.dfn.de, but apparently Postfix only logs the root and the server, which obviously confused me. Kind regards, Paul [1]: https://www.hardenize.com/report/rki.de/1669019771 [2]: https://www.hardenize.com/report/helmholtz-muenchen.de PPPS: OpenSSL output: ``` $ openssl s_client -connect mx1.bund.de.:25 -starttls smtp CONNECTED(0003) Can't use SSL_get_servername depth=2 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 verify return:1 depth=1 C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA verify return:1 depth=0 C = DE, O = Bundesverwaltungsamt Koeln, OU = BUND, OU = SERVICE, ST = Nordrhein-Westfalen, L = Koeln, CN = mx1.bund.de verify return:1 --- Certificate chain 0 s:C = DE, O = Bundesverwaltungsamt Koeln, OU = BUND, OU = SERVICE, ST = Nordrhein-Westfalen, L = Koeln, CN = mx1.bund.de i:C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Aug 24 11:35:10 2022 GMT; NotAfter: Aug 28 23:59:59 2023 GMT 1 s:C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 11 14:39:10 2014 GMT; NotAfter: Feb 11 23:59:59 2024 GMT 2 s:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Oct 1 10:40:14 2008 GMT; NotAfter: Oct 1 23:59:59 2033 GMT --- Server certificate -BEGIN CERTIFICATE- MIIJ8TCCCNmgAwIBAgIQIKyFpxYJvhHPIJjx7MBJ+TANBgkqhkiG9w0BAQsFADCB 3zELMAkGA1UEBhMCREUxJTAjBgNVBAoMHFQtU3lzdGVtcyBJbnRlcm5hdGlvbmFs IEdtYkgxHzAdBgNVBAsMFlQtU3lzdGVtcyBUcnVzdCBDZW50ZXIxHDAaBgNVBAgM E05vcmRyaGVpbiBXZXN0ZmFsZW4xDjAMBgNVBBEMBTU3MjUwMRAwDgYDVQQHDAdO ZXRwaGVuMSAwHgYDVQQJDBdVbnRlcmUgSW5kdXN0cmllc3RyLiAyMDEmMCQGA1UE AwwdVGVsZVNlYyBTZXJ2ZXJQYXNzIENsYXNzIDIgQ0EwHhcNMjIwODI0MTEzNTEw WhcNMjMwODI4MjM1OTU5WjCBlzELMAkGA1UEBhMCREUxIzAhBgNVBAoTGkJ1bmRl c3ZlcndhbHR1bmdzYW10IEtvZWxuMQ0wCwYDVQQLEwRCVU5EMRAwDgYDVQQLEwdT RVJWSUNFMRwwGgYDVQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMQ4wDAYDVQQHEwVL b2VsbjEUMBIGA1UEAxMLbXgxLmJ1bmQuZGUwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDCUMRjT8RTr1Z/Dm1zoe8NV9+vjYsueoF0AAdWRB5HsLFmQI65 xiuNWfgCrUWPrpbbutLE1RAf1WQ003l82WskUdePCVIFy4GaEDe8Y4URzhF1ujKd oEbEcjpG+SCUWFdCvQmzvKf3+x/K2nIAczMwMQ4/CXDXEvhZP9nyi4/NKtEAWb6L 3j22mVudg+UO6qQ6gTf9vh13lzOoicO5WBbA1+nD8kmh+GuE9sejGD1fQPsx5whI Zwbbfl7+xD4D227PmmNGsm9IOgrUDgU0a+tQH9kE6mqb1nwv/0voMHZesRB4Q0UV lec1uV7Y21piHu1+3/cNzfz7aDHlq+D/ppRk+zNDR3SgjA4fQ+DbmoHwEV16ZIR/ yypfpqfEHUJ9to3GRHjpI3shiXuuMNY+e0HAGRbRimGbOydkQ1tqcylK1HSS1AJV 9cEE1OFd2h5LxBs5kBLwYhJAXks8k1ulIujvoTj0hyVQfIlFaJ/RV8cZ+ycL1k4L Xkrt54PBkY7AAlh8fPjCXFiRryHsiwPLKkmtO/vyf9rfhi5L+7Q1PIyxc7B7O60W Cq4LVwjkS07xU5bOT2w1wxeJne0QKMRJwf+pZul04/gAMTxeL27pnv+vuhqkvvvm DIUXgeqYLiS2A6FfBUa0KYclHpMMgw7moLXneEifQflDNPiKyQO0ZXXSCwIDAQAB o4IE7TCCBOkwHwYDVR0jBBgwFoAUlMh0RvU6tEZIJvgryjQeViYEEgAwDgYDVR0P AQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAdBgNVHQ4E FgQU9cN3EN1qX6S3h7SKduRlNoCX+kEwZQYDVR0gBF4wXDBQBgorBgEEAb1HDRcB MEIwQAYIKwYBBQUHAgEWNGh0dHA6Ly9kb2NzLnNlcnZlcnBhc3MudGVsZXNlYy5k ZS9jcHMvc2VydmVycGFzcy5odG0wCAYGZ4EMAQICMEsGA1UdHwREMEIwQKA+oDy
Re: drop unwanted recipients
Viktor Dukhovni skrev den 2022-11-21 19:29: On Mon, Nov 21, 2022 at 07:14:12PM +0100, Benny Pedersen wrote: > How should this be done properly? show postconf -nf and logs of event that fails Nothing fails. The OP is asking how to selectively discard some recipients. Nothing in the OP's configuration is needed here, because nothing is wrong, this is a question about how to achieve a non-default behaviour. Wietse's answer is sufficient. I typically write "discard:silently" in the transport table, which is ever so slightly more efficient in some corner cases, and arguably makes the associated log entry a bit more clear. good, its just me that remember "reject_mutli_recipient_bounce" ? i have always being in impression valid recipient was delivered, while all others in multi recipient was just rejected sendmail -f m...@junc.eu -bv ab...@junc.eu,postmast...@junc.eu (expanded from ): delivery via mx.junc.eu[private/dovecot-lmtp]: 250 2.1.5 OK : delivery via mx.junc.eu[private/dovecot-lmtp]: host mx.junc.eu[private/dovecot-lmtp] said: 550 5.1.1 User doesn't exist: postmast...@junc.eu (in reply to RCPT TO command) not the same ?
