[Users] [Bug 3612] New: auto-configure sets POP=SSL & SMTP=SSL/STARTTLS
albert.aribaud at free.fr
Sat Feb 6 21:15:29 CET 2016
Le Sat, 6 Feb 2016 14:14:24 -0500
Pierre Fortin <pf at pfortin.com> a écrit:
> >> So, in both POP & SMTP, CM aborts connections when set to
> >> STARTTLS...
> >What is the timing? Is the communication aborted as soon as started,
> >or is there a silent period (which could mean a time-out waiting for
> >the server's welcome banner, for instance).
> POP STARTTLS:
> CM ACK at 09:35:22.165738018
> CM FIN,ACK at 09:35:22.518216870 (352ms)
> SMTP STARTTLS:
> CM ACK at 10:42:16.976440538
> CM FIN,ACK at 10:42:27.516643314 (10.54 seconds)
> Quite a difference in times...
Yes, but then, this is *not* STARTTLS, this is pure TCP connection (on
unspecified ports -- are you using the advertised ports or did you
choose default ports based on protocol)?
> In both cases, I believe it's up to CM to proceed with the next step.
> When SSL is selected, CM issues a Client Hello instead of a FIN,ACK...
> With STARTTLS, CM waits & aborts while the server sits expecting a
When using STARTTLS, the server does not expect a hello; it should
answer with a banner (both in POP and SMTP IIRC) as soon as it is ready
> >BUT... if the server does not support STARTTLS, it may not support
> >cleartext connections at all.
> How would the server know what is coming next if CM aborts & never
> attempts the connection beyond the SYN sequence...?
I did not say it needed to know what is coming next. STARTTLS support
is just "support cleartext session initiation and offer STARTTLS
capability" (possibly on a specific port), so no knowledge is needed;
but a server may decide not to support STARTTLS therefore, if plaintext
is not an option, not to support plaintext at all.
> >> >This may influence the auto-configuration process.
> >> How? The auto-configuration is based on DNS SRV records, nothing
> >> else as witnessed by a wireshark capture:
> >> CM sends 2 packets:
> >> DNSq: _pop3s._tcp.domain.tld: type SRV, class IN
> >> DNSq: _submission._tcp.domain.tld: type SRV, class IN
> >> and gets these responses ~230ms later:
> >> DNSr: _pop3s._tcp.pfortin.com: type SRV, class IN, priority 10,
> >> weight 1, port 995, target pop.service.tld
> >> DNSr: _submission._tcp.pfortin.com: type SRV, class IN,
> >> priority 0, weight 1, port 6465, target smtp.service.tld
> >> Nothing else...
> >> If STARTTLS doesn't work at all, then that would imply that only
> >> SSL is required (note that SSL actually uses TLSv1.2 in the
> >> wireshark captures) and STARTTLS may be redundant...
> >STARTTLS may work or not depending on the server setting. But if it
> >is supposed to work, then the server should accept cleartext
> >connections, if only to let the client send the STARTTLS command --
> >and this means the server should send a banner and respond to a EHLO
> >with a list of its capabilities.
> Again... CM *aborts* the connection rather than proceed normally...
> In the case of SMTP SSL, CM's next packet is a PSH,ACK v. FIN,ACK with
Have you tried the advertised supported methods manually (via openssl
for the SSL part)? Do they work that way? If they do, and if CM fails
with the same settings, then CM is at fault. If they fail manually, then
there is an issue with the domain mail servers setup. And if the
settings you use are not the ones advertised, then all bets are off.
> >> Over the years, I never noticed that _all_ my accounts are set to
> >> SSL. When I've had problems setting up new ones, I recall having
> >> to make changes to the SSL pane...
> >> Based on my wireshark captures, can anyone be using STARTTLS
> >> successfully?
> >Depends on the server -- IP+port: some providers have SSL service on
> >one port, STARTTLS on another one.
> Yup... that's by convention -- nothing magical about port v. service
> (note luxsci.com uses 6465 for SMTP); but you still seem to be
> refusing to recognize what I'm reporting... that CM in STARTTLS mode
> *aborts* rather than proceeding to the next step...
I refuse nothing; I just try and check everything. Does this STARTTLS
on port 6465 work manually (in cleartext until STARTTLS is issued? Does
CM with the same settings work?
> >> What am I missing?
> Note to self: if there's a SSL+TLS v. STARTTLS clue/hint in the SYN
> sequence, I still don't see it...
There cannot be. These sequences are TCP/IP, below, and ignorant of,
> >Wouldn't know unless I knew which server (domain) you are talking
> >about, so that I could check the advertised settings vs working
> Easy.... :)
> $ dig +short srv _pop3s._tcp.pfortin.com
> 10 1 995 pop-2.luxsci.com.
openssl s_client -connect pop-2.luxsci.com:995 shows the server banner
('+OK POP3 rs143.luxsci.com 2010.104 server ready').
Seems like this sever is correctly configured.
> $ dig +short srv _submission._tcp.pfortin.com
> 0 1 6465 secure-email-2.luxsci.com.
Trying 'openssl s_client -connect secure-email-2.luxsci.com:6465
-starttls smtp' only shows 'CONNECTED(00000003)' and stands there.
A comparison to a known-to-work STARTTLS-capable sever shows that such
a server immediately emits a banner on connection and provides its
capabilities (including STARTTLS) upon receiving the client's EHLO
(although the EHLO is not required and one can STARTTLS right after
> $ dig +short srv _pop3s._tcp.gmail.com
> 20 0 995 pop.gmail.com.
> $ dig +short srv _submission._tcp.gmail.com
> 5 0 587 smtp.gmail.com.
> >What I know is, I've got many accounts set to SSL for both
> >POP and SMTP, and one set to SSL for POP and STARTTLS for SMTP, and
> >all work well -- but I can't swear they were all auto-configured.
> Have you sent from the STARTTLS one lately? Does it fail with SSL?
"Does [STARTTLS] fail with SSL" has no sense. STARTTLS cannot be "with"
or "without" SSL; STARTTLS starts TLS, which *is* SSL in this context.
STARTTLS aims at switching to SSL. STARTTLS cannot work without SSL.
Maybe you mean " do you use an account where POP3 is SSL and SMTP is
STARTTLS, and does it work?" in which case yes, I do, and yes, it does.
> BTW, free.fr does not report SRV records, so no auto-config there...
Nop, they don't. OTOH, they describe the settings explicitly to their
users, and IIRC, they allow using the standard ports (among others
IIRC), so guess-configuring normally works.
> So the plot thickens.... :)
I think the first thing is to determine whether the target servers are
correctly set; I think the POP part is, I am not sure the SMTP part is.
> PS SSL is really SSL+TLS
I assume that by this you mean "when speaking about SSL, we in
fact speak about either SSL or TLS".
More information about the Users