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
