Detail on missed CAPA probes.

svn path=/branches/BRANCH_6-3/; revision=4979

diff --git a/NEWS b/NEWS
index fc36a49f66b18124f096a89aad9e34f60e537696..b5bdceeceddfd692672ef6dc9bd32341eeb0239e 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -52,8 +52,8 @@ fetchmail 6.3.6 (not yet released):
     requested) fails with sslproto 'tls1' (also applies if this is implicit).
 
   - POP3 connections ignored STLS altogether in many circumstances, because
-    fetchmail did not probe server capabilities in all situations where it
-    should have done that.
+    fetchmail did not probe server capabilities for all values of "auth" - see
+    fetchmail-SA-2006-02.txt for details.
 
   - POP3 connections could retry USER/PASS authentication even if strong
     challenge-response schemes such as CRAM-MD5 had explicitly been requested,

diff --git a/fetchmail-SA-2006-02.txt b/fetchmail-SA-2006-02.txt
index 1704512f6cde34d8752fc80aee7b026afc7e0e99..05a9a8f07ad43233ea9136930fb3abf2aebb98d1 100644 (file)
--- a/fetchmail-SA-2006-02.txt
+++ b/fetchmail-SA-2006-02.txt
@@ -60,7 +60,8 @@ V3. POP3 fetches could completely ignore all TLS options whether
     available or not because it didn't reliably issue CAPA before
     checking for STLS support - but CAPA is a requisite for STLS.
     Whether or not CAPAbilities were probed, depended on the "auth"
-    option.
+    option. (Fetchmail only tried CAPA if the auth option was not set at
+    all, was set to gssapi, kerberos, kerberos_v4, otp, or cram-md5.)
 
 V4. POP3 could fall back to using plain text passwords, even if strong
     authentication had been configured.