IMAP checking does not work here. Here's the error output:
DBG[mailwatch-mailbox-imap.c:510] imap_connect(): checking for a connection...
DBG[mailwatch-mailbox-imap.c:523] imap_connect(): connection succeeded
DBG[mailwatch-mailbox-imap.c:434] imap_do_starttls(): checking for STARTTLS caps
(145): * CAPABILITY CHILDREN ID IDLE IMAP4 IMAP4rev1 LITERAL+ LOGIN-REFERRALS
MAILBOX-REFERRALS NAMESPACE UIDPLUS QUOTA STARTTLS AUTH=PLAIN AUTH=LOGIN
DBG[mailwatch-mailbox-imap.c:594] imap_authenticate(): res is 0
DBG[mailwatch-mailbox-imap.c:632] imap_authenticate(): using_ssl is TRUE
** (xfce4-panel:4870): CRITICAL **: TLS handshake failed: A record packet with
illegal version was received.
DBG[mailwatch-mailbox-imap.c:746] imap_check_mail(): failed to connect to imap
Steps to Reproduce:
If you need an account on that server to test, write me private mail or via
Jabber (bwalle AT jabber DOT ccc DOT de).
Actually, the mail server is broken. It's advertising that it supports the
STARTTLS command, but it's failing. I'm not sure if it's the server's fault, or
the fault of how I'm using gnutls. Not really sure what to do here, or if this
is even my bug.
What I don't understand is: Why are you trying to use SSL if the checkbox
"require secure connection" is not checked?
Because "don't require" doesn't mean "don't try".
ok, you're right :)
It would be very good if you could add an option "disable secure connection".
Thunderbird has the same, SSL fails in Thunderbird, too.
But even imap_auth_plain(imailbox, username, password) fails at this server.
Don't know what it supports, but it must be one of gssapi or cram-md5 because
Mutt can connect to this server.
Yeah... My original idea was to make it as configuration-less as possible, but
it doesn't seem to have worked out well. If connection timeouts weren't so long
(generally, people like to break the internet by dropping packets destined for
closed ports, rather than explicitly refusing connections, with some vague
unfounded belief that this is somehow more "secure"), it would work out rather
So, I guess really the only thing to do is have a dropdown box with choices like:
* Require secure connection
* Use secure connection, if available
* Use plaintext authentication
I suppose I'll also have to have an "advanced" dialog that let's you specify
whether to use STARTTLS or direct TLS negotiation on an alternate port. Meh.
For your case, your mail server is advertising that it supports TLS when it
actually doesn't. So you should really get in touch with your provider and
bitch at them. It's broken and violates the RFC.
Note that imap_auth_plain() isn't just for insecure auth - it's actually always
used, just sometimes within a TLS session. Your mail server reports AUTH=PLAIN,
so the standard
00001 LOGIN "username" "password"
should work (this is what imap_auth_plain() does). If not, again, the mail
server is broken.
> generally, people like to break the internet by dropping packets destined for
> closed ports, rather than explicitly refusing connections, with some vague
> unfounded belief that this is somehow more "secure"
I know. :(
> * Require secure connection
> * Use secure connection, if available
> * Use plaintext authentication
> For your case, your mail server is advertising that it supports TLS when it
> actually doesn't. So you should really get in touch with your provider and
> bitch at them. It's broken and violates the RFC.
I'll write a mail to the provider. I don't think that I succeed (thinking of a
"works with Outlook" answer).
00001 LOGIN user pass
works in a Telnet session, so I think I just patched the code wrong.
As a somewhat related note I'd like to point out that leaving out the choice of
imap port from the user and relying on service name might cause problems, as
some distros seem to ship with a /etc/services file in which there is no "imap"
service listed. The service name for port 143 is "imap2" in the installations
Ok, I changed how the authentication works completely, so now there's an option
* Use unsecured connection
* Use SSL/TLS on alternate port
* Use SSL/TLS via STARTTLS
Yeah, I know, users might be a little confused what that means, but we can deal
with that later.
Pasi: can you elaborate on the service name problem? Like, specific systems
without those entries. If you think it's a problem, please open a new bug for
it, and I'll work in it (eventually =p).
I encountered the service name problem in Gentoo, whose recent baselayout
updates fixed it. I guess this problem isn't one we should worry about, as these
imo are distribution related problems.