0

I have set up postfix and dovecot following several guides online and consistently have the problem that emails I send will not be encrypted. I have been testing the settings by sending an email to my @gmail.com account as I am sure the google servers will support TLS encryption, and email in the gmail webmail clearly shows the red crossed out padlock to show that they are not encrypted.

If I set

smtpd_tls_security_level = encrypt smtp_tls_security_level = encrypt 

I get this error

TLS is required, but was not offered by host gmail-smtp-in.l.google.com[64.233.167.27] 

And if I set it to may it sends the email, without encrypting it.

This is the output of postconf -n

alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no home_mailbox = Maildir/ inet_interfaces = all inet_protocols = all mailbox_command = mailbox_size_limit = 0 mydestination = $myhostname, localdomain, localhost, localhost.localdomain, localhost, mail.example.com, example.com myhostname = mail.example.com mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mynetworks_style = subnet myorigin = /etc/mailname readme_directory = no recipient_delimiter = + smtp_tls_CAfile = /routeto/my.ca-bundle smtp_tls_cert_file = /routeto/my.crt smtp_tls_key_file = /routeto/my.key smtp_tls_loglevel = 1 smtp_tls_note_starttls_offer = yes smtp_tls_security_level = may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtp_use_tls = yes smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_client_hostname smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = example.com smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_tls_CAfile = /routeto/my.ca-bundle smtpd_tls_cert_file = /routeto/my.crt smtpd_tls_key_file = /routeto/my.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_use_tls = yes 

and this is the output of a telnet on port 25 followed by ehlo test

250-mail.example.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN 

and the same thing on port 587

250-mail.example.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN 

1 Answer 1

1

TLS is required, but was not offered by host gmail-smtp-in.l.google.com[64.233.167.27]

This clearly shows, that the host does not offer STARTTLS to your server. But, it is known that gmail offers STARTTLS and your test with telnet confirms it. My guess is that you did the telnet from a different system and that your mail server is behind some (transparent) firewall which intercepts traffic to analyze it. In order to not deal with encrypted SMTP traffic this is often done by simply stripping the STARTTLS command from the servers response to EHLO so that the mail server assumes that TLS is not supported.

See also What happens if STARTTLS dropped in SMTP?.

Sign up to request clarification or add additional context in comments.

4 Comments

The server is a VPS running a fresh install of ubuntu 16.04 and I believe it doesn't have any firewall running on it, so I'm not sure what to do next.
The telnet output I posted was actually of my own server, but now you've said that yes it makes more sense to test the gmail server from my own and you were totally right, this is the google server test from my server 250-mx.google.com at your service, 250-SIZE 157286400 250-8BITMIME 250-ENHANCEDSTATUSCODES 250 SMTPUTF8 and this is the same thing from my own laptop 250-SIZE 157286400 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 the STARTTLS is not offered to my server...
@DuncanConnolly: Intercepting firewalls are usually not located on the local system, i.e. the firewall is somewhere else in the network but in the path to the real server.
This was exactly the problem, there was a spam filter on the network disallowing me from encrypting emails. So I can't fix this problem myself and I will have to get a new VPS provider instead.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.