Google is refusing access because your ipv6 PTR does not map to your domain.
It’s the common (now) google reverse lookup failing.


-----
Robert Chalmers
https://robert-chalmers.uk
aut...@robert-chalmers.uk
@R_A_Chalmers


> 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

Reply via email to