Re: Service currently unavailable
On Wed, 5 Jul 2017 12:11:41 -0400 (EDT) wie...@porcupine.org (Wietse Venema) wrote: > I suggest that you remove the postscreen_cache_map file and do > 'postfix reload'. Im not sure this was but it looks normally again. So all mails arrived. Thank you for help & Nice day Silvio
don't use ADH in server-to-server
Hello, I have a setup where a MTA will forward mail to another node, based on ldap configuration. It works well, but it uses ADH Received: from corrin.geekwu.org (unknown [87.98.180.13]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by arrakeen.geekwu.org (Postfix) with ESMTPS id A96DF6C07D for ; Thu, 6 Jul 2017 01:52:53 +0200 (CEST) I know I should not disable ADH on public interface, but I'd like to prevent it on "private" interface (intra-cluster only), as "cluster" nodes does communicate over Internet. the private interface is defined in master.cf: 26 inetn - - - - smtpd -o smtpd_client_restrictions=permit_mynetworks,reject -o syslog_name=postfix/cluster -o smtpd_milters= -o check_policy_service= but I did not succeed in fixing cipher for this interface (something like -osmtpd_tls_ciphers=ECDH+AES does not work ...) Is there a way to do that ? Thanks, -- Bastien
Re: don't use ADH in server-to-server
Bastien Durel: > Hello, > > I have a setup where a MTA will forward mail to another node, based on > ldap configuration. > It works well, but it uses ADH > > Received: from corrin.geekwu.org (unknown [87.98.180.13]) > (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) > (No client certificate requested) > by arrakeen.geekwu.org (Postfix) with ESMTPS id A96DF6C07D > for ; Thu, 6 Jul 2017 01:52:53 +0200 (CEST) > > I know I should not disable ADH on public interface, but I'd like to > prevent it on "private" interface (intra-cluster only), as "cluster" > nodes does communicate over Internet. > > the private interface is defined in master.cf: > 26 inetn - - - - smtpd >-o smtpd_client_restrictions=permit_mynetworks,reject >-o syslog_name=postfix/cluster >-o smtpd_milters= >-o check_policy_service= > > but I did not succeed in fixing cipher for this interface (something > like -osmtpd_tls_ciphers=ECDH+AES does not work ...) RTFM? As documented, smtpd_tls_ciphers takes a grade (such as 'medium' or 'export'). See 'smtpd_tls_mandatory_ciphers' for the full list. http://www.postfix.org/postconf.5.html#smtpd_tls_ciphers http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_ciphers > Is there a way to do that ? The above links refer to, among other things, http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers This has an example for excluding anonymous ciphers. Wietse
something like smtp-limiter plugin for ISPConfig
Hi people, I am looking for some plugin which is similar to smtp-limiter which is for DirectAdmin. It would be nice if there would be any. If not, is there any similar plugin which can be manage by the linux console? -- *Pozdrawiam / Best Regards* *Piotr Bracha* *tel. 534 555 877* *ser...@poliman.pl *
Re: something like smtp-limiter plugin for ISPConfig
On Thu, Jul 06, 2017 at 03:01:22PM +0200, Poliman - Serwis wrote: > I am looking for some plugin which is similar to smtp-limiter > which is for DirectAdmin. It would be nice if there would be any. What does that plugin do? What is the actual problem you're trying to solve? BTW, this is not the place for ISPConfig support. If you're using Postfix through some kind of management frontend, you need to use support offerings of that company or their user community. > If not, is there any similar plugin which can be manage by the > linux console? I'm going to guess that the real problem might be spam sent by authenticated users' malware. You can mitigate that with content filtering on submission mail, specifically with URIBL lookups, because practically all of this malware will be spewing references to URIBL-listed web sites. Also, a policy service such as postfwd[1] or cbpolicyd[2] can be deployed to limit users' sending. Generally this kind of malware exceeds a human user's ability to send mail. [1] http://postfwd.org/ratelimits.html [2] https://wiki.policyd.org/quotas -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: don't use ADH in server-to-server
On Thu, Jul 06, 2017 at 01:03:03PM +0200, Bastien Durel wrote: > I have a setup where a MTA will forward mail to another node, based on ldap > configuration. > It works well, but it uses ADH > > Received: from corrin.geekwu.org (unknown [87.98.180.13]) > (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) > (No client certificate requested) > by arrakeen.geekwu.org (Postfix) with ESMTPS id A96DF6C07D > for ; Thu, 6 Jul 2017 01:52:53 +0200 (CEST) > > I know I should not disable ADH on public interface, but I'd like to prevent > it on "private" interface (intra-cluster only), as "cluster" nodes does > communicate over Internet. Just force authentication for this connection by setting smtp_tls_security_level to an appropriate level: - dane, with appropriate dns entries - dane-only - fingerprint - verify - secure You can also override this setting via smtp_tls_policy_maps Regards, Bastian -- Is truth not truth for all? -- Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4.
Re: something like smtp-limiter plugin for ISPConfig
Thank you for answer. This plugin gives ability to limit number of sending emails. Above some value user's account is blocked and mail is send to administrator. I use postfix with ISP Config. It does not have to be plugin for ISP. It can be something just for postfix which can be manage as shell user in linux console. Of course if some plugin for ISP is, I would be happy to know about. 2017-07-06 15:41 GMT+02:00 /dev/rob0 : > On Thu, Jul 06, 2017 at 03:01:22PM +0200, Poliman - Serwis wrote: > > I am looking for some plugin which is similar to smtp-limiter > > which is for DirectAdmin. It would be nice if there would be any. > > What does that plugin do? What is the actual problem you're trying > to solve? > > BTW, this is not the place for ISPConfig support. If you're using > Postfix through some kind of management frontend, you need to use > support offerings of that company or their user community. > > > If not, is there any similar plugin which can be manage by the > > linux console? > > I'm going to guess that the real problem might be spam sent by > authenticated users' malware. You can mitigate that with content > filtering on submission mail, specifically with URIBL lookups, > because practically all of this malware will be spewing references to > URIBL-listed web sites. > > Also, a policy service such as postfwd[1] or cbpolicyd[2] can be > deployed to limit users' sending. Generally this kind of malware > exceeds a human user's ability to send mail. > > [1] http://postfwd.org/ratelimits.html > [2] https://wiki.policyd.org/quotas > -- > http://rob0.nodns4.us/ > Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: > -- *Pozdrawiam / Best Regards* *Piotr Bracha* *tel. 534 555 877* *ser...@poliman.pl *
Re: don't use ADH in server-to-server
> On Jul 6, 2017, at 7:03 AM, Bastien Durel wrote: > > I have a setup where a MTA will forward mail to another node, based on ldap > configuration. > It works well, but it uses ADH > > Received: from corrin.geekwu.org (unknown [87.98.180.13]) > (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) > (No client certificate requested) > by arrakeen.geekwu.org (Postfix) with ESMTPS id A96DF6C07D > for ; Thu, 6 Jul 2017 01:52:53 +0200 (CEST) > > I know I should not disable ADH on public interface, but I'd like to prevent > it on "private" interface (intra-cluster only), as "cluster" nodes does > communicate over Internet. SMTP transport security policy is largely up to the client, not the server. See http://www.postfix.org/TLS_README.html#client_tls_limits http://www.postfix.org/TLS_README.html#client_tls_levels The reason ADH is used, is that the client is not bothering to authenticate the server, and so does not bother to ask for a certificate it will anyhow ignore. If you want secure transport, you need to set the client TLS security level to "secure", "fingerprint", "dane" or "dane-only". http://www.postfix.org/TLS_README.html#client_tls_secure http://www.postfix.org/TLS_README.html#client_tls_fprint http://www.postfix.org/TLS_README.html#client_tls_dane -- Viktor.
How to fall back from `dane-only` to `secure`?
Dear Postfix folks, There are several SMTP servers, where messages should only be sent over a secure channel. But, the postmasters have set up the servers differently. Some use CAs to sign their certificates and some DANE with self-signed certificates. To avoid maintaining two TLS policies, one where for `smtp_tls_security_level` the value `secure` is specified, and another with `dane-only` [1], and keeping an eye out, when SMTP switch to or from DANE, is there a way to maintain one list? So if no DANE records are published, it falls back to secure certificate verification? Like `dane` falls back to `may`? Kind regards, Paul [1] http://www.postfix.org/TLS_README.html#client_tls_policy
Re: How to fall back from `dane-only` to `secure`?
On Thu, Jul 06, 2017 at 07:37:47PM +0200, Paul Menzel wrote: > There are several SMTP servers, where messages should only be sent over a > secure channel. But, the postmasters have set up the servers differently. > Some use CAs to sign their certificates and some DANE with self-signed > certificates. > > To avoid maintaining two TLS policies, one where for > `smtp_tls_security_level` the value `secure` is specified, and another with > `dane-only` [1], and keeping an eye out, when SMTP switch to or from DANE, > is there a way to maintain one list? So if no DANE records are published, it > falls back to secure certificate verification? > > Like `dane` falls back to `may`? Wietse and I have discussed something along these lines some time back, but nothing of that sort has as yet been implemented. -- Viktor.
Root certificate in `/etc/ssl/certs` not found
Dear Postfix users, First I am sorry, for probably bringing up a topic, which has probably discussed to end on this list, like [1], and in the end was probably a user error. I’ll try to provide the information requested in [1]. Thank you for your patience and help in advance. The goal is to set up secure server certificate verification [2] for messages sent to the domain gwdg.de [3]. But doing that, the test message was deferred as the certificate couldn’t be verified. Debian 9 (Stretch/stable) with the package `postfix` has the version 3.1.4-7. ``` $ sudo postconf mail_version mail_version = 3.1.4 $ sudo postconf smtp_tls_CAfile smtp_tls_CAfile = $ sudo postconf smtp_tls_CAfilesmtp_tls_CApath postconf: warning: smtp_tls_CAfilesmtp_tls_CApath: unknown parameter $ sudo postconf smtp_tls_CApath smtp_tls_CApath = /etc/ssl/certs/ ``` Verify with `posttls-finger`. ``` $ sudo posttls-finger -t30 -T180 -c -L verbose,summary gwdg.de posttls-finger: initializing the client-side TLS engine posttls-finger: setting up TLS connection to mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25 posttls-finger: mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH:!aNULL" posttls-finger: mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25: depth=2 verify=0 subject=/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01 posttls-finger: mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25: depth=1 verify=1 subject=/C=DE/O=DFN-Verein/OU=Geschaeftsstelle/CN=DFN-Verein-GS-CA - G02 posttls-finger: mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25: depth=0 verify=1 subject=/C=DE/ST=Berlin/L=Berlin/O=DFN-Verein/OU=Geschaeftsstelle/CN=mfilter-123-3-1.mx.srv.dfn.de posttls-finger: certificate verification failed for mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25: untrusted issuer /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2 posttls-finger: mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25: subject_CN=mfilter-123-3-1.mx.srv.dfn.de, issuer_CN=DFN-Verein-GS-CA - G02, fingerprint=F8:EC:1C:72:36:5B:40:E4:F0:B4:23:8C:9E:C5:E4:7B:C3:54:85:70, pkey_fingerprint=19:CA:96:64:83:C8:90:34:B6:15:31:EF:C0:8F:26:41:99:80:17:65 posttls-finger: Untrusted TLS connection established to mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) ``` So judging from “untrusted issuer”, I assume the root certificate is missing. Use `openssl`. ``` $ echo "" | openssl s_client -connect mfilter-123-3-1.mx.srv.dfn.de:25 -starttls smtp -showcerts […] CONNECTED(0003) depth=3 C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2 verify return:1 depth=2 C = DE, O = DFN-Verein, OU = DFN-PKI, CN = DFN-Verein PCA Global - G01 verify return:1 depth=1 C = DE, O = DFN-Verein, OU = Geschaeftsstelle, CN = DFN-Verein-GS-CA - G02 verify return:1 depth=0 C = DE, ST = Berlin, L = Berlin, O = DFN-Verein, OU = Geschaeftsstelle, CN = mfilter-123-3-1.mx.srv.dfn.de verify return:1[…] Verify return code: 0 (ok) […] ``` Save the certificate *C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01* in `issuer.pem` (attached), and verify it. ``` $ openssl verify -CApath /etc/ssl/certs -purpose crlsign issuer.pem issuer.pem: OK ``` The server certificate also contains the correct name, right? ``` CN=mfilter-123-3-1.mx.srv.dfn.de ``` So it’s not a problem with matching the server certificate peername [4], is it? Kind regards, Paul [1] http://postfix.1071664.n5.nabble.com/TLS-Encryption-and-Verification-issue-td72677.html "TLS Encryption and Verification issue" [2] http://www.postfix.org/TLS_README.html#client_tls_secure [3] https://ssl-tools.net/mailservers/gwdg.de [4] http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_match 2 s:/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01 i:/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2 -BEGIN CERTIFICATE- MIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcNAQELBQAwcTELMAkGA1UE BhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQt VGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20g Um9vdCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkG A1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kx JDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuV InTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFssoNTl7LZBF0O2g AHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt /zWGfW8zs9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYf JzDNSVTbyRM0mnF1xWzqpwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYw ggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsTKffxCnA+ 3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwEgYDVR0TAQH/BAgw BgEB/wIBAjBiBgNVHSAEWzBZMBE
Returning an Error Response
When using virtual domains, is there a way to return a temp fail message for a specific user in a domain? I am not finding anything about that in the documentation.
Configuration Syntax
I tried to implement RBL and postfwd. I placed everything in main.cf: smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040 reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, reject_unauth_destination, reject_rbl_client bl.spamcop.net permit That worked, but it affected both the smtp and submission ports. I expected that, but it made it easier to test. However, I then needed to make the submission port work properly. So I made the following change to master.cf and removed those lines from main.cf: smtpd pass - - n - - smtpd -o smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040 reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, reject_unauth_destination, reject_rbl_client bl.spamcop.net permit After a postfix reload basically everything stopped working. There were no errors reported in maillog. Basically, nothing was going into maillog. So I went back to the original configuration and it started working again. I then added the following to master.cf to remove those from submission port: submission inet n - n - - smtpd -o smtpd_recipient_restrictions=permit_mynetworks This approach works, but it seems to me that the first approach should have worked. Apparently I have formatted the options incorrectly. What did I do wrong? -- Doug
Re: Returning an Error Response
On 7/6/2017 1:45 PM, Doug Hardie wrote:
> When using virtual domains, is there a way to return a temp fail message for
> a specific user in a domain? I am not finding anything about that in the
> documentation.
>
You can use a check_{sender, recipient}_access map (whichever is
appropriate, or both) and return DEFER for that user. There isn't a
way to defer in the virtual map itself.
-- Noel Jones
Re: Returning an Error Response
On Thu, Jul 06, 2017 at 11:45:01AM -0700, Doug Hardie wrote: > When using virtual domains, (That part is not relevant.) > is there a way to return a temp fail message for a specific > user in a domain? I am not finding anything about that in the > documentation. http://www.postfix.org/SMTPD_ACCESS_README.html http://www.postfix.org/access.5.html http://www.postfix.org/postconf.5.html#check_recipient_access main.cf : ... smtpd_recipient_restrictions = ... check_recipient_access hash:/path/to/rcpt-tempfail ... ... /path/to/rcpt-tempfail : u...@example.com450 4.2.1 This mailbox is unavailable Don't forget: "postmap /path/to/rcpt-tempfail" -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Configuration Syntax
On 7/6/2017 1:45 PM, Doug Hardie wrote:
> I tried to implement RBL and postfwd. I placed everything in main.cf:
>
> smtpd_recipient_restrictions =
> check_policy_service inet:127.0.0.1:10040
> reject_invalid_hostname,
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> reject_unauth_pipelining,
> permit_mynetworks,
> reject_unauth_destination,
> reject_rbl_client bl.spamcop.net
> permit
>
> That worked, but it affected both the smtp and submission ports. I expected
> that, but it made it easier to test. However, I then needed to make the
> submission port work properly. So I made the following change to master.cf
> and removed those lines from main.cf:
>
> smtpd pass - - n - - smtpd
>-o smtpd_recipient_restrictions =
>check_policy_service inet:127.0.0.1:10040
>reject_invalid_hostname,
>reject_non_fqdn_sender,
>reject_non_fqdn_recipient,
>reject_unknown_sender_domain,
>reject_unknown_recipient_domain,
>reject_unauth_pipelining,
>permit_mynetworks,
>reject_unauth_destination,
>reject_rbl_client bl.spamcop.net
>permit
>
>
> After a postfix reload basically everything stopped working. There were no
> errors reported in maillog. Basically, nothing was going into maillog. So I
> went back to the original configuration and it started working again. I then
> added the following to master.cf to remove those from submission port:
>
> submission inet n - n - - smtpd
>-o smtpd_recipient_restrictions=permit_mynetworks
>
>
> This approach works, but it seems to me that the first approach should have
> worked. Apparently I have formatted the options incorrectly. What did I do
> wrong?
>
> -- Doug
>
main.cf doesn't allow spaces in the options. The supported syntax
is to either use commas "," rather than spaces; enclose the option
in braces "{ ... }"; or the preferred method of defining a macro in
main.cf and reference it in master.cf. See the master.cf man page.
# main.cf
my_smtpd_restrictions =
check_policy_service inet:127.0.0.1:10040
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
reject_unauth_destination,
reject_rbl_client bl.spamcop.net
permit
# master.cf
smtpd pass - - n - - smtpd
-o smtpd_recipient_restrictions=$my_smtpd_restrictions
-- Noel Jones
Re: Root certificate in `/etc/ssl/certs` not found
On Thu, Jul 06, 2017 at 08:27:35PM +0200, Paul Menzel wrote: > $ sudo posttls-finger -t30 -T180 -c -L verbose,summary gwdg.de There's no need to run posttls-finger as root. And "verbose" is just distracting. > posttls-finger: setting up TLS connection to > mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25 > posttls-finger: Untrusted TLS connection established to > mfilter-123-3-1.mx.srv.dfn.de[194.95.232.101]:25: TLSv1.2 with cipher > ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) This is not surprising, since by default Postfix trusts no CAs, also recent versions of posttls-finger do "dane" verification by default. On my system the system certificate bundle is in /etc/ssl/cert.pem, and so the correct test is: $ posttls-finger -c -l secure -F /etc/ssl/cert.pem gwdg.de .mx.srv.dfn.de posttls-finger: mfilter-123-3-3.mx.srv.dfn.de[194.95.238.101]:25: Matched subjectAltName: mfilter-123-3-3.mx.srv.dfn.de posttls-finger: mfilter-123-3-3.mx.srv.dfn.de[194.95.238.101]:25 CommonName mfilter-123-3-3.mx.srv.dfn.de posttls-finger: mfilter-123-3-3.mx.srv.dfn.de[194.95.238.101]:25: subject_CN=mfilter-123-3-3.mx.srv.dfn.de, issuer_CN=DFN-Verein-GS-CA - G02, fingerprint=6D:C1:73:0B:7F:E4:CD:A5:54:CF:D8:79:7E:17:37:27:81:EF:9A:BE, pkey_fingerprint=E1:7E:4F:88:AD:09:50:54:5C:19:49:47:62:C6:64:33:A0:D7:48:35 posttls-finger: Verified TLS connection established to mfilter-123-3-3.mx.srv.dfn.de[194.95.238.101]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Notes: 1. "-l secure" selects the desired security level. 2. "-F /etc/ssl/cert.pem" selects the correct trusted certificate bundle. This corresponds to smtp_tls_CAfile. You can use "-P /some/path" to select a directory of trusted certs hashed in the usual way with c_rehash. This corresponds to smtp_tls_CApath. 3. The domain's MX hosts have certificates with the MX host DNS names, but do not contain the nexthop domain. Since the MX hosts are typically obtained via insecure DNS lookups, they cannot be trusted. See TLS_README for details. Therefore "secure" verification of this domain requires a non-default name matching strategy. In this case ".mx.srv.dfn.de" is a parent domain of all the MX hosts. Thus your TLS policy entry for this domain would be: # Perhaps some day the MX host certs will have gwdg.de names, so # include nexthop and dot-nexthop in addition to the current MX # provider domain. # gwdg.de secure match=nexthop:dot-nexthop:.mx.srv.dfn.de Encourage the counter-party to deploy DANE, SMTP TLS security scales much better with DANE (does not require per-destination manual configuration like the above). -- Viktor.
Re: Returning an Error Response
Thanks for the pointers on that. I spent a couple days digging around and never found it. On 6 July 2017, at 12:06, /dev/rob0 wrote: > > > On Thu, Jul 06, 2017 at 11:45:01AM -0700, Doug Hardie wrote: >> When using virtual domains, > > (That part is not relevant.) > >> is there a way to return a temp fail message for a specific >> user in a domain? I am not finding anything about that in the >> documentation. > > http://www.postfix.org/SMTPD_ACCESS_README.html > http://www.postfix.org/access.5.html > http://www.postfix.org/postconf.5.html#check_recipient_access > > main.cf : > > ... > smtpd_recipient_restrictions = ... >check_recipient_access hash:/path/to/rcpt-tempfail >... > ... > > /path/to/rcpt-tempfail : > > u...@example.com 450 4.2.1 This mailbox is unavailable > > Don't forget: "postmap /path/to/rcpt-tempfail" > -- > http://rob0.nodns4.us/ > Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Returning an Error Response
Doug Hardie: > Thanks for the pointers on that. I spent a couple days digging > around and never found it. Alternative: /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport /etc/postfix/transport: us...@example.com retry:This mailbox is temporarily unavailable us...@example.com error:This mailbox is permanently unavailable (see 'man 5 transport' and 'man 8 error' for background). Don't forget to 'postmap hash:/etc/postfix/transport' Wietse
Re: don't use ADH in server-to-server
Le 06/07/2017 à 15:59, Viktor Dukhovni a écrit : The reason ADH is used, is that the client is not bothering to authenticate the server, and so does not bother to ask for a certificate it will anyhow ignore. If you want secure transport, you need to set the client TLS security level to "secure", "fingerprint", "dane" or "dane-only". http://www.postfix.org/TLS_README.html#client_tls_secure http://www.postfix.org/TLS_README.html#client_tls_fprint http://www.postfix.org/TLS_README.html#client_tls_dane dane-only in client config is what I needed, thanks :) -- Bastien Durel
Re: Configuration Syntax
> On 6 July 2017, at 12:40, Doug Hardie wrote:
>
>>
>> On 6 July 2017, at 12:06, Noel Jones wrote:
>>
>> main.cf doesn't allow spaces in the options. The supported syntax
>> is to either use commas "," rather than spaces; enclose the option
>> in braces "{ ... }"; or the preferred method of defining a macro in
>> main.cf and reference it in master.cf. See the master.cf man page.
>>
>> # main.cf
>> my_smtpd_restrictions =
>> check_policy_service inet:127.0.0.1:10040
>> reject_invalid_hostname,
>> reject_non_fqdn_sender,
>> reject_non_fqdn_recipient,
>> reject_unknown_sender_domain,
>> reject_unknown_recipient_domain,
>> reject_unauth_pipelining,
>> permit_mynetworks,
>> reject_unauth_destination,
>> reject_rbl_client bl.spamcop.net
>> permit
>>
>> # master.cf
>> smtpd pass - - n - - smtpd
>> -o smtpd_recipient_restrictions=$my_smtpd_restrictions
>
>
> Thanks. That makes sense now.
Well, I thought I understood it, but now am not so sure so here is what I have
ready to try. I still am a bit confused in the macro in main.cf some of the
lines have a comma at the end and others do not. When is the comma needed?
main.cf
# Incoming restrictions and Implement postfwd
incoming_smtpd_restrictions =
check_policy_service inet:127.0.0.1:10040
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
check_recipient_access hash:/usr/local/etc/postfix/tempfail
reject_unauth_destination,
reject_rbl_client bl.spamcop.net
permit
Virtual_alias_maps file:
bc97...@lafn.orgdoug
...
tempfail file:
bc97...@lafn.org450 4.2.1 This mailbox is unavailable today
master.cf:
smtpd pass - - n - - smtpd
submission inet n - n - - smtpd
-o smtpd_recipient_restrictions=permit_mynetworks
