Just looking at this again…
Do you have in or remember to update…. (note the use of <your domain> as a
marker)
dovecot/conf.d/10-ssl.conf
ssl_cert = </etc/letsencrypt/live/<your domain>/fullchain.pem
ssl_key = </etc/letsencrypt/live/<your domain>/privkey.pem
and in postfix/main.cf
#TLS parameters
smtpd_use_tls=yes
smtpd_tls_ciphers = medium
smtpd_tls_security_level = may
smtpd_tls_key_file = /etc/letsencrypt/live/<your domain>/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/<your domain>/fullchain.pem
smtpd_tls_CAfile = /private/etc/ssl/certs/gd_bundle-g2-g1.crt
# List of ciphers or cipher types to exclude from the SMTP server cipher
# list at all TLS security levels.
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
smtpd_tls_ciphers = medium
smtpd_tls_security_level = may
and this seems to be useful for testing your certs…
openssl s_client -showcerts -servername <your domain> -connect <your
domain>:443 or 586 I think it is.
and don’t forget to rebuild your aliases and postmap your db files if you have
them.
As a side not, I managed to buildpostfix-3.4-20181125 and am now running that.
the configs remain much the same though.
hope tht may help
Robert
> On 10 Dec 2018, at 11:08, Alice Wonder <al...@domblogger.net> wrote:
>
> When trouble shooting on systems with SELinux I put it in permissive mode -
>
> setenforce 0
>
> Personally 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,
>> 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.
>
Robert Chalmers
https://robert-chalmers.uk
aut...@robert-chalmers.uk
@R_A_Chalmers
