[Dovecot] STARTTLS does not seem to work
I believe I have the configuration set to use START TLS on IMAP4 (143) and POP3 (110) ports. However, it does not seem to be working. Yet "STARTTLS" is listed as a capability (which tells me I probably do have it configured right).
In the session below, 172.30.0.24 is the mail server I'm putting up. 64.26.60.229 is an outside mail service. A similar thing happens on POP3. The always-SSL/TLS ports (993 and 995) are working. There's very little documentation matching "starttls".
======================================================================== altair/phil /home/phil 162> telnet 172.30.0.24 143 Trying 172.30.0.24... Connected to 172.30.0.24. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1 STARTTLS LOGINDISABLED] AUTHORIZED USERS ONLY -- unauthorized access strictly prohibited STARTTLS STARTTLS BAD Error in IMAP command received by server. ^]quit
telnet> quit Connection closed. altair/phil /home/phil 163> telnet 64.26.60.229 143 Trying 64.26.60.229... Connected to 64.26.60.229. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE STARTTLS] Courier-IMAP ready. Copyright 1998-2005 Double Precision, Inc. See COPYING for distribution information. STARTTLS STARTTLS OK Begin SSL/TLS negotiation now. ^]quit
telnet> quit Connection closed. altair/phil /home/phil 164>
I do have "disable_plaintext_auth = yes" in my config file even though "dovecot -n" does not show it ... must be a default.
======================================================================== # 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.31-19-server x86_64 Ubuntu 9.10 ext3 base_dir: /var/run/dovecot/ log_path: /var/log/dovecot/error.log info_log_path: /var/log/dovecot/info.log log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap pop3 imaps pop3s listen: 172.30.0.24, [fc00::18], 127.0.0.1, [::1] ssl_cert_file: /etc/ssl/certs/ssl-mail.pem ssl_key_file: /etc/ssl/private/ssl-mail.key ssl_parameters_regenerate: 24 ssl_cipher_list: ALL:!LOW:!SSLv2:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:+HIGH:+MEDIUM login_dir: /var/run/dovecot//login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_greeting: AUTHORIZED USERS ONLY -- unauthorized access strictly prohibited login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no mail_max_userip_connections(default): 10 mail_max_userip_connections(imap): 10 mail_max_userip_connections(pop3): 3 verbose_proctitle: yes first_valid_uid: 250 mail_privileged_group: mail mail_uid: vmail mail_gid: vmail mail_location: maildir:/home/mail/%Ld/%Ln/mail mail_debug: yes mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_process_size: 768 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(pop3): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh auth default: mechanisms: plain login username_format: %Ln@%Ld verbose: yes debug: yes debug_passwords: yes passdb: driver: passwd-file args: username_format=%Ln@%Ld /etc/mailauth/deny deny: yes passdb: driver: passwd-file args: username_format=%Ln /etc/mailauth/%Ld/deny deny: yes passdb: driver: passwd-file args: scheme=crypt username_format=%Ln@%Ld /etc/mailauth/passwd passdb: driver: passwd-file args: scheme=crypt username_format=%Ln /etc/mailauth/%Ld/passwd userdb: driver: passwd-file args: username_format=%Ln@%Ld /etc/mailauth/passwd userdb: driver: passwd-file args: username_format=%Ln /etc/mailauth/%Ld/passwd socket: type: listen client: path: /var/spool/postfix/private/dovecot-auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail
altair/phil /home/phil 162> telnet 172.30.0.24 143 Trying 172.30.0.24... Connected to 172.30.0.24. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1 STARTTLS LOGINDISABLED] AUTHORIZED USERS ONLY -- unauthorized access strictly prohibited STARTTLS STARTTLS BAD Error in IMAP command received by server. ^]quit
Every IMAP command needs a command tag. Instead of "STARTTLS" try "A STARTTLS".
On Mon, May 24, 2010 at 11:31, Mike Abbott michael.abbott@apple.com wrote:
altair/phil /home/phil 162> telnet 172.30.0.24 143 Trying 172.30.0.24... Connected to 172.30.0.24. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1 STARTTLS LOGINDISABLED] AUTHORIZED USERS ONLY -- unauthorized access strictly prohibited STARTTLS STARTTLS BAD Error in IMAP command received by server. ^]quit
Every IMAP command needs a command tag. Instead of "STARTTLS" try "A STARTTLS".
Interesting. So the outside service's software has a hack in there to accept it without the tag? I wonder why? Maybe it's a workaround because some client software does it that way.
Anyway, with the tag it does work on IMAP. But it still fails on POP (which doesn't have tags, though I tried one anyway for kicks).
On Mon, May 24, 2010 at 11:49, Mike Abbott michael.abbott@apple.com wrote:
Anyway, with the tag it does work on IMAP. But it still fails on POP
For POP3 the command is STLS.
Well, that kinda complicates a "STARTTLS tunnel" :-) ... I was thinking of trying to do that to address some issues.
OK, well, put the emphasis on "seem" in my subject. It seems I made assumptions about the protocols.
Well, that kinda complicates a "STARTTLS tunnel"
Perhaps you might be interested in these commands. I'm not sure about their portability but they work tolerably well in scripts on Mac OS X 10.6.
$ openssl s_client -connect yourhost:imap -starttls imap $ openssl s_client -connect yourhost:pop3 -starttls pop3
$ openssl s_client -connect yourhost:imaps $ openssl s_client -connect yourhost:pop3s
$ openssl s_client -connect yourhost:smtp -starttls smtp
On Mon, May 24, 2010 at 17:31, Mike Abbott michael.abbott@apple.com wrote:
Well, that kinda complicates a "STARTTLS tunnel"
Perhaps you might be interested in these commands. I'm not sure about their portability but they work tolerably well in scripts on Mac OS X 10.6.
$ openssl s_client -connect yourhost:imap -starttls imap $ openssl s_client -connect yourhost:pop3 -starttls pop3
$ openssl s_client -connect yourhost:imaps $ openssl s_client -connect yourhost:pop3s
$ openssl s_client -connect yourhost:smtp -starttls smtp
Yeah, that can be used, perhaps best with expect or pexpect. I'm hoping to find tools that can do basic email functions at a higher level, where the user of the tool does not need to know the protocol details, but only needs to consider the same kinds of configuration aspects that configuring a regular email client involves (except without all the misleading and often erroneous terminology used by these GUI client developers ... such as "TLS" for STARTTLS/STLS on clear ports, and "SSL" for wrapped/tunneled TLS/SSL connections on always-encrypted ports as used in Evolution).
At some point I think I need to learn the OpenSSL library API for C so I can write some command line tool apps of my own with it (now we're getting well off the Dovecot topic).
On 5/24/2010 4:46 PM, Phil Howard wrote:
On Mon, May 24, 2010 at 17:31, Mike Abbottmichael.abbott@apple.com wrote:
Well, that kinda complicates a "STARTTLS tunnel"
Perhaps you might be interested in these commands. I'm not sure about their portability but they work tolerably well in scripts on Mac OS X 10.6.
$ openssl s_client -connect yourhost:imap -starttls imap $ openssl s_client -connect yourhost:pop3 -starttls pop3
$ openssl s_client -connect yourhost:imaps $ openssl s_client -connect yourhost:pop3s
$ openssl s_client -connect yourhost:smtp -starttls smtp
Yeah, that can be used, perhaps best with expect or pexpect. I'm hoping to find tools that can do basic email functions at a higher level, where the user of the tool does not need to know the protocol details, but only needs to consider the same kinds of configuration aspects that configuring a regular email client involves (except without all the misleading and often erroneous terminology used by these GUI client developers ... such as "TLS" for STARTTLS/STLS on clear ports, and "SSL" for wrapped/tunneled TLS/SSL connections on always-encrypted ports as used in Evolution).
Mail::POP3Client works pretty well. Net::IMAP::Simple looks easy too, but I've not used it. Ken
At some point I think I need to learn the OpenSSL library API for C so I can write some command line tool apps of my own with it (now we're getting well off the Dovecot topic).
-- Ken Anderson Pacific Internet - http://www.pacific.net
On Mon, May 24, 2010 at 17:59, Ken A ka@pacific.net wrote:
Mail::POP3Client works pretty well. Net::IMAP::Simple looks easy too, but I've not used it. Ken
At some point I think I need to learn the OpenSSL library API for C so I can write some command line tool apps of my own with it (now we're getting well off the Dovecot topic).
I would be looking for components in languages I know (C a lot and Pike some) or am learning (Python).
On 05/25/2010 12:03 AM Phil Howard wrote:
I would be looking for components in languages I know (C a lot and Pike some) or am learning (Python).
Python's standard library provides all you need: - http://docs.python.org/library/poplib.html - http://docs.python.org/library/imaplib.html
Regards, Pascal
The trapper recommends today: cafebabe.1014500@localdomain.org
On Mon, May 24, 2010 at 18:13, Pascal Volk user+dovecot@localhost.localdomain.org wrote:
On 05/25/2010 12:03 AM Phil Howard wrote:
I would be looking for components in languages I know (C a lot and Pike some) or am learning (Python).
Python's standard library provides all you need: - http://docs.python.org/library/poplib.html - http://docs.python.org/library/imaplib.html
Yes, it does. But, unfortunately, my level of Python is not yet where I can just "whip something up". if there was a library for C, I could have. I should check what Pike has.
On 5/24/2010 6:13 PM, Pascal Volk wrote:
On 05/25/2010 12:03 AM Phil Howard wrote:
I would be looking for components in languages I know (C a lot and Pike some) or am learning (Python).
Python's standard library provides all you need: - http://docs.python.org/library/poplib.html - http://docs.python.org/library/imaplib.html
Regards, Pascal
The openssl client will connect you in plain text to your imap server where you can manually do login (AUTH LOGIN) and browse through your imap folders just like you use your SSH shell. This is a sufficient enough test. Refer here, after doing what Mike Abbott told you to do with openssl s_client: http://www.macgeekery.com/tips/troubleshooting/troubleshooting_imap
On Tue, May 25, 2010 at 16:31, Jerrale Gayle jerralegayle@sheltoncomputers.com wrote:
The openssl client will connect you in plain text to your imap server where you can manually do login (AUTH LOGIN) and browse through your imap folders just like you use your SSH shell. This is a sufficient enough test. Refer here, after doing what Mike Abbott told you to do with openssl s_client: http://www.macgeekery.com/tips/troubleshooting/troubleshooting_imap
The test I want to do requires deleting the existing mail after fetching it ... so that subsequent runs won't see that mail, again. There will be timestamp coded info in that email, too (though it would fit on the subject). So it seems something like fetchmail could work. But I do need to do this test in a variety of different ways specified by a script, so the ability to specify those things on the command line or environment is preferred over doing it by means of a config file. Specifying them by means of running an interactive program is out. These things include what server to connect to (by hostname or IP address), what certificate hostname to expect (may be different than the connect host, since these tests may be running through tunnels), what port to connect to, whether to operate in clear vs. use STARTTLS vs. use SSL wrapper, what password authentication scheme to use, the password itself, and the local directory for the mail transfer (where to get mail to send/submit, or where to deposit mail fetched ... maildir format preferred for that).
This is about operational testing, not implementation or deployment testing. It will be run on a regular basis and the scripts will log the results in various places, including notifying operators and/or administrators depending on the issues discovered. Among the tests will include tests that are expected to fail (for example connecting to port 465, or logging in without enabling TLS) and will raise an issue if they succeed. Every test unit will have a unique user@domain. Some tests will even be specifically testing domains (every domain, though not every hostname, will have a test unit). I expect a few hundred test units to be deployed for the mail system (some offsite ... that's to be tested, too).
participants (5)
-
Jerrale Gayle
-
Ken A
-
Mike Abbott
-
Pascal Volk
-
Phil Howard