Since some time (a few weeks), I can't send mails anymore with Trojita. Probably, this is problem with my mail provider GMX, because it happens both with version 0.5 and 0.6, but I don't know how to debug it … When sending a mail, it's added to the "Sent" IMAP folder, but the sending process bar hangs at 50 % and nothing happens. The mail is not actually sent, just added to the "Sent" folder. So I think the IMAP stuff still works, but the SMTP stuff doesn't. Reading the IMAP protocol, it only says: 15:33:05.459 Network Session User's preference changed: NETWORK_ONLINE 15:33:05.459 Network Session Switched to network configuration enp3s0 (Ethernet, 3278187404) 15:33:05.459 Network Session Opening network session 15:33:05.459 Network Session Session is open (configuration enp3s0), online state: online 15:33:57.965 Submission STATE_INIT 15:33:57.971 Submission STATE_BUILDING_MESSAGE 15:33:57.979 Submission STATE_SAVING 15:33:58.052 Submission STATE_SUBMITTING But, as said, nothing happens, the progress bar stays at 50 % forever. Same thing on two different machines, one using x86 and one amd_64, but both trying to send mails via GMX. I would really like to debug this further if someone told me how ;-) Reproducible: Always
SMTP submission prints out stuff to stderr, so please: 1) ensure Trojita is not running, 2) start Trojita from console, 3) try sending e-mail as usual, 4) attach the log from console here, 5) reopen.
Common fails: ---- nb. that *web.de* like gmail.com recently requires you to allow acces via smtp (the defaults seemed to have been added randomly...) For gmx, ensure to use the full mail address as login (tobias.leup...@gmx.de) and smtp.gmx.de:465 Most importantly do not mix TLDs, ie. smtp.gmx.net won't work for *.de logins et vv.
I thought port 465 was outdated and clients should use port 587? Just saying, with KMail, I use mail.gmx.net:587 with my @gmx.de address and it works just fine … So here's what the console said: With mail.gmx.net:587 and STARTTLS (which used to work just fine until recently), I get: SMTP ** connectToHost SMTP <<< 220 gmx.com (mrgmx102) Nemesis ESMTP Service ready SMTP >>> "EHLO localhost\r\n" SMTP <<< 250-gmx.com Hello localhost [87.171.206.252] SMTP <<< 250-SIZE 69920427 SMTP <<< 250-AUTH LOGIN PLAIN SMTP <<< 250 STARTTLS SMTP >>> STARTTLS SMTP <<< 220 OK SMTP ** startClientEncruption SMTP >>> "EHLO localhost\r\n" SMTP <<< 250-gmx.com Hello localhost [87.171.206.252] SMTP <<< 250-SIZE 69920427 SMTP <<< 250 AUTH LOGIN PLAIN SMTP >>> AUTH PLAIN and then, it hangs. With mail.gmx.net:465, I can't even connect when using STARTTLS: only: SMTP ** connectToHost And a message "The remote host closed the connection". With both mail.gmx.net:465 and mail.gmx.de:465 and TLS instead of STARTTLS, I get: SMTP ** connectToHostEncrypted SMTP >>> "EHLO localhost\r\n" SMTP <<< 220 gmx.com (mrgmx102) Nemesis ESMTP Service ready SMTP <<< 250-gmx.com Hello localhost [87.171.206.252] SMTP <<< 250-SIZE 69920427 SMTP <<< 250 AUTH LOGIN PLAIN SMTP >>> AUTH PLAIN And it always hangs as described. So probably, the AUTH PLAIN step is what causes the trouble?
smtps is more robust than starttls (at least in the gmx.net case, because if anything goes wrong they fell back to the unencrypted variant which was oc. blocked ... ;-) 465 is smtps, so starttls will naturally fail. That said, it fails. The server will timeout and afterwards you'll get: SMTP <<< 334 421 gmx.com Service closing transmission channel - command timeout SMTP <<< [authentication data] Nuking AuthPlain in qwwsmtpclient.cpp (ie. enforcing LOGIN) works like a charm. PLAIN authentication on gmail works like a charm. => gmx broke PLAIN authentication and it's unfortunately preferred by qwwsmtp. Since LOGIN is announced first, kmail will likely just use that (for the order) Seems to have been a problem on kmail around 2005 as well: https://bugs.kde.org/show_bug.cgi?id=67797#c70 => I guess it would be required to either allow config of the preferred authentication or prefer the announced order (what could be just as much troublesome) or walk them on each timeout (what's oc. outmost crap, sending a mail could easily last 10 minutes - every time!)
PS: src/qwwsmtp/qwwsmtp.cpp:553, make it if (false || s.toLower() == "plain") this is oc. a terrible hack that will easily kill smtp servers only supporting PLAIN. PPS: the amount of "smtp gmx auth plain" on google results is just stunning...
(In reply to Thomas Lübking from comment #5) > PS: src/qwwsmtp/qwwsmtp.cpp:553, make it > > if (false || s.toLower() == "plain") false && ... shall work much better. it's too hot.
(In reply to Thomas Lübking from comment #4) > gmx broke PLAIN authentication and it's unfortunately preferred by > qwwsmtp. Well, that sucks ;-) I fear that even if one contacted the GMX folks saying "Your server is broken", not much will happen … anyway, I'll try to do so. Thanks for tracking this down. Would be nice if some solution (like configurable SMTP auth, fallback or something) could be implemented in Trojita, as sadly, not everybody respects standards like we can see here …
PLAIN is mantory by the standard, LOGIN is not even a "real" standard =) GMX mandates the *optional* initial-response data (and mandate it to be the login data) Sending "AUTH PLAIN =\r\n" gets me an immediate response about wrong credentials. sending "AUTH PLAIN " and then calling setAuthPlain("<login>", "<passwort>"); works "as expected".
Apparently, GMX fixed it. At least, I can send mail again using the very same Trojitá versions ;-)
That's a pleasant surprise. Thanks :).