It's a shame that this bug wasn't fixed for sarge.
The main problem, as I see it, is that stated by Daniel Dehennin in his
addendum to the initial report: when one sets POP3_TLS_REQUIRED=1 in
/etc/courier/pop3d-ssl, the pop3s service on port 995 *requires* STLS
even though the session is already TLS-wrapped.
This prevents people from securely offering both pop3 on port 110 (with
mandatory STLS before passwords are sent) and pop3s on port 995. Clients
like mutt will (quite reasonably) not issue STLS when the session is
already SSL-wrapped.
Here is a patch to the startup script that solves the problem:
--- /etc/init.d/courier-pop-ssl.orig 2005-10-13 13:59:15.000000000 +0200
+++ /etc/init.d/courier-pop-ssl 2005-10-13 13:58:48.000000000 +0200
@@ -68,6 +68,7 @@
/bin/sh -c " . ${sysconfdir}/pop3d ; \
. ${sysconfdir}/pop3d-ssl ; \
POP3_TLS=1 ; export POP3_TLS ; \
+ POP3_TLS_REQUIRED=0; export POP3_TLS_REQUIRED; \
`sed -n '/^#/d;/=/p' <${sysconfdir}/pop3d | \
sed 's/=.*//;s/^/export /;s/$/;/'`
`sed -n '/^#/d;/=/p' <${sysconfdir}/pop3d-ssl | \
As for Andreas Metzler's suggestion that one shouldn't offer STLS in the
first place when the session is already SSL-wrapped, that seems mostly
cosmetic (is this why the bug report wasn't acted on?), unless the
daemon is actually incapable of supporting STLS on an already-wrapped
connection (I haven't tested). I suppose one could extend the above
patch to include
POP3_STARTTLS=NO; export POP3_STARTTLS; \
and fix that issue as well. I just tested, and it seems to work.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
