When trouble shooting on systems with SELinux I put it in permissive mode -
setenforce 0Personally I prefer to disable it, it gets in the way too often and so far has never prevented an actual attack on any of my systems, and just when I start to figure things out - they change how it works on me. So I spend hours fiddling with it without benefit. But maybe I'm just not smart enough to figure SELinux out requiring me to constantly search how to resolve problems.
Anyway when I have to use it and there's something I need to troubleshoot, setenforce 0 puts it in permissive mode until I solve the problem. Just remember to setenforce 1 when it is all figured out.
For cert permissions, I use ownership of root:root with 644 on the cert and root:root with 400 on the private key. And I keep them in /etc/pki/tls structure with /etc/pki/tls/private being a directory only root can read (and the private key is in that directory)
Postfix and Dovecot in CentOS systems work fine with that even though the daemon runs as user postfix group postfix.
On 12/10/18 2:45 AM, Marco Fioretti wrote:
Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers <racu...@gmail.com> ha scritto:Google is refusing access because your ipv6 PTR does not map to your domain. It’s the common (now) google reverse lookup failing. ...thanks for the reminder. I know, but had temporarily forgotten due to how that this migration "crashed" on me without notice, the need to have that mapping. I have already contacted the provider of the new VPS to handle this. My doubts, and consequent need for help, about my postfix configuration remain, however. I do *believe* that I have done everything correctly wrt generating and installing letsencryptcertificates. However, I know for a fact that TLS/SSL is not working in dovecot, am not sure at all if the postfix TLS/SSL configuration is correct, or complete, and I also am not sure if the interwork between dovecot and postfix is configured correctly. I have found several pages with contrasting advice on how to set file ownership/ permissions for the certificate files so postfix can access them, and if / how selinux may have a part in theproblem (even if in my vps is set to "permissive" right now). So any further comment/check on my postconf -n output is still very welcome (as I said, right now I am running postfix 2.10.1, while the config files I am using are from a 2.5/2.6 installation, I do not remember exactly) Thanks, MarcoOn 10 Dec 2018, at 8:08 am, Marco Fioretti <marco.fiore...@gmail.com> wrote: Greetings, I had my personal postfix/dovecot server, configured for some of my own domains, running without problems on a linux VPS. For reasons totally out of my control, I had to migrate everything to another VPS two days ago, without notice, (details at the bottom if anybody is interested...), and consequently without any possibility to do the due homework and testing *BEFORE* the migration, so please be patient... The problem: since software and operating system versions are not the same as before, certain settings stopped working. So far the only major one I can't handle myself, both in dovecot and postfix, seems to be TLS/SSL configuration. I regenerated and installed a new SSL certificate with letsencrypt, but: - in dovecot, I can't connect because "ssl3_get_client_hello:no shared cipher", no matter which ciphers I configure (I've already asked about this on the dovecot list) - postfix receives email, but: - also gets lots of "454 4.7.0 TLS not available due to local problem" connecting to google servers - if I try to send email, I get this: Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review... As far as I can tell, this is a combination of postfix/dovecot settings not valid anymore + wrong file/folder permissions + maybe not compatible selinux (now set to "permissive"). I am already reading all the online resources I can find, but I find no clear consensus on what should be done. Any help is appreciated! Thanks, and here is the postfix configuration: I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 disable_vrfy_command = yes html_directory = /usr/share/doc/postfix-2.4.3-documentation/html inet_interfaces = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost mydomain = $myhostname myhostname = a.mx.MYDOMAIN mynetworks = 127.0.0.0/8, 212.110.184.219 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = inet:localhost:8891 procmail_destination_recipient_limit = 1 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme relay_domains = sample_directory = /etc/postfix sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_security_level = may smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_milters = inet:localhost:8891 smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_helo_access hash:/etc/postfix/reject_own_helo, check_policy_service unix:postgrey/socket smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may strict_rfc821_envelopes = yes unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/mymail_storage virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map virtual_transport = procmail virtual_uid_maps = static:5000 postconf: warning: /etc/postfix/main.cf: unused parameter: smtp_tls_auth_only=yes postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D WHY THIS HAPPENED: A few weeks ago, the old VPS provider communicated that they were going out of business on Dec 8th. For several personal reasons not relevant here (short version: have simply been almost unable to work in the same weeks) I only discovered this... on Dec. 8th. I had no time at all to test anything. Saturday I bought a new VPS from another provider, changed DNS records to point there, set up a new SSL certificate with letsencrypt, copied all the files and mailboxes to the new VPS and only after that I was able to start checking if configuration needed changes
-- For signature trust anchor (paranoid only need worry 'bout this): https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt Webmail clients, sorry, out of luck, you can't import it. Get an actual e-mail app.
smime.p7s
Description: S/MIME Cryptographic Signature
