258077 - TB will not authenticate with POP3 server -since 20040824

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Robby Workman]

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

Comment 1

[Robby Workman]

Attachment: Log file of POP3 server transactions

Comment 2

[Scott MacGregor]

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

Comment 3

[Robby Workman]

(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

Comment 4

[Christian Eyrich]

> 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.

Comment 5

[Robby Workman]

Received this from Corey ([e-mail]) 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

Comment 6

[Christian Eyrich]

> + 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?

Comment 7

[Robby Workman]

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

Comment 8

[Christian Eyrich]

>> 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.

Comment 9

[Peter Cigehn]

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).

Comment 10

[Nathan Hamblen]

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.

Comment 11

[homer]

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.

Comment 12

[Christian Eyrich]

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?

Comment 13

[Christian Eyrich]

(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.

Comment 14

[Nathan Hamblen]

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!)

Comment 15

[Peter Cigehn]

(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.

Comment 16

[Robby Workman]

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

Comment 17

[David :Bienvenu]

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.

Comment 18

[David :Bienvenu]

*** Bug 257299 has been marked as a duplicate of this bug. ***

Comment 19

[Christian Eyrich]

(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.

Comment 20

[Christian Eyrich]

(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?

Comment 21

[Christian Eyrich]

Attachment: proposed patch

This patch redirects our PLAIN mode to LOGIN mode if we detect the typical
LOGIN chars "VXNlc".

Comment 22

[Robby Workman]

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

Comment 23

[Christian Eyrich]

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.

Comment 24

[will mooney]

*** Bug 259892 has been marked as a duplicate of this bug. ***

Comment 25

[David :Bienvenu]

Comment on attachment 159086 [details] [diff] [review]
proposed patch

some folks would want if (! m_commandResponse...) but I'm happy with == 0 here.

Comment 26

[Christian Eyrich]

Comment on attachment 159086 [details] [diff] [review]
proposed patch

Ok, thanks. Let's see what Scott wants.

Comment 27

[Scott MacGregor]

Comment on attachment 159086 [details] [diff] [review]
proposed patch

I'm happy too.

Comment 28

[David :Bienvenu]

fixed on trunk and 1.0 branch.

Comment 29

[Robby Workman]

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

Comment 30

[Christian :Biesinger (don't email me, ping me on IRC)]

+                // 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"?

Comment 31

[Christian Eyrich]

(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.

Comment 32

[Vaclav Dvorak]

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...

Comment 33

[Christian :Biesinger (don't email me, ping me on IRC)]

comment fix per comment 30 / comment 31 checked in

Comment 34

[Christian Eyrich]

(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.

Comment 35

[David :Bienvenu]

*** Bug 261260 has been marked as a duplicate of this bug. ***

Comment 36

[David :Bienvenu]

*** Bug 261721 has been marked as a duplicate of this bug. ***

Comment 37

[David :Bienvenu]

*** Bug 258516 has been marked as a duplicate of this bug. ***

Comment 38

[David :Bienvenu]

*** Bug 261791 has been marked as a duplicate of this bug. ***

Comment 39

[David :Bienvenu]

*** Bug 237476 has been marked as a duplicate of this bug. ***

Comment 40

[David :Bienvenu]

*** Bug 262591 has been marked as a duplicate of this bug. ***

Comment 41

[Christian Eyrich]

*** Bug 261963 has been marked as a duplicate of this bug. ***

Comment 42

[Christian Eyrich]

*** Bug 259880 has been marked as a duplicate of this bug. ***

Comment 43

[David :Bienvenu]

*** Bug 259661 has been marked as a duplicate of this bug. ***

Comment 44

[David :Bienvenu]

*** Bug 264017 has been marked as a duplicate of this bug. ***

Comment 45

[Peter Cigehn]

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.

Comment 46

[Christian Eyrich]

(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.

Comment 47

[Peter Cigehn]

(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.

Comment 48

[Christian Eyrich]

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.

Comment 49

[Doug Wright]

*** Bug 259602 has been marked as a duplicate of this bug. ***

Comment 50

[Bob Salsburg]

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.

Comment 51

[Bob Salsburg]

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.

Comment 52

[Alex Burke]

This bug STILL exists in Thunderbird 1.5.0.8.

Comment 53

[Christian Eyrich]

> 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.

Comment 54

[Alex Burke]

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 55

[Alex Burke]

Attachment: Redacted communications log from Thunderbird 1.5.0.8 trying to POP from IMail 6.06

Comment 56

[Alex Burke]

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

Comment 57

[Christian Eyrich]

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.

Comment 58

[Christian Eyrich]

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.