The new option ssl_force_tls (intended as a replacement for imap_force_ssl, at least according to the ChangeLog) doesn't work. mutt can only connect to my IMAPS server (SSL only) if I tell it explicitly to use SSL (i.e. use {server/ssl} instead of {server}). Reproducible: Always Steps to Reproduce: 1. set ssl_force_tls 2. set spoolfile='{imap.sascha.silbe.org}INBOX' 3. start mutt 4. set spoolfile='{imap.sascha.silbe.org/ssl}INBOX' 5. start mutt Actual Results: Step 3: connection gets refused Step 5: everything works fine Expected Results: Step 3: everything works fine Step 5: everything works fine Gentoo Base System version 1.6.13 Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.11.6-infra-cube-1 i686) ================================================================= System uname: 2.6.11.6-infra-cube-1 i686 AMD Athlon(tm) XP 1700+ distcc 2.18.3 i586-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i586-pc-linux-gnu" CFLAGS="-march=pentium -mcpu=athlon-xp -O3 -pipe" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /usr/vice/etc /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/afs/C /etc/afs/afsws /etc/afs/modload /etc/gconf /etc/make.globals /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium -mcpu=athlon-xp -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distcc distlocks fixpackages sandbox sfperms strict test userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.easynet.nl/mirror/gentoo/ http://gentoo.inode.at/ ftp://gentoo.inode.at/source/" LANG="en_US" LINGUAS="en,de" MAKEOPTS="-j10 -s" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp/portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage-local--main--1.0" SYNC="rsync://copper.sascha.silbe.org/gentoo-portage" USE="x86 3dnow 3dnowext S3TC X a52 aac accessibility acl afs alsa apm audiofile avi bash-completion berkdb bitmap-fonts blas bzip2 bzlib cdparanoia cdr chipcard cjk crypt curl doc dts dv dvd dvdr dvdread ecc eds emboss encode examples exif expat fam fame ffmpeg flac foomaticdb fortran gd gdbm geldkarte gif gimpprint glut gmp gstreamer gtk gtk2 gtkhtml guile hbci idn imagemagick imap imlib ipv6 j-noaim j-nomsn j-noyahoo jabber jpeg jpeg2k lapack lcms libg++ libwww lm_sensors lua lvm1 lzo mad maildir mailwrapper makecheck mbox mikmod mjpeg mmx mmxext mng monitor mozsvg mp3 mpeg mysql nas ncurses nls nodrm offensive ogg oggvorbis openal opengl oss pam pcre pda pdflib plotutils png postgres python qt qtmt quicktime readline recode samba scanner sdl serial skey smartcard speex spell sqlite sse ssl svg sysfs test tetex theora tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis win32codecs xine xml xml2 xv xvid yv12 zlib linguas_en,de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS
Is that server accepting TLS connections on the default imap port ? Anyway, I wouldn't consider this a Gentoo bug. If anything this is an upstream bug. Cheers, Ferdy
The server is only accepting SSL connections on the imaps port (993). No plain-text-connect-and-agree-to-switch-to-ssl hack whatsoever.
(In reply to comment #2) > The server is only accepting SSL connections on the imaps port (993). No plain-text-connect-and-agree-to-switch-to-ssl hack whatsoever. > Well, then it can't work, if it's not supported on server side, this is not a bug (though I suspect that trying TLS also if not advertised by the server breaks an RFC or two ;p). Otherwise, it does what's documented - forces encrypted connections. Encryption is not available on imap:// port unless server supports TLS, so it properly fails. With imaps:// the connection is encrypted via SSL, so it works. Not a bug, IMHO.
Indeed... not a bug. Cheers, Ferdy
