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 server Reproducible: Always Steps to Reproduce: 1. 2. 3.
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 nicely. 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 Sounds good. > 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 I've encountered.
Ok, I changed how the authentication works completely, so now there's an option to do: * 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.