Hello Alice, see answers in line
Il giorno lun 10 dic 2018 alle ore 12:09 Alice Wonder <al...@domblogger.net> ha scritto: > > When trouble shooting on systems with SELinux I put it in permissive mode - > setenforce 0 this is already the case on the new VPS (FWIW, I personally share your feelingsabout selinux in general, but that is another story..) > 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) I just changed my permission in the same way, except that the files are in another folder (does it make any difference? It shouldn't right?), i.e. the same where letsencrypt/certbot put them: -r--------. 1 root root 3546 Dec 7 11:59 fullchain1.pem -rw-r--r--. 1 root root 1704 Dec 7 11:59 privkey1.pem and FWIW, as far as dovecot is concerned, this did not change things a bit, , I still can't get the "no shared cipher" abort message, even if dovecot/postfix config should point to/have the same config for these keys, right? This part is really confusing. Not sure if I can test anything more on the postfix side, until the reverse pointer gets updated in DNS. Or not? Thanks, Marco > > 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, > > Marco > > > > > > > > > > > >> On 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. >
