While porting the line buffering code, I ran across the hack represented by NET_POP3TooEarlyForEnd(). This was code put in during Nova. The hack involves several global variables and calling this routine from the line buffering code, whether or not the line buffering has anything to do with POP parsing. There's no way we're keeping this hack around in the line buffering code, so whoever's maintaining the POP3 code needs to figure out a better way of doing this. For starters, we should be using some variable in the pop protocol object instead of global variables. I think part of the reason someone put this code where he did might have to do with losing information when the line buffering code converts CRLF to just LF, but maybe not.

Scott, you're maintaining the POP3 code, right? :-) M7

Once this is fixed, is there something that Suresh do to verify your fix?

I don't know enough about this bug (i.e. why we call pop3tooearlyto find) to know that I'm going to fix this for M7. We haven't had any problems with pop yet without it so I'm pushing this off.

correcting platform to All

Moving all Mail/News Networking bugs to Mail/News Networking-Mail This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will fix those bugs.

I don't see where this is hurting us yet and I still haven't sat down to figure out what I need to do. Post necko work in any case so after m9.

If this bug doesn't hurt us, I don't think this needs to be fixed for PR1

This is now handled in nsPop3Protocol::HandleLine(). We accumulate the parsed bytes in that routine. This is fixed along with fixing Bug 20312.

Verified...