aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--NEWS4
-rw-r--r--fetchmail-SA-2006-02.txt3
2 files changed, 4 insertions, 3 deletions
diff --git a/NEWS b/NEWS
index fc36a49f..b5bdceec 100644
--- 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 1704512f..05a9a8f0 100644
--- 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.