On Mon, Jan 03, 2022 at 01:29:59PM -0500, Ruben Safir <ru...@mrbrklyn.com> wrote:
> On Thu, Dec 23, 2021 at 11:20:09AM +1100, raf wrote: > > On Wed, Dec 22, 2021 at 12:20:31AM -0500, Ruben Safir <ru...@mrbrklyn.com> > > wrote: > > > > > On Wed, Dec 22, 2021 at 02:19:49PM +1100, raf wrote: > > > > On Tue, Dec 21, 2021 at 06:52:23AM -0500, Ruben Safir > > > > <ru...@mrbrklyn.com> wrote: > > > > > > > > > I want to add a domain for the office in addition to my current > > > > > domain. > > > > > > > > > > I've done this before, following the outline in: > > > > > http://www.postfix.org/VIRTUAL_README.html#canonical > > > > > > > > > > using > > > > > > > > > > [ruben@www2 ~]$ cat /etc/postfix/main.cf|grep mydest > > > > > mydestination = www.domain1.com, www2.domain1.com, home.domain1.com, > > > > > domain1.com, domain2.com, domain3.com, domain4.com, domain5.com, > > > > > newistdomain.com > > > > > > > > > > So I can receive mail satisfactory and this has been good enough > > > > > since I > > > > > normally ssh in from remote and use mutt and all my outgoing email is > > > > > transformed to n...@domain.com > > > > > > > > > > I need for select users from the newistdomain.com to have that > > > > > n...@newistdomain.com > > > > > > > > > > I am using thunderbird and dovecot to pop mail from the system. At > > > > > home, this is no problem as I am on the local network. I just set up > > > > > the > > > > > smtp server to the postfix host running postfix. > > > > > > > > That should probably be the same for all Thunderbird users as well. > > > > > > > > > mydomain = domain1.com > > > > > masquerade_domains = domain1.com, domain1.com #which is probably wrong > > > > > myhostname = domain1.com > > > > > > > > I'm sure that domain1.com doesn't need to appear twice in > > > > the masquerade_domains parameter, but it's harmless. > > > > > > > > > How do I securely open postfix to relay email received from these > > > > > specific external office locals using newistdomain.coms > > > > > > > > If you can already connect using Thunderbird, you must > > > > have an entry for submission and/or submissions/smtps > > > > (i.e., port 587 and/or 465) in /etc/postfix.master.cf, > > > > > > Thunderbird can directly talk to postfix SMTP without dovecot et al? > > > > > > I thought it only talks to postfix on the outbound mail. This is not > > > taylor uucp :( > > > > Thunderbird can talk SMTP to Postfix on ports 25, 465, > > and/or 587. But it can probably only use port 25 when > > it's connecting from an IP address that is in Postfix's > > $mynetworks and so doesn't necessarily require > > authentication. Ports 465 and 587 should require > > authentication. > > > > Thunderbird only connects to Dovecot directly for > > reading mail via POP/IMAP (ports 110, 143, 993, 995). > > > > However, for authenticated SMTP, Thunderbird connects > > to Postfix, and Postfix can then connect to Dovecot > > locally for authenticating the user. One way of doing > > that is: > > > > /etc/postfix/main.cf: > > smtpd_sasl_type = dovecot > > smtpd_sasl_path = private/auth > > Can't this be done with tls withouth dovecot or sasl? Authentication is needed by Dovecot for IMAP access to read email. So it should be available for use by Postfix as well. Authentication should also be required by Postfix for submission of email from remote clients like Thunderbird. The only typical exception to that would be when the Thunderbird clients are on a "trusted" network, and so their IP address can take the place of SASL authentication in order for Postfix to decide that it's OK to accept mail from them to be relayed to the outside world. Some would argue that SASL authentication should always be used whenever possible. However, even though TLS (usually) only verifies the identity of the server, rather than authenticating the client, it can do that as well, by using client certificates in addition to the server certificate. See http://www.postfix.org/TLS_README.html for details. So yes, you should be able to replace uses of permit_sasl_authenticated in various parameters with "smtpd_tls_req_ccert = yes" as -o option override in master.cf for your submission service. I'm sure there's more to it, but the TLS_README should help. > I tried to do this and I get this error > > > An error occurred while sending mail: Outgoing server (SMTP) error. The > server responded: TLS not available due to local problem. The Postfix server's logfile should contain more information about what the local problem was. You can also use openssl to connect to the server and examine the certificate details, with a command like this for port 25 or 587: DOMAIN=example.com SERVER=example.com PORT=25 echo | \ openssl s_client -starttls smtp -showcerts -servername $SERVER -connect $DOMAIN:$PORT 2>/dev/null | \ openssl x509 -inform pem -noout -text | less Or like this for port 465: DOMAIN=example.com SERVER=example.com PORT=465 echo | \ openssl s_client -showcerts -servername $SERVER -connect $DOMAIN:$PORT 2>/dev/null | \ openssl x509 -inform pem -noout -text | less But will probably just confirm the local problem. The mail logs are more likely to help you identify the cause. > I have this in the config file now: > > /etc/postfix/main.cf > > > smtpd_sender_restrictions = hash:/etc/postfix/access, > reject_unknown_sender_domain > > smtpd_recipient_restrictions = > check_client_access hash:/etc/postfix/helo_client_exceptions > check_sender_access hash:/etc/postfix/sender_checks, > reject_invalid_hostname, > ### Can cause issues with Auth SMTP, so be weary! > reject_non_fqdn_hostname, > ################################## > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > permit_mynetworks, > reject_unauth_destination, > permit_mynetworks, reject_unauth_destination, > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_rbl_client zen.spamhaus.org, > reject_rbl_client bl.spamcop.net > reject_rbl_client cbl.abuseat.org, > permit > smtpd_data_restrictions = reject_unauth_pipelining, permit > > ############################################################ > # SASL stuff > ############################################################ > smtp_sasl_auth_enable = no > smtp_sasl_security_options = > smtp_sasl_password_maps = > smtpd_sasl_auth_enable = no > ############################################################ > # TLS stuff > ############################################################ > #tls_append_default_CA = no > relay_clientcerts = It looks like the relay_clientcerts parameter would do what you want, if you point it at a lookup table containing your client TLS certificate fingerprints. You'd need to use permit_tls_clientcerts in place of permit_sasl_authenticated in the appropriate smtp_*_restrictions parameter for the submission service in master.cf. See http://www.postfix.org/postconf.5.html#relay_clientcerts http://www.postfix.org/postconf.5.html#permit_tls_clientcerts However, it's probably much easier to use SASL authentication instead since you already have dovecot. > #tls_random_source = dev:/dev/urandom > > smtp_use_tls = yes > smtp_tls_loglevel = 1 > smtp_enforce_tls = no > smtp_tls_CAfile = /etc/postfix/tls/smtpd.pem > #smtp_tls_CApath = > smtp_tls_cert_file = /etc/postfix/tls/smtpd.pem > smtp_tls_key_file = /etc/postfix/tls/smtpd.pem I don't think the above two parameters should be pointing to the same file. But I might be wrong about that. I've never had the Postfix server use a client certificate when sending mail out. But it really doesn't look right. Normally, the server would only use a specific client certificate for outgoing mail when sending to a particular transport that required it, not to all potential recipient servers as would be the case when putting those parameters in main.cf. It might be sensible to just replace the above with: smtp_tls_security_level = may smtp_tls_loglevel = 1 > #smtp_tls_session_cache_timeout = 3600s > smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache The above should probably use ${data_directory} rather than ${queue_directory}. But maybe that depends on the system. I think I had queue_directory originally but got warning messages in the logfile about it. If you aren't seeing those warnings, it's probably fine. > smtpd_use_tls = yes > smtpd_tls_loglevel = 1 > smtpd_tls_CAfile = /etc/postfix/tls/smtpd.pem > #smtpd_tls_CApath =/etc/postfix/tls/smtpd.pem > smtpd_tls_cert_file =/etc/postfix/tls/smtpd.pem > smtpd_tls_key_file =/etc/postfix/tls/smtpd.pem The same pem file as above is being used as the server certificate as well. And the cert and key parameters are pointing to the same file again which looks unusual to me. Does it contain both the private key and the full chain? If so, you could use the smtpd_tls_chain_files parameter instead of smtpd_tls_cert_file and smtpd_tls_key_file. Using the same file for smtpd_tls_CAfile as well looks odd to me, but I'm not an expert. Maybe it's OK. > smtpd_tls_ask_ccert = yes Having the above in main.cf makes it apply to all incoming SMTP connections. I don't think you want that. You only want it for your own users whose client certificates you know about. It should be in master.cf where the submission/submissions services are defined. And it should be "smtpd_tls_req_ccert = yes" instead, so that the Thunderbird clients are required to possess a known client certificate (if SASL authentication is not going to be used). I hope what I've said makes sense. cheers, raf
