Closed Bug 258077 Opened 20 years ago Closed 20 years ago

TB will not authenticate with POP3 server -since 20040824

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: robw810, Assigned: ch.ey)

References

(
URL
)

Details

(Keywords: fixed-aviary1.0)

Attachments

(2 files, 1 obsolete file)

Log file of POP3 server transactions
10.09 KB, text/plain
Details
proposed patch
1.39 KB, patch
Bienvenu
: review+
mscott
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040904 Firefox/1.0 PR (NOT FINAL) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040904 Firefox/1.0 PR (NOT FINAL) On an account with new messages on the server, TB returns "no new messages." On all of my other accounts, TB works correctly. The 20040821 Branch build works properly with the same profile (no account settings changed). More detailed information is in this thread: http://forums.mozillazine.org/viewtopic.php?p=767300#767300 and this thread: http://forums.mozillazine.org/viewtopic.php?p=767298#767298 Also, I will create an attachment of the log created. Reproducible: Always Steps to Reproduce: Using latest branch build, check mail on a simplecom.net account. Actual Results: Server responds with: -ERR authentication exchange failed -ERR An authentication mechanism MUST be entered -ERR Invalid userid/password yet the userid/password combination is correct Expected Results: TB should have authenticated with the simplecom.net POP3 server, recognized that there were new messages, and downloaded them. -secure authentication is not accepted by simplecom.net -new profile does not remove bug -no extensions -also experienced with clean install (new directory) and new profile in new user account in Slackware 10
the log says you have a bad user name or password: 0[274630]: Entering NET_ProcessPop3 30 0[274630]: POP3: Entering state: 3 0[274630]: RECV: -ERR Invalid userid/password
(In reply to comment #2) > the log says you have a bad user name or password: I know, but I *don't* have a bad username/password combo - with absolutely NO changes to account settings, I can unzip an older branch build (20040821) and it works fine. Also, the same username/password combo works correctly in Outlook, Outlook Express, and the full Mozilla Suite. RW
> the same username/password combo works correctly in the full Mozilla Suite. Also in builds >= 20040825? That would be strange. I'm quite sure it was my patch from bug 256294 that made a server bug visible. The answers -ERR authentication exchange failed -ERR An authentication mechanism MUST be entered to our first AUTH command are understandable since AUTH without parameter isn't defined in an RFC. But we need to send it since most servers need it to send out the accepted mechanisms (while compliant servers like yours use CAPA for this). But ok, these -ERR don't harm. The server cobra.simplecom.net has to bugs. First it goes into LOGIN mode although it advertises it knows PLAIN and we send "AUTH PLAIN" (also verified manually via telnet). This fails: SEND: AUTH PLAIN RECV: + VXNlcm5hbWU6 (<- is username request of LOGIN mechanism) SEND: authentication (<- is username+password of PLAIN mechanism) RECV: + UGFzc3dvcmQ6 (<- is password request of LOGIN mechanism) SEND: STAT (requested since we took the previous + of the password request as "accepted" of our username+password) RECV: + UGFzc3dvcmQ6 (server tries again to request password) SEND: QUIT (we quit since we don't see new messages (UGFzc3dvcmQ6 was seen as response to our STAT command and decoded to 0 messages)) RECV: -ERR Invalid userid/password We'd fall back to LOGIN mechanism if it'd be obvious to us that our PLAIN attempt failed. But I don't see a way to detect this misunderstanding here. Please contact your server admin and report the problem it uses LOGIN authentication though the client requested PLAIN. He should either correctly use PLAIN if requested or disable advertising PLAIN at all.
Received this from Corey (support@simplecom.net) after forwarding bug info to him: + UGFzc3dvcmQ6 decodes to "Password:" not to "0 messages" The client is not sending hte password when it is requested. Here is a successful conversation with the server (login obscured of course) Server: +OK X1 NT-POP3 Server cobra.simplecom.net (IMail 7.15 28001-1) Client: AUTH PLAIN Server: + VXNlcm5hbWU6 Client: Y------0 (base64 of username obscured by -) Server: + UGFzc3dvcmQ6 Client: Z--------------= (base64 of password obscured by -) Server: +OK maildrop locked and ready Client: stat Server: +OK 101 321845 Client: quit Server: +OK POP3 Server saying Good-Bye
> + UGFzc3dvcmQ6 decodes to "Password:" not to "0 messages" Yes, if we'd handle UGFzc3dvcmQ6 as response in LOGIN mechanism and would base64 decode it. But since we think it's the response to our STAT command we don't decode it but to atol(UGFzc3dvcmQ6) and that's 0. > The client is not sending hte password when it is requested. Mozilla sends username and password according to RFC 2595 ("The mechanism consists of a single message from the client to the server. The client sends the authorization identity (identity to login as), followed by a US-ASCII NUL character, followed by the authentication identity (identity whose password will be used), followed by a US-ASCII NUL character, followed by the clear-text password." Additionally this whole string is base64 coded.) in response to the first positive answer (+) to our command "AUTH PLAIN". Mozilla believes if PLAIN authentication has been requested, and the server replies with OK (+) it also performs PLAIN authentication. And so we behave like we're in PLAIN mode. Or see it the other way: > The client is not sending hte password when it is requested. Yes, and the server did not go into PLAIN authentication but LOGIN authentication when it is requested. So who made the first mistake?
OS: Windows XP → All
This is the latest response from Simplecom support: > Can the mail client be forced to use LOGIN instead of PLAIN? > that would seem to resolve the issue. > Barring that, you can always use the webmail interface http://simplecom.net:8383 I think it's dodging the larger issue, but that is a valid question - is there some way that I can force TB to use LOGIN for the simplecom.net server? As for the second comment, NO, I CAN'T - I don't WANT to use the webmail interface, just like I don't want to use Eudora, Outlook, Outlook Express, KMail, or anything else - I want to use Thunderbird, and I want simplecom's server to allow it... I know you developers are busy, so thanks for all that you do. More importantly , thank you for looking into a bug that appears to be caused by external factors... RW
>> Can the mail client be forced to use LOGIN instead of PLAIN? >> that would seem to resolve the issue. > > I think it's dodging the larger issue, but that is a valid question - is > there some way that I can force TB to use LOGIN for the simplecom.net server? Switching off PLAIN (i.e. recognizing the servers advertising it) would solve your problem, yes. A general way to switch specific mechanisms on or off would be needed to fit everyone's needs. The questions are with or without UI (if with, it should be put in the Advanced Settings to not confuse users) and how to save it to the prefs (single pref for each mechanism or bitfields)? But for your problem I think I've found something that helps you: the pref auth_login. It switches off any attempt to send AUTH and CAPA and just uses plain old USER/PASS authentication in clear text. It's a hidden pref and need to be put in prefs.js or user.js like this: user_pref("mail.server.server?.auth_login", false); Intead of the question mark you've to enter the server number for the server you want to switch it off.
Hardware: PC → All
I can just confirm that I have had a very, very similar experience with one of my mail accounts that all of a sudden stopped working with Thunderbird 0.8 (which I just downloaded). The workaround in comment #8 did help for me (adding the hidden prefs). Looking at the attached log looks very similar to what is going in when communicating with my SMTP server as well (smtp.kommunicera.umea.se).
This is baaad, at least for those unlucky enough to be affected by it. I just got an angry "why haven't you responded to my email" phone call because I haven't received my mail all morning. What a bad indoctrination for new users (or those who have just upgraded to .8). Here is one affected mail server: http://www.ipswitch.com/imail Could someone at least change the status to confirmed? You'll probably find a lot of new (and frustrated) .8 users querying for it.
I experience the same problem, but not on every account, just one. The others, which have the same security settings, are fine. The fix suggested in comment #8 works for me too.
Man - one buggy server, ok. But four revaled in that short time? I've gone through the RFCs and the code again but am still sure our behaviour is compliant. I'm happy the workaround does its job but that shouldn't become a final solution. In any case please notify your providers about what's going on (see my explanations in comments #6 and #8). I hope not everyone is as balky as simplecoms admin. Peter, I tested the server you wrote and it's indeed the same problem. Nathan, can you tell me a address where this server software is in use? But what could we do here? It would be possible to test if the response to our "AUTH PLAIN" command is VXNlcm5hbWU6 (or VXNlcm5hbWU= which is also possible) and switch to LOGIN method then. That's not nice but it shouldn't cause any problems. Besides such handlers make the code everything but clearer, it's a question of the policy to peruse. How far should we work around buggy servers or educate the admins at the expense of our users?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #10) > Here is one affected mail server: http://www.ipswitch.com/imail I now tested it on imail.ipswitch.com and yes, it shows the same problem. Since it also offers CRAM-MD5 as method you can also enable "Use secure authentication" in Mozilla/TB. So you don't have the PLAIN problem and get a more secure authentication. I couldn't test if the server implements CRAM-MD5 correct, but hope so.
At my office our iMail server's secure authentication does not work (for whatever bad reason), so plain is my only option. It's worth saying this plainly I think: There is at least one mail server out there that is incompatible with Thunderbird .8 when both are in their default configurations. (bad!)
(In reply to comment #12) > > But what could we do here? It would be possible to test if the response to our > "AUTH PLAIN" command is VXNlcm5hbWU6 (or VXNlcm5hbWU= which is also possible) > and switch to LOGIN method then. That's not nice but it shouldn't cause any > problems. > Besides such handlers make the code everything but clearer, it's a question of > the policy to peruse. How far should we work around buggy servers or educate the > admins at the expense of our users? Personally I think that you just must accept the fact that there are buggy or incorrectly configured servers out there. Going after the admins will not help. I myself was just planning on introducing Thunderbird to my father, and I do not want to explain hideous details like this to him why it does not work for him. If you want people to abandon Outlook Express (like my father is using right now), then it just must work even with buggy servers like http://www.ipswitch.com/imail. Add lots of comment in the code that this is workaround for this specific server. I'm not sure that testing against that it identifes itself as Imail is such a good solution, but then the workaround clearly indicates that it is Imail that it tries to handle. Having Thunderbird working is much better than a having a "not so nice" solution.
Let's not spam the bug report - Bugzilla is not the proper place to debate whether a bug should be fixed or not. Try to keep all comments in this forum thread: http://forums.mozillazine.org/viewtopic.php?p=767300#767300 RW
Christian, could you explain this part a bit more? >But what could we do here? It would be possible to test if the response to our >"AUTH PLAIN" command is VXNlcm5hbWU6 (or VXNlcm5hbWU= which is also possible) >and switch to LOGIN method then what does "VXNlcm5hbWU6" mean? Do we literally check for that string? If that fixes our handling of 4 broken servers, then I think it's worthwhile. While ultimately we should have UI for enabling/disabling various authentication mechanisms, if we we have a way of handling it without bothering the user, that's preferrable. If we do implement the UI, we could disable this fallback hack for users that have explicitly picked an authentication mechanism.
*** Bug 257299 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > If you want people to abandon Outlook Express (like my father is using right > now), then it just must work even with buggy servers like > http://www.ipswitch.com/imail. Oh stupid me. I just recognized that all problematic servers reported here (don't know about homers) use IMail. Though it seems a widely used I'm happy to see there aren't so much different people implementing PLAIN wrong.
(In reply to comment #17) > >But what could we do here? It would be possible to test if the response to > >our "AUTH PLAIN" command is VXNlcm5hbWU6 (or VXNlcm5hbWU= which is also > >possible) and switch to LOGIN method then > > what does "VXNlcm5hbWU6" mean? It's just "Username:" base64 encoded. I was wrong in the alternative, it's "VXNlciBOYW1lAA==" ("User Name<NULL>" according to draft-murchison-sasl-login-00.txt). > Do we literally check for that string? No, we currently don't check the server reply behind the first char (+ or -), neither for the LOGIN nor for the PLAIN case. The idea is that we could test for at least "VXNlc" and if we receive this in response to "AUTH PLAIN", it's very likely the server switched to LOGIN instead of PLAIN mode and we could follow then. > If that fixes our handling of 4 broken servers, then I think it's worthwhile. As I wrote in the above comment it seems it's just one server doing this wrong. But it's a widely used one. > While ultimately we should have UI for enabling/disabling various > authentication mechanisms, if we we have a way of handling it without > bothering the user, that's preferrable. If we do implement the UI, we could > disable this fallback hack for users that have explicitly picked an > authentication mechanism. I also thought about this earlier. I just opened bug 259679 for this. Although I don't think it would help users in a situation like this. How should the user know which mechanism to disable so it will work again?
Attached patch proposed patch — — Splinter Review
This patch redirects our PLAIN mode to LOGIN mode if we detect the typical LOGIN chars "VXNlc".
Assignee: mscott → ch.ey
Status: NEW → ASSIGNED
Attachment #159086 - Flags: review?(bienvenu)
Christian, What are the chances that this applies to the SMTP server as well? We don't use Simplecom's SMTP server, so I don't know if it would have given a problem or not. The reason I ask is because numerous people on the Support forum are reporting problems sending mail while all account information is correct - the latest one reports that his server is IMail... http://forums.mozillazine.org/viewtopic.php?t=130379 RW
SMTP is very likely to be affected too. If IMail does offer PLAIN on SMTP in general they'll use the same authentication mechanism I guess. But before I write a patch I'd like to see such a behaviour in the wild. None of the three providers that have been named here offer PLAIN in their SMTP server so I couldn't provocate the problem there.
*** Bug 259892 has been marked as a duplicate of this bug. ***
Comment on attachment 159086 [details] [diff] [review] proposed patch some folks would want if (! m_commandResponse...) but I'm happy with == 0 here.
Attachment #159086 - Flags: review?(bienvenu) → review+
Comment on attachment 159086 [details] [diff] [review] proposed patch Ok, thanks. Let's see what Scott wants.
Attachment #159086 - Flags: superreview?(mscott)
Comment on attachment 159086 [details] [diff] [review] proposed patch I'm happy too.
Attachment #159086 - Flags: superreview?(mscott) → superreview+
fixed on trunk and 1.0 branch.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Outstanding! Christian, Several different people in the forums have reported that SMTP is NOT affected, and I have verified that they are correct. If you would like to see the SMTP log, email me privately and I'll forward it to you. RW
+ // disable and enable LOGIN (in case it's not already enabled) + ClearCapFlag(POP3_HAS_AUTH_PLAIN); + SetCapFlag(POP3_HAS_AUTH_LOGIN); should the comment say "disable PLAIN and enable LOGIN"?
(In reply to comment #30) > + // disable and enable LOGIN (in case it's not already enabled) > + ClearCapFlag(POP3_HAS_AUTH_PLAIN); > + SetCapFlag(POP3_HAS_AUTH_LOGIN); > > should the comment say "disable PLAIN and enable LOGIN"? Grmpf - yes, it should.
Just out of curiosity... What if a server responds to "AUTH PLAIN" with something like "+ VXNlciBtYXkgc2VuZCBQTEFJTiBjcmVkZW50aWFscw==", i.e., "User may send PLAIN credentials"? Not likely, I know, but still...
(In reply to comment #32) > Just out of curiosity... What if a server responds to "AUTH PLAIN" with > something like "+ VXNlciBtYXkgc2VuZCBQTEFJTiBjcmVkZW50aWFscw==", i.e., "User may > send PLAIN credentials"? Not likely, I know, but still... Firstly I only check for "VXNlc", so it would work well also. And second it's really very unlikely. Not only that a server sends such a strange string but that the same server is one that has this PLAIN->LOGIN error.
*** Bug 261260 has been marked as a duplicate of this bug. ***
*** Bug 261721 has been marked as a duplicate of this bug. ***
*** Bug 258516 has been marked as a duplicate of this bug. ***
*** Bug 261791 has been marked as a duplicate of this bug. ***
*** Bug 237476 has been marked as a duplicate of this bug. ***
*** Bug 262591 has been marked as a duplicate of this bug. ***
*** Bug 261963 has been marked as a duplicate of this bug. ***
*** Bug 259880 has been marked as a duplicate of this bug. ***
*** Bug 259661 has been marked as a duplicate of this bug. ***
*** Bug 264017 has been marked as a duplicate of this bug. ***
Has this bug been actually been verified by someone? I just downloaded Firefox 0.9 (I am not one of those dare devils who try the nightlies) and if I remove the workaround from my prefs.js, i.e. removing the following line: user_pref("mail.server.server3.auth_login", false); Then I still get a similar fault as before, i.e. a dialog box stating: "Sending of password did not succeed. Mail server smtp.kommunicera.umea.se responded:" and then a second one stating: "Sending of usename did not succeed. Mail server smtp.kommunicera.umea.se responded: USER" So I still need the workaround to get it to work with the IMail server. So the fault seem to still be in 0.9 as well.
(In reply to comment #45) > So I still need the workaround to get it to work with the IMail server. So the > fault seem to still be in 0.9 as well. Are you using some AntiVirus software? If so you might experience bug 259840.
(In reply to comment #46) > (In reply to comment #45) > > > So I still need the workaround to get it to work with the IMail server. So the > > fault seem to still be in 0.9 as well. > > Are you using some AntiVirus software? If so you might experience bug 259840. Ah, yes I am. Norton Antivirus 2003. I tried to disable checking of incoming e-mail in Norton Antivirus and now it did work when I removed the workaround. So it seems like I am actually affected by bug 259840 instead. Thanks for the quick response.
FYI, I just received a message from IPswitch: "This message is to inform you that an issue you reported has been addressed in IMail Server 8.14. Issue TT 1560: PLAIN is treated like LOGIN in SASL" This doesn't fix all servers using IMail (there even are providers out there using some 6.x version) but maybe a little success-story.
*** Bug 259602 has been marked as a duplicate of this bug. ***
I have been working with the folks in the Thunderbird support forum on what appears to be an Authentication issue with an iMail server (8.15). Rather than reproduce the threads here, I refer you to http://forums.mozillazine.org/viewtopic.php?p=1581409#1581409 After some suggestions and failed attempts at logging, I am now being ignored by the support moderator. Doesn't say much for the stayinmg power of Thunderbird support. Anyway, is there a chance that there could be a regression of this bug or the original partch has now exposed a Authentication problem in iMail in 1.02. BTW returning to 1.0 fails as well. No mail at this site (except OE with 6) since 6-11-05.
Another comment: I used the user_prefs line and was able to get the mail. That's great, but I had tried before having found the recommendation elsewhere. There was no info on replacing the ? with the server #. After I read the entire bug tonight, it made sense with that small but important detail included. Now the question is, did iMail make a change re-exposing the original problem? I have a question to the provider about build updates they may have done on the date that our mail stopped. No response yet.
This bug STILL exists in Thunderbird 1.5.0.8.
> This bug STILL exists in Thunderbird 1.5.0.8. If you've read the thread you'll see there never was such a bug in TB. If you experience problems in authentication to a server it's likely to be some other issue. In order to see which we need more input. What server (address), which error, since when do you see this? Attaching a communications log (see http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#smtp for instructions) would be the best.
The server in question is an outdated copy of IMail (6.06) on Windows at mail1.fusix.com; a communications log, redacted where appropriate, is attached. Many versions of IMail, apparently through at least version 8, go through the motions of AUTH LOGIN when the client requests AUTH PLAIN, and TB is being confused by it (since it's taking the + at the start of the Base64 "Password:" string to mean "authentication successful, now in TRANSACTION state", at which point it gets confused. There really should be checkboxes somewhere in TB (server settings dialog, perhaps?) to permit/disallow certain authentication types to work around broken servers; Eudora has been working around IMail's POP3 brokenness since at least version 4.12 (and it's up to 7.1 now, and may she rest in peace).
Comment on attachment 245948 [details] Redacted communications log from Thunderbird 1.5.0.8 trying to POP from IMail 6.06 >0[2747b0]: Entering NET_ProcessPop3 61 >0[2747b0]: POP3: Entering state: 1 >0[2747b0]: POP3: Entering state: 2 >0[2747b0]: POP3: Entering state: 4 >0[2747b0]: RECV: +OK X1 NT-POP3 Server mail1.fusix.com (IMail 6.06 808829-2) >0[2747b0]: POP3: Entering state: 29 >0[2747b0]: SEND: AUTH >0[2747b0]: Entering NET_ProcessPop3 37 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: -ERR authentication exchange failed >0[2747b0]: POP3: Entering state: 30 >0[2747b0]: POP3: Entering state: 31 >0[2747b0]: SEND: CAPA >0[2747b0]: Entering NET_ProcessPop3 87 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: +OK Capability list follows >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: TOP >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: USER >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: SASL LOGIN PLAIN >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: RESP-CODES >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: LOGIN-DELAY 120 >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: Entering NET_ProcessPop3 72 >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: PIPELINING >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: EXPIRE 30 USER >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: UIDL >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: IMPLEMENTATION Ipswitch_IMail_5.0 >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: . >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: AUTH PLAIN >0[2747b0]: Entering NET_ProcessPop3 16 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: + VXNlcm5hbWU6 >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 6 >0[2747b0]: POP3: Entering state: 36 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: dXNlcm5hbWVyZW1vdmVk >0[2747b0]: Entering NET_ProcessPop3 2 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: USER usernameremoved >0[2747b0]: Entering NET_ProcessPop3 16 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: + UGFzc3dvcmQ6 >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 6 >0[2747b0]: Logging suppressed for this command (it probably contained authentication information) >0[2747b0]: Entering NET_ProcessPop3 2 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 24 >0[2747b0]: POP3: Entering state: 0 >0[2747b0]: POP3: Entering state: 31 >0[2747b0]: SEND: CAPA >0[2747b0]: Entering NET_ProcessPop3 30 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: -ERR Invalid userid/password >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: AUTH PLAIN >0[2747b0]: Entering NET_ProcessPop3 33 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: -ERR Not in authorization state >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 35 >0[2747b0]: SEND: AUTH LOGIN >0[2747b0]: Entering NET_ProcessPop3 29 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: +OK Capability list follows >0[2747b0]: POP3: Entering state: 36 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: dXNlcm5hbWVyZW1vdmVk >0[2747b0]: Entering NET_ProcessPop3 5 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: TOP >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: USER usernameremoved >0[2747b0]: Entering NET_ProcessPop3 6 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: USER >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 24 >0[2747b0]: POP3: Entering state: 25 >0[2747b0]: Entering NET_ProcessPop3 61 >0[2747b0]: POP3: Entering state: 1 >0[2747b0]: POP3: Entering state: 2 >0[2747b0]: POP3: Entering state: 4 >0[2747b0]: RECV: +OK X1 NT-POP3 Server mail1.fusix.com (IMail 6.06 809047-1) >0[2747b0]: POP3: Entering state: 31 >0[2747b0]: SEND: CAPA >0[2747b0]: Entering NET_ProcessPop3 159 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: +OK Capability list follows >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: TOP >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: USER >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: SASL LOGIN PLAIN >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: RESP-CODES >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: LOGIN-DELAY 120 >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: PIPELINING >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: EXPIRE 30 USER >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: UIDL >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: IMPLEMENTATION Ipswitch_IMail_5.0 >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: . >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: AUTH PLAIN >0[2747b0]: Entering NET_ProcessPop3 16 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: + VXNlcm5hbWU6 >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 6 >0[2747b0]: POP3: Entering state: 36 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: dXNlcm5hbWVyZW1vdmVk >0[2747b0]: Entering NET_ProcessPop3 2 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: USER usernameremoved >0[2747b0]: Entering NET_ProcessPop3 16 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: + UGFzc3dvcmQ6 >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 6 >0[2747b0]: Logging suppressed for this command (it probably contained authentication information) >0[2747b0]: Entering NET_ProcessPop3 2 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 24 >0[2747b0]: POP3: Entering state: 0 >0[2747b0]: POP3: Entering state: 31 >0[2747b0]: SEND: CAPA >0[2747b0]: Entering NET_ProcessPop3 30 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: -ERR Invalid userid/password >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: AUTH PLAIN >0[2747b0]: Entering NET_ProcessPop3 33 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: -ERR Not in authorization state >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 35 >0[2747b0]: SEND: AUTH LOGIN >0[2747b0]: Entering NET_ProcessPop3 29 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: +OK Capability list follows >0[2747b0]: POP3: Entering state: 36 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: dXNlcm5hbWVyZW1vdmVk >0[2747b0]: Entering NET_ProcessPop3 5 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: TOP >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: USER usernameremoved >0[2747b0]: Entering NET_ProcessPop3 6 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: USER >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 24 >0[2747b0]: POP3: Entering state: 25 >0[2747b0]: Entering NET_ProcessPop3 61 >0[2747b0]: POP3: Entering state: 1 >0[2747b0]: POP3: Entering state: 2 >0[2747b0]: POP3: Entering state: 4 >0[2747b0]: RECV: +OK X1 NT-POP3 Server mail1.fusix.com (IMail 6.06 809181-2) >0[2747b0]: POP3: Entering state: 31 >0[2747b0]: SEND: CAPA >0[2747b0]: Entering NET_ProcessPop3 159 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: +OK Capability list follows >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: TOP >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: USER >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: SASL LOGIN PLAIN >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: RESP-CODES >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: LOGIN-DELAY 120 >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: PIPELINING >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: EXPIRE 30 USER >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: UIDL >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: IMPLEMENTATION Ipswitch_IMail_5.0 >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: RECV: . >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: AUTH PLAIN >0[2747b0]: Entering NET_ProcessPop3 16 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: + VXNlcm5hbWU6 >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 6 >0[2747b0]: POP3: Entering state: 36 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: dXNlcm5hbWVyZW1vdmVk >0[2747b0]: Entering NET_ProcessPop3 2 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: USER usernameremoved >0[2747b0]: Entering NET_ProcessPop3 16 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: + UGFzc3dvcmQ6 >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 6 >0[2747b0]: Logging suppressed for this command (it probably contained authentication information) >0[2747b0]: Entering NET_ProcessPop3 2 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 24 >0[2747b0]: POP3: Entering state: 0 >0[2747b0]: POP3: Entering state: 31 >0[2747b0]: SEND: CAPA >0[2747b0]: Entering NET_ProcessPop3 30 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: -ERR Invalid userid/password >0[2747b0]: POP3: Entering state: 32 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: AUTH PLAIN >0[2747b0]: Entering NET_ProcessPop3 33 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: -ERR Not in authorization state >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 35 >0[2747b0]: SEND: AUTH LOGIN >0[2747b0]: Entering NET_ProcessPop3 29 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: +OK Capability list follows >0[2747b0]: POP3: Entering state: 36 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: dXNlcm5hbWVyZW1vdmVk >0[2747b0]: Entering NET_ProcessPop3 5 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: TOP >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 33 >0[2747b0]: POP3: Entering state: 5 >0[2747b0]: SEND: USER usernameremoved >0[2747b0]: Entering NET_ProcessPop3 6 >0[2747b0]: POP3: Entering state: 3 >0[2747b0]: RECV: USER >0[2747b0]: POP3: Entering state: 34 >0[2747b0]: POP3: Entering state: 24 >0[2747b0]: POP3: Entering state: 25
Attachment #245948 - Attachment is obsolete: true
Thanks for the logs. If I read that logs right, that server is even more broken than the version the original poster had contact with. It sends two linebreaks after + VXNlcm5hbWU6 and + UGFzc3dvcmQ6. Since we read line for line, for the client it looks as the server responds with an empty line to our username. An empty line is not a "+" and so we treat it as error message. From this point on server and client are out of sync. In bug 234421 some code was added to remove any left over bytes from previous responses in case the server sent two lines. Don't know why that doesn't help in this case. I'll test that tomorrow.
I tested that myself now, with SM and TB nightly and TB 1.5.0.8, it works in all versions with your server. A guess from me is, that you're using an antivirus/personal firewall software on your system. Just remembered I've already an explanation on my site, please have a look at http://www.eyrich-net.org/mozilla/mozvsav.html?en#six.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: