[Users] [Bug 3612] New: auto-configure sets POP=SSL & SMTP=SSL/STARTTLS
Pierre Fortin
pf at pfortin.com
Sat Feb 6 20:14:24 CET 2016
On Sat, 6 Feb 2016 17:37:29 +0100 Albert ARIBAUD wrote:
>Bonjour,
>
>Le Sat, 6 Feb 2016 11:09:25 -0500
>pf at pfortin.com a écrit:
>
>> On Sat, 6 Feb 2016 09:47:06 +0100 Albert ARIBAUD wrote:
>>
>> >Bonjour,
>> >
>> >Le Sat, 06 Feb 2016 02:48:18 +0000
>> >noreply at thewildbeast.co.uk a écrit:
>> >
>> >> http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3612
>> >>
>> >> Bug ID: 3612
>> >> Summary: auto-configure sets POP=SSL & SMTP=SSL/STARTTLS
>> >> Classification: Unclassified
>> >> Product: Claws Mail
>> >> Version: GIT
>> >> Hardware: PC
>> >> OS: Linux
>> >> Status: NEW
>> >> Severity: enhancement
>> >> Priority: P3
>> >> Component: Other
>> >> Assignee: users at lists.claws-mail.org
>> >> Reporter: pf at pfortin.com
>> >>
>> >> Setting up new accounts with auto-configure results in:
>> >> POP3 = SSL
>> >> SMTP = SSL/STARTTLS
>> >>
>> >> Here's the DNS responses I get on clicking auto-configure:
>> >> _pop3s._tcp.pfortin.com: type SRV, class IN, priority 10, weight 1,
>> >> port 995, target pop-2.luxsci.com
>> >> _submission._tcp.pfortin.com: type SRV, class IN, priority 0,
>> >> weight 1, port 6465, target secure-email-2.luxsci.com
>> >>
>> >> POP3 & SMTP are usually set the same way... this difference may not
>> >> be obvious to new users.
>> >
>> >Hmm... apart from the fact that the bug report summary does not
>> >clearly state what the problem is,
>>
>> It's an *enhancement*; but based on further investigation, it's
>> beginning to appear like a STARTTLS bug...
>>
>> >why *should* POP and SMTP be set the same way?
>>
>> Conversely, why should they NOT be set the same way?
>
>Because the infrastructures for sending and receiving mail have no
>reason to be the same or to share identical technical choices.
>
> I run two
>>> instances of CM with a total of 15 active email accounts (nearly as
>> many retired) and ALL of them are set to:
>> POP3 = SSL (orthogonally: I hate IMAP)
>> SMTP = SSL
>
>Do you conclude from this thatb STARTTLS should never be used? :)
>
>> >Those are different services and may well imply different settings
>> >without anything being wrong.
>>
>> I tried changing POP3 from SSL to SSL/STARTTLS and EVERY server access
>> resulted in:
>> ** Session timed out. You may be able to recover by increasing the
>> timeout value in Preferences/Other/Miscellaneous.
>
>So you have tried mis-using a service and ended up with a
>non-functional setting. This seems pretty normal to me.
>
>> So I suppose a _bug_ report could be opened against misleading
>> information :)
>
>I am still not understanding what here is misleading. Each POP3 service
>provider, as well as, and independently of, each SMTP service provider,
>even for the same domain, may choose its own settings freely. The goal
>of auto-configuration is to get the settings from the provider in some
>way, then apply them. If you get the provider settings then apply some
>other settings, then you are not doing auto-configuration, you're doing
>guess-configuration.
>
>> >What capabilities do your POP and SMTP servers announce on
>> >connection?
>>
>> Good question... and with very interesting results....
>>
>> ---------POP----------
>> Packet captures shows that while the CM settings are SSL, the
>> communications occur as TLSV1.2; the sequence is:
>> CM Server
>> SYN(wsz=29200,MSS=1460,SACK=1,...)
>> SYN,ACK(wsz=14480,MSS=1380,SACK=1,...)
>> ACK(calcWsz=29312)
>> Client Hello (TLSv1.2)
>> ACK
>> Server Hello (TLSv1.2)
>> etc....
>>
>> However, when set to STARTTLS, this is the ENTIRE exchange:
>> CM Server
>> SYN(wsz=29200,MSS=1460,SACK=1,...)
>> SYN,ACK(wsz=14480,MSS=1380,SACK=1,...)
>> ACK(calcWsz=29312)
>> FIN, ACK <===========<<<
>> ACK
>> FIN,ACK
>> ACK
>>
>> NO capabilities are ever announced because CM aborts the connection
>> instead of initiating the next step... is this what CM should be
>> doing? Up to this point, there is no information in the SYN sequence
>> telling the server what is coming... Now looking like a bug v. an
>> enhancement report...
>>
>> ---------SMTP----------
>> This too returns:
>> *** Session timed out. You may be able to recover by increasing the
>> timeout value in Preferences/Other/Miscellaneous.
>>
>> Wireshark reports:
>> CM Server
>> SYN(wsz=29200,MSS=1460,SACK=1,...)
>> SYN,ACK(wsz=14480,MSS=1380,SACK=1,...)
>> ACK(calcWsz=29312)
>> FIN, ACK <===========<<<
>> ACK
>> FIN,ACK
>> ACK
>>
>> -----------------------
>> 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...
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
Hello...
>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...?
>> >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
STARTTLS...
>> 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...
>> 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...
>Wouldn't know unless I knew which server (domain) you are talking
>about, so that I could check the advertised settings vs working
>settings.
Easy.... :)
$ dig +short srv _pop3s._tcp.pfortin.com
10 1 995 pop-2.luxsci.com.
$ dig +short srv _submission._tcp.pfortin.com
0 1 6465 secure-email-2.luxsci.com.
$ 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?
BTW, free.fr does not report SRV records, so no auto-config there...
So the plot thickens.... :)
>Amicalement,
De me^me
PS SSL is really SSL+TLS
[Take your time; I'm gone for the rest of the day... later...]
More information about the Users
mailing list