Re: empty MAIL FROM and check_sender_access
> On Sep 25, 2018, at 12:27 PM, Stefan Bauer wrote: > > I notice that only outlook out of all my mail clients, use the null mailer > address. it looks to me after reading the standard - that outlook does it > right. Is that correct? Outlook is perhaps the only one that is actually sending MDNs. These are often not supported or enabled in other mail user agents. -- Viktor.
Re: empty MAIL FROM and check_sender_access
I notice that only outlook out of all my mail clients, use the null mailer address. it looks to me after reading the standard - that outlook does it right. Is that correct? Am Di., 25. Sep. 2018 um 17:22 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 25, 2018, at 10:13 AM, Stefan Bauer > wrote: > > > > I was more asking if it's even a good idea to add the null entry to the > table? i would like to be a good postmaster but not want to relax policies > for allowed sender addresses. > > You need to allow mail with null return addresses. These are required in > bounces > and auto-replies to avoid loops. > > -- > Viktor. > >
Re: TLS: Migrate from *encrypt* to *verify* for specific domain
> On Sep 25, 2018, at 11:58 AM, Wietse Venema wrote: > >> As for "soft failure" with "verify" >> (or "secure"), that's not presently supported in Postfix. > > What about using smtp_delivery_status_filter? By "soft failure", I meant the OP's request to deliver anyway and just log a warning. We already tempfail on authentication errors. What we don't have is "try-tls" setting, that is insecure, but tamper-evident. -- Viktor. -- Viktor.
Re: TLS: Migrate from *encrypt* to *verify* for specific domain
Viktor Dukhovni: > The DANE survey finds 21 domains with DFN-Verein certificates and working > DANE. There are almost certainly some that don't have DANE TLSA records, > but they could if they wanted to. As for "soft failure" with "verify" > (or "secure"), that's not presently supported in Postfix. What about using smtp_delivery_status_filter? Wietse
Re: TLS: Migrate from *encrypt* to *verify* for specific domain
> On Sep 25, 2018, at 11:34 AM, Viktor Dukhovni > wrote: > > The DANE survey finds 21 domains with DFN-Verein certificates and working > DANE. There are almost certainly some that don't have DANE TLSA records, > but they could if they wanted to. FWIW, the certificates found among DANE-enabled domains with DFN-Verein issued certificates list the below organizations: Subject Organization = Bayerische Akademie der Wissenschaften Subject Organization = Bergische Universitaet Wuppertal Subject Organization = Hochschule Bremen Subject Organization = Hochschule Trier - Trier University of Applied Sciences Subject Organization = Hochschule fuer angewandte Wissenschaften Augsburg Subject Organization = Ludwig-Maximilians-Universitaet Muenchen Subject Organization = Max-Planck-Gesellschaft Subject Organization = Ruhr-Universitaet Bochum Subject Organization = Technische Hochschule Nuernberg Georg Simon Ohm Subject Organization = Technische Universitaet Dresden Subject Organization = Technische Universitaet Hamburg-Harburg Subject Organization = Technische Universitaet Kaiserslautern Subject Organization = Universitaet Erlangen-Nuernberg Subject Organization = Universitaet Passau Subject Organization = Universitaet Regensburg Subject Organization = Universitaet Rostock -- Viktor.
Re: TLS: Migrate from *encrypt* to *verify* for specific domain
> On Sep 25, 2018, at 9:29 AM, Paul Menzel wrote: > > We want to improve that. Unfortunately, DANE is not an option as the DFN > does not support that, What do you mean by "DFN does not support that"? If by "DFN" you mean "DFN-Verein", their certificates pose no compatibility issues with DANE. For example: uni-wuppertal.de. IN MX 20 mail1.uni-wuppertal.de. ; NoError AD=1 uni-wuppertal.de. IN MX 20 mail2.uni-wuppertal.de. ; NoError AD=1 mail1.uni-wuppertal.de. IN A 132.195.64.21 ; NoError AD=1 mail1.uni-wuppertal.de. IN 2001:638:50a:64::21 ; NoError AD=1 _25._tcp.mail1.uni-wuppertal.de. IN TLSA 3 1 1 e5ee04ac55b2dd966f1aa0011c90d8ab8284d2dce3480c48cde7bc12feca5422 ; NoError AD=1 mail1.uni-wuppertal.de[132.195.64.21]: pass: TLSA match: depth = 0, name = mail1.uni-wuppertal.de mail1.uni-wuppertal.de[2001:638:50a:64::21]: pass: TLSA match: depth = 0, name = mail1.uni-wuppertal.de TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384 name = mail1.uni-wuppertal.de depth = 0 Issuer CommonName = Uni-Wuppertal CA Issuer Organization = Bergische Universitaet Wuppertal notBefore = 2016-11-02T09:23:43Z notAfter = 2019-07-09T23:59:00Z Subject CommonName = mail1.uni-wuppertal.de Subject Organization = Bergische Universitaet Wuppertal pkey sha256 [matched] <- 3 1 1 e5ee04ac55b2dd966f1aa0011c90d8ab8284d2dce3480c48cde7bc12feca5422 depth = 1 Issuer CommonName = DFN-Verein PCA Global - G01 Issuer Organization = DFN-Verein notBefore = 2014-05-27T14:53:55Z notAfter = 2019-07-09T23:59:00Z Subject CommonName = Uni-Wuppertal CA Subject Organization = Bergische Universitaet Wuppertal pkey sha256 [nomatch] <- 2 1 1 894aabe20c4b0f55fe31261693303f034d9d3ca12bc3042eaed12f633e1ef357 depth = 2 Issuer CommonName = Deutsche Telekom Root CA 2 Issuer Organization = Deutsche Telekom AG notBefore = 2014-07-22T12:08:26Z notAfter = 2019-07-09T23:59:00Z Subject CommonName = DFN-Verein PCA Global - G01 Subject Organization = DFN-Verein pkey sha256 [nomatch] <- 2 1 1 5732fe16d00abf36f83798a0985272bfcdc60fb0812bb632c3e47a5dd4517e68 depth = 3 Issuer CommonName = Deutsche Telekom Root CA 2 Issuer Organization = Deutsche Telekom AG notBefore = 1999-07-09T12:11:00Z notAfter = 2019-07-09T23:59:00Z Subject CommonName = Deutsche Telekom Root CA 2 Subject Organization = Deutsche Telekom AG pkey sha256 [nomatch] <- 2 1 1 d1de2ae61c8df2fa623966163d4c73d460bfc428e57585be6bfeb9a56323d1b6 mail2.uni-wuppertal.de. IN A 132.195.64.6 ; NoError AD=1 mail2.uni-wuppertal.de. IN 2001:638:50a:64::6 ; NoError AD=1 _25._tcp.mail2.uni-wuppertal.de. IN TLSA 3 1 1 9739ebc5261100a62c488f48162816435872abddfcd0b6735e104a4fa7a7841a ; NoError AD=1 mail2.uni-wuppertal.de[132.195.64.6]: pass: TLSA match: depth = 0, name = mail2.uni-wuppertal.de mail2.uni-wuppertal.de[2001:638:50a:64::6]: pass: TLSA match: depth = 0, name = mail2.uni-wuppertal.de TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384 name = mail2.uni-wuppertal.de depth = 0 Issuer CommonName = Uni-Wuppertal CA Issuer Organization = Bergische Universitaet Wuppertal notBefore = 2016-11-02T09:23:45Z notAfter = 2019-07-09T23:59:00Z Subject CommonName = mail2.uni-wuppertal.de Subject Organization = Bergische Universitaet Wuppertal pkey sha256 [matched] <- 3 1 1 9739ebc5261100a62c488f48162816435872abddfcd0b6735e104a4fa7a7841a depth = 1 Issuer CommonName = DFN-Verein PCA Global - G01 Issuer Organization = DFN-Verein notBefore = 2014-05-27T14:53:55Z notAfter = 2019-07-09T23:59:00Z Subject CommonName = Uni-Wuppertal CA Subject Organization = Bergische Universitaet Wuppertal pkey sha256 [nomatch] <- 2 1 1 894aabe20c4b0f55fe31261693303f034d9d3ca12bc3042eaed12f633e1ef357 depth = 2 Issuer CommonName = Deutsche Telekom Root CA 2 Issuer Organization = Deutsche Telekom AG notBefore = 2014-07-22T12:08:26Z notAfter = 2019-07-09T23:59:00Z Subject CommonName = DFN-Verein PCA Global - G01 Subject Organization = DFN-Verein pkey sha256 [nomatch] <- 2 1 1 5732fe16d00abf36f83798a0985272bfcdc60fb0812bb632c3e47a5dd4517e68 depth = 3 Issuer CommonName = Deutsche Telekom Root CA 2 Issuer Organization = Deutsche Telekom AG notBefore = 1999-07-09T12:11:00Z notAfter = 2019-07-09T23:59:00Z Subject CommonName = Deutsche Telekom Root CA 2 Subject Organization = Deutsche Telekom AG pkey sha256 [nomatch] <- 2 1 1
Re: empty MAIL FROM and check_sender_access
> On Sep 25, 2018, at 10:13 AM, Stefan Bauer wrote: > > I was more asking if it's even a good idea to add the null entry to the > table? i would like to be a good postmaster but not want to relax policies > for allowed sender addresses. You need to allow mail with null return addresses. These are required in bounces and auto-replies to avoid loops. -- Viktor.
Devendra Fadnavis: Clean drinking municipal water for North West Virar residents
Hey, I just signed the petition "Devendra Fadnavis: Clean drinking municipal water for North West Virar residents" and wanted to see if you could help by adding your name. Our goal is to reach 224 signatures and we need more support. You can read more and sign the petition here: https://chn.ge/2N2irAv Thanks! Ashishkumar
empty MAIL FROM and check_sender_access
I was more asking if it's even a good idea to add the null entry to the table? i would like to be a good postmaster but not want to relax policies for allowed sender addresses. Am Di., 25. Sep. 2018 um 13:26 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > > Stefan Bauer: > > Hi, > > > > I'm using smtpd_sender_restrictions = check_sender_access > > hash:/etc/postfix/allowed_sender > > > > to make sure, my senders only send out with pre-defined and allowed domains. > > > > Now i noticed, that if my users acknowledge "read confirmations" in > > clients, mails in the following form arrive at postfix: > > > > from=<> to= proto=ESMTP helo= > > > > and will be rejected as empty mail from is not allowed by > > check_sender_access. > > > > Howto deal with that? > > http://www.postfix.org/postconf.5.html#smtpd_null_access_lookup_key > > Wietse
TLS: Migrate from *encrypt* to *verify* for specific domain
Dear Postfix folks, Currently, our `/etc/postfix/tls_policy` looks like below to force encryption when sending messages to other servers in our organization. mpg.deencrypt .mpg.de encrypt We want to improve that. Unfortunately, DANE is not an option as the DFN does not support that, and a lot of German research organizations and institutes use that for receiving messages. We do not have control over the other servers, but want to migrate to *verify* [1]. Can you recommend a strategy how to do that? Is there a way to use verify, and then fall back to encrypt, but log that, so that the other postmasters can be informed? Or should we maintain a separate list in some central place, which interested parties contribute to? Kind regards, Paul [1]: http://www.postfix.org/TLS_README.html#client_tls_verify
Re: empty MAIL FROM and check_sender_access
Stefan Bauer: > Hi, > > I'm using smtpd_sender_restrictions = check_sender_access > hash:/etc/postfix/allowed_sender > > to make sure, my senders only send out with pre-defined and allowed domains. > > Now i noticed, that if my users acknowledge "read confirmations" in > clients, mails in the following form arrive at postfix: > > from=<> to= proto=ESMTP helo= > > and will be rejected as empty mail from is not allowed by > check_sender_access. > > Howto deal with that? http://www.postfix.org/postconf.5.html#smtpd_null_access_lookup_key Wietse
empty MAIL FROM and check_sender_access
Hi, I'm using smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/allowed_sender to make sure, my senders only send out with pre-defined and allowed domains. Now i noticed, that if my users acknowledge "read confirmations" in clients, mails in the following form arrive at postfix: from=<> to= proto=ESMTP helo= and will be rejected as empty mail from is not allowed by check_sender_access. Howto deal with that?
