Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have an, apparently frequently occurring but unsolved, issue with gmail when retrieving mail from external pop mail boxes via gmail. Looking at the error details it says:

server responded: 'authentication failed'.

This mail server is my own server and when I connect from terminal with:

~$ telnet mail.mydomain.com:995

I get the following:

Trying xx.xx.xxx.xx...
Connected to mail.mydomain.com.
Escape character is '^]'.

and then when trying to login:

user myuser
Connection closed by foreign host.

And in my mail log:

Mar 26 18:22:42 www dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth
Mar 26 18:22:42 www dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_mysql.so
Mar 26 18:22:42 www dovecot: auth: Debug: auth client connected (pid=6554)
Mar 26 18:23:20 www dovecot: pop3-login: Disconnected (no auth attempts): rip=xx.xx.xxx.xx, lip=xx.xx.xxx.xx, TLS handshaking: SSL_accept() failed: error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol

when testing ssl with:

~$ openssl s_client -connect mail.mydomain.com:995

I can connect, but with this line (I purchased a godaddy certificate):

Verify return code: 19 (self signed certificate in certificate chain)

What could I be doing wrong? Here are my config files:

# 2.0.13: /etc/dovecot/dovecot.conf
# OS: Linux 3.0.0-13-server x86_64 Ubuntu 11.10 ext4
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_location = maildir:/home/vmail/%d/%n/Maildir
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date
namespace {
  inbox = yes
  location = 
  prefix = INBOX.
  separator = .
  type = private
passdb {
  args = /etc/dovecot/dovecot-sql.conf
  driver = sql
protocols = imap pop3
service auth {
  unix_listener /var/spool/postfix/private/auth {
    group = postfix
    mode = 0660
    user = postfix
  unix_listener auth-userdb {
    group = vmail
    mode = 0600
    user = vmail
  unix_listener auth-master {
    mode = 0600
    user = vmail
  user = root
ssl = required
ssl_cert = </etc/ssl/certs/mail.mydomain.com_combined.crt
ssl_key = </etc/ssl/private/mail.mydomain.key
userdb {
  args = uid=5000 gid=5000 home=/home/vmail/%d/%n allow_all_users=yes
  driver = static
protocol lda {
  auth_socket_path = /var/run/dovecot/auth-master
  log_path = /home/vmail/dovecot-deliver.log
  mail_plugins = sieve
  postmaster_address = postmaster@mydomain.com
protocol pop3 {
  pop3_uidl_format = %08Xu%08Xv
disable_plaintext_auth = no

auth_verbose = yes
auth_debug = yes


# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = /usr/share/doc/postfix

# TLS parameters
smtpd_tls_cert_file = /etc/ssl/certs/mail.mydomain.com_combined.crt
smtpd_tls_key_file = /etc/ssl/private/mail.mydomain.com.key
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = mail.mydomain.com
mydomain = mydomain.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = 
relayhost = 
mynetworks = [::ffff:]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
html_directory = /usr/share/doc/postfix/html
message_size_limit = 30720000
virtual_alias_domains = 
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /home/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes
# see under Spam smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

# Spam
disable_vrfy_command = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
   check_helo_access hash:/etc/postfix/helo_access,
smtpd_recipient_restrictions =
   reject_rbl_client sbl.spamhaus.org,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client cbl.abuseat.org,
   reject_rbl_client bl.spamcop.net,
smtpd_error_sleep_time = 1s
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 20
share|improve this question

2 Answers 2

up vote 1 down vote accepted

Nothing is wrong. Everything you have shown us is consistent with a POP/S (SSL-secured) server running on port 995. Your openssl s_client session is probably complaining because it doesn't have the right CA in its certificate bundle.

Why google can't get email from your server is a legitimate question, but nothing you've posted sheds any light on that failure. If you can catch google in the act of retrieving mail from your server, and post those dovecot logs, then we might start to shed light on the problem.

Edit: Connection closed by foreign host happens because, unless you personally can speak fluent SSL and type odd characters very quickly, you can't use telnet to connect to an SSL-secured service (nb: this is not true for TLS-secured services, but this isn't one). Your entry of "user myuser", not being a valid SSL handshake, caused the SSL23_GET_CLIENT_HELLO:unknown protocol error. I'm sorry it doesn't "look nice", but it's all perfectly correct.

If you'd tried to login from the openssl s_client session, you'd probably have had more luck; the self-signed certificate warning is informational, not fatal, to the session.

share|improve this answer
what about: 'Connection closed by foreign host'? According to the docs I should be able to follow with my password. And the SSL_accept() failed: error:140760FC:SSL? It does not look nice. Google cannot be caught easily, not in my logs nor on their support forum... –  zensys Mar 26 '13 at 18:24
You should if you setup SSL handshake. With telnet - no. For keys -showcerts show you what happends but I think Mad is right. –  dsznajder Mar 26 '13 at 18:30
Sometimes Google fetchmail manages to login, more often not. My best guess is that Google notices the self signed certificate (incorrectly configured Godaddy certificate) and flags the account for the next login which is blocked. When I have solved the self signed issues I will report back. –  zensys Mar 27 '13 at 8:25
My problems are over. I did not change anything to my Dovecot or Postfix SSL config but I did correct an issue with my certificate configuration for Apache. As with the Dovecot/Postfix where you have to combine the domain and intermediate certificate I thought that would work for Apache as well (to avoid having different versions of one certificate). It did not. And it appears that fetchmail does not like that situation and refuses to do its work most of the time. –  zensys Mar 28 '13 at 21:54

I think perhaps this thread is old, but I will try and contribute, someone else might find it useful Google is very peculiar when it comes to connecting to mail servers, unless the mail-server uses a genuine ssl certificates issued by a recognised authority such as "Starssl " and so on, Google won't even talk to your server.

I had similar problem few months back, when I finally used a NOT self signed certificate I started receiving emails from "Yahoo, Google etc.." So it is definitely to do with the self signed certificate or not well bundled certificates, if you get issued certificates from a recognised authority and it's still not working check that you have everything correctly processed. Pay attention to the smallest detail anything can screw it up. But the first culprits are the CA. Good luck and I hope this information can help someone else.

share|improve this answer
-1. From the log, this is obviously dovecot issue and your answer stated that this is postfix part problem –  masegaloeh Jan 15 at 8:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.