there was a similar report not too long ago, the problem was that the
server was sending us a line:

 DELE, LIST, LAST, NOOP, RETR, RSET, STAT, TOP, UIDL or QUIT

when it MEANT to send us:

-ERR Supported commands are: DELE, LIST, LAST, NOOP, RETR, RSET, STAT,
TOP, UIDL or QUIT

or some such.

but because the server response does not start with a +OK or a -ERR,
we fail.

this is a server bug. Have your server software company fix it :-)

I am not a POP3 expert, so I cannot refute the allegation that the
server may be returning an incorrect response; however, before we just
mark this as resolved, I would like to understand why this same POP3
server WORKS with any other email client including...you guessed
it...Evolution 1.2.x; if Evo 1.2.x, balsa, etc. have the "flexibility"
to handle this response (even if it is not correct), I would hope an
improved Evo version could as well?

I appreciate any chance of a second glance at the issue.

Thanks,
Philip

evolutioon 1.2 sends a CAPA command when it first connects to the POP
server to try to get which server extensions the POP server supports
(especially things like security extensions such as SASL and STLS)

if that fails, the code guesses that the POP server doesn't support
things like UIDL which make things like "keep mail on server" possible.

the problem with this is that a lot of POP servers don't allow CAPA
before the user has logged in, and so if that is the case those users
will have to suffer with a really slow implementation of "keep mail on
server" and we have gotten a lot of complaints about that.

So for 1.3, I made evolution issue another CAPA command *after*
logging in if the first one failed so that we can work around the
problem of the aformentioned user group.

your problem comes in because your server doesn't implement CAPA
before *nor* after logging in, and when we issue a CAPA command
*after* we have logged in, your server returns a broken response and
we have to abort.

do you see the pain we have to deal with? it's becomming far too much.
No matter what we do, we run into broken servers that we have to try
to work around. and when we work around those broken servers, it
breaks it for someone else. It is an endless cycle that must end
before I go insane.

people need to complaining to their ISPs to get them to start fixing
the servers. it's as simple as that.


Note: POP servers don't *have* to implement CAPA, but if they don't
they MUST respond with a -ERR (with an optional comment following on
that same line). Also, POP servers MAY legally reject CAPA before
login if they implement CAPA at all, and then later, after login,
allow CAPA.


As far as "well, balsa and other mailers work with this broken
response" goes, the truth of the matter is that those other clients
don't support any POP extensions and so never issue a CAPA command,
thus they never receive the broken response :-)

Thank you very much for taking the time to explain the situation...I
will help in the crusade to move toward CAPA compliance, or at least
to acknowledge non-compliance from POP servers!

I feel like a pain in the ass, but to make the product as robust as
possible, I think I need to report the following response from my ISP:


Dear DellHost Customer,

We do not currently support this command and we do produce an -ERR message
that we do not have it:

+OK InterMail POP3 server ready.
CAPA
-ERR Invalid command; valid commands: USER, QUIT
quit

Thank you for contacting DellHost support.


Kanika
DellHost Dedicated Server Support Team
serversupport@dellhost.com
www.dellhost.com
888.832.7166

they do the first time, but the second time (after logging in), they
do not.

OK...our ISP is saying they are compliant with RFC 1939 (see
below)...is this correct?  Thanks for your help.

Dear DellHost Customer,

Here is what I got from the Email SAs:

InterMail is fully compliant with RFC 1939 (Post Offic Protocol - Version
3) with the exception of APOP.

This means that they will not be changing the -ERR ro CAPA on the server
any time soon.  I apologize for this, but this is something that will not
be changed any time soon.

Thank you for contacting DellHost support.

Matt
DellHost Dedicated Server Support Team
serversupport@dellhost.com
www.dellhost.com
888.832.7166

could you please do the following from your end:

run evolution-1.3 from a terminal like this:

CAMEL_VERBOSE_DEBUG=1 evolution-1.3
or
setenv CAMEL_VERBOSE_DEBUG 1
evolution-1.3

Then try to connect to your pop account.  It will dump the pop
conversation to the screen, and we can see exactly what is happening.

Here is the output...it appears that *after* login, the server does
not respond with "-ERR" at the beginning of a response (it does
*before* login).  DellHost is saying that this is RFC 1939 compliant?

---OUTPUT BELOW----

[philip@ingrid philip]$ CAMEL_VERBOSE_DEBUG=1 evolution-1.3
current config version is '1.3.0'

(evolution-1.3:2372): evolution-shell-CRITICAL **: file
evolution-storage.c: line 1064 (evolution_storage_new_folder):
assertion `physical_uri != NULL' failed
POP3_STREAM_LINE(32): '+OK InterMail POP3 server ready.'
POP3_STREAM_WRITE(6):
CAPA

POP3_STREAM_LINE(48): '-ERR Invalid command; valid commands: USER, QUIT'
POP3_STREAM_WRITE(21):
USER D30008631-phil

POP3_STREAM_LINE(28): '+OK please send PASS command'
Got + response
POP3_STREAM_WRITE(15):
PASS xxxxxxxx
POP3_STREAM_LINE(34): '+OK D30008631-phil is welcome here'
Got + response
POP3_STREAM_WRITE(6):
CAPA

POP3_STREAM_LINE(60): ' DELE, LIST, LAST, NOOP, RETR, RSET, STAT, TOP,
UIDL or QUIT'

(evolution-1.3:2378): camel-pop3-provider-WARNING **: Bad server
response:  DELE, LIST, LAST, NOOP, RETR, RSET, STAT, TOP, UIDL or QUIT

this is what I've been saying the entire time ;-)

your ISP is wrong, it is not RFC compliant. It MUST send +OK or -ERR
for EVERY reply. However, your ISP's POP server is NOT sending -ERR
the second time, in fact - it seems to be getting confused and not
even sending the entire reply string in the first place :-)

This bug is indeed "NOTXIMIAN" and Intermail is to blame, but since
every other MUA has a workaround, maybe there should be one in the new
Evolution as well. For many non-technical users things like these are
not clear and since the other mail programs work, they probably think
it's an Evolution bug.

I did report the bug to my ISP, but for now I just have to use another
MUA to read my other mailbox which is a pain.

*** bug 242532 has been marked as a duplicate of this bug. ***

While I agree in principle that the bug is NOTXIMIAN and understand
the issue, as a software developer myself I wrestle with whether or
not to address the shortcomings of third party interfaces and systems.
 To maximize robustness, there is no doubt that the new Evolution
should work around "broken" systems, like InterMail; however, only the
Ximian staff can answer the question: "At what cost, and to what end".

I would *love* to see Evo work around this issue, but trust that if
Ximian decides not to, they have done so after careful consideration
and for sensible reason.

*** bug 242873 has been marked as a duplicate of this bug. ***

OK folks, I have seen enough commentary on this issue to request that
it be raised to a higher level of consideration at Ximian.  The fact
that we can use numerous other email POP clients (including previous
Evolution clients) probably says that strict compliance, while a good
idea in principle, is hurting the implementation of 1.3/1.4. We
understand the issues, but at the end of the day, aren't we working
toward better solutions that meet more people's needs?  If not, maybe
the whole Microsoft anarchy thing made sense after all?  Of course, it
did not.  Ximian and Evolution are the future.  I am confident that we
can come up with a valid solution...e.g. an option for
"CAPA"..."yes/no"...use at your own security risk...something to keep
us all moving forward!  Thanks!

I'm not convinced. please do not reopen. if/when ximian decides to
work around this, it will be reopened by a ximian employee. thanks.

I apologize if re-opening was inappropriate, and will heed the request
not to do so in the future.
I continue to feel very strongly that Ximian is making a mistake by
not addressing this issue.  I absolutely understand the dilemma, but
feel that an "upgrade" should never "downgrade" capabilities...it
should enhance features, and at a minimum allow the user to determine
if the upgraded product should compromise its integrity to be backward
compatible (or compatible with non-compliant mail servers in this case).
I am *hopeful* that Ximian will agree, and would love to be able to
continue to use Evolution for all of our email servers!
Thanks, Philip

*** bug 244205 has been marked as a duplicate of this bug. ***

ok, it's been decided that we will attempt to work around this
broken-server issue. the current thought is to add a account config
option to disable POP3 extension support in the POP3 client code.

this means you won't get STLS, SASL, nor PIPELINE (and others?)
support, but I guess at least it'll download mail.

Created attachment 42505 [details] [review]
40788.patch

*** bug 244393 has been marked as a duplicate of this bug. ***

i wonder jeff, should we just treat lines that return with no + or -
as if they started with -ERR?

rather than aborting the entire connection.

although, it really is a very serious failing of the server
implementation if it can't get the very simple pop protocol right.

we could I suppose... assuming that the POP server isn't fucked up at
this point.
can someone try telnetting to their POP server and run the following
sequence of commands?

(S: lines are server responses, C: lines are what you type)

Note: anything after the +OK or -ERR is irrelevant

S: +OK
C: CAPA
S: -ERR
C: USER <type your username here>
S: +OK
C: PASS <type your passwd here>
S: +OK
C: CAPA
S: <garbage>
C: LIST
S: <list of messages - multiline>
C: RETR 1
S: <body of message #1>


my goal here is just to make sure that LIST and RETR are working after
that bad CAPA response. If they work, then I guess we can try just
ignoring the bad CAPA response.

however, we still will want to have the config checkbox to skip CAPA,
since some POP servers have been reported to drop the connection after
getting a CAPA query. Joy. I love the people who implement these
broken POP servers.

It turns out that my evolution bug is the same as this one except that
evolution more often than not either hangs or crashes. My internet
host (Sympatico.ca) also uses InterMail and it gives the same " DELE,
LIST, LAST, NOOP, RETR, RSET, STAT, TOP, UIDL or QUIT" response during
the CAPA query. I ran evolution through GBD and came up with two
different stack traces. I'm using Evolution 1.4 on RedHat 9.0 with
Ximian Desktop 2.0

Apparently, there are two ways this query can cause a crash (i.e.
evolution dies with the bug dialog "Application "evolution-1.4"
(process 7145) has crashed due to a fatal error. (Segmentation fault)") 

or hang (i.e. evolution must be forcefully killed with "kill -9").

I'll append the text dumps of both types of problems as separate
comments for readability's sake.

Here's the first stack dump
====================================================
[rnd@localhost rnd]$ gdb evolution
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging
symbols found)...
(gdb) run
Starting program: /usr/bin/evolution
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...[New Thread
1092630016 (LWP 3799)]
[New Thread 1116949808 (LWP 3801)]
[New Thread 1125342512 (LWP 3802)]
[New Thread 1133735216 (LWP 3803)]
[New Thread 1142127920 (LWP 3804)]
 
(evolution:3799): Bonobo-WARNING **: Could not find GNOME pixmap file
/usr/share/pixmaps/help-chat-16.png
 
(evolution:3799): Bonobo-WARNING **: Could not find GNOME pixmap file
/usr/share/pixmaps/help-chat-16.png
 
(evolution:3799): Bonobo-WARNING **: Could not find GNOME pixmap file
/usr/share/pixmaps/help-chat-16.png
[New Thread 1150520624 (LWP 3805)]
[Thread 1150520624 (LWP 3805) exited]
 
(evolution:3799): camel-pop3-provider-WARNING **: Bad server response:
 DELE, LIST, NOOP, RETR, RSET, STAT, TOP, UIDL or QUIT 
 
Program received signal SIGSEGV, Segmentation fault.

+ Trace 37712

Here's the second stack dump. I used the CAMEL_VERBOSE_DEBUG=1
directive so you can get more information on the history of the crash.
============================================
[rnd@localhost rnd]$ CAMEL_VERBOSE_DEBUG=1 gdb evolution-1.4
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging
symbols found)...
(gdb) run
Starting program: /usr/bin/evolution-1.4
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...[New Thread
1092630016 (LWP 7081)]
[New Thread 1116949808 (LWP 7083)]
[New Thread 1125342512 (LWP 7084)]
[New Thread 1133735216 (LWP 7085)]
[New Thread 1142127920 (LWP 7086)]
 
(evolution-1.4:7081): Bonobo-WARNING **: Could not find GNOME pixmap
file /usr/share/pixmaps/help-chat-16.png
 
(evolution-1.4:7081): Bonobo-WARNING **: Could not find GNOME pixmap
file /usr/share/pixmaps/help-chat-16.png
 
(evolution-1.4:7081): Bonobo-WARNING **: Could not find GNOME pixmap
file /usr/share/pixmaps/help-chat-16.png
[New Thread 1150520624 (LWP 7087)]
[Thread 1150520624 (LWP 7087) exited]
POP3_STREAM_LINE(32): '+OK InterMail POP3 server ready.'
POP3_STREAM_WRITE(6):
CAPA
 
POP3_STREAM_LINE(48): '-ERR Invalid command; valid commands: USER, QUIT'
POP3_STREAM_WRITE(15):
USER b1xxxxxx
 
POP3_STREAM_LINE(28): '+OK please send PASS command'
Got + response
POP3_STREAM_WRITE(15):
PASS xxxxxxxx
POP3_STREAM_LINE(28): '+OK b1mbog81 is welcome here'
Got + response
POP3_STREAM_WRITE(6):
CAPA
 
POP3_STREAM_LINE(54): ' DELE, LIST, NOOP, RETR, RSET, STAT, TOP, UIDL
or QUIT'
 
(evolution-1.4:7081): camel-pop3-provider-WARNING **: Bad server
response:  DELE, LIST, NOOP, RETR, RSET, STAT, TOP, UIDL or QUIT
 
POP3_STREAM_FILL(ERROR): 'Interrupted system call'
POP3_STREAM_FILL(ERROR): 'Interrupted system call'
POP3_STREAM_FILL(ERROR): 'Interrupted system call'
 
Program received signal SIGSEGV, Segmentation fault.

+ Trace 37713

The program is running.  Exit anyway? (y or n) y

Per the request re: "LIST" and "RETR" working after bad server response:

+OK InterMail POP3 server ready.
CAPA
-ERR Invalid command; valid commands: USER, QUIT
USER ********
+OK please send PASS command
PASS ********
+OK D30008631-phil is welcome here
CAPA
 DELE, LIST, LAST, NOOP, RETR, RSET, STAT, TOP, UIDL or QUIT
LIST
+OK 1 messages
1 771
.
RETR 1
+OK 771 octets
Return-Path: <phil@arivanet.com>
Received: from arivanet.com ([205.243.232.2]) by mxsmta03.dellhost.com
          (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with
ESMTP
          id <20030612162504.SZAX28645.mxsmta03.dellhost.com@arivanet.com>
          for <phil@arivanet.com>; Thu, 12 Jun 2003 12:25:04 -0400
Message-ID: <3EE8A900.70907@arivanet.com>
Date: Thu, 12 Jun 2003 11:23:28 -0500
From: Philip Allen <phil@arivanet.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2)
Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  phil@arivanet.com
Subject: Test Message
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This is a test message for Ximian...

.
QUIT
+OK D30008631-phil InterMail POP3 server signing off.

thanks

code has been committed to work around these broken servers now.

Can you tell me where can I download the source for Evolution 1.4 that
have the patch for the broken server? I use Gentoo here and the RPM
dont work!

And, does this fix the sympatico pop server error?

Thanx a lot

You can only get it from gnome CVS right now, but it will be included
in evolution-1.4.1

Greetings,

Hope it's acceptable to add some further comments. Specifically, I
just wanted to add that I too was having similar problems with
Evolution (1.4) and /my/ ISP, Cox.net. While it seems I'm a relative
neophyte compared with most of you guys (esp. re Linux), I tried to
follow along this bug report and check that the problems I was
experiencing (POP mail not working, SMTP working, in Evo 1.4 also Evo
crashing/hanging when attempting to converse with non-compliant POP
server) jived with what Philip Allen (et al) was experiencing. 

Last night, I tried to set-up a mail account in Evo 1.4 provided my
ISP, Cox.net. After several unsucessful attempts to receive mail (I
did notice that sending/SMTP would work) and several crashes, I set up
the same account with the Mozilla mail client. In testing, it seemed
to work fine. I sent an e-mail to a friend of mine (who runs a Postfix
server) who had originally recommened Evolution to me (the Linux noob)
mentioning to him this problem. 

Although he was unclear on the why (he suggested I double check POP
and SMTP settings), I checked his e-mail headers (inspired by reading
through this bug report) and I observed that Cox.net appears to be
using Intermail.

I then set-up another POP account in Evolution, but this time using an
account on the Postfix server my aforementioned friend runs. This
time, zero problems sending, zero crashes. 

If I can muddle my way through the debug stuff you folks have already
done on your respective ends and I can get some useful information
output and if it matches (at this point, I can only assume that it
will based on my crude testing methods) what you folks have shown me,
I will forward that information to the Postmaster at Cox.net in the
(perhaps futile) attempt to get them to alter/change/correct the
settings on their end.

*** bug 246016 has been marked as a duplicate of this bug. ***

*** bug 245593 has been marked as a duplicate of this bug. ***

*** bug 247427 has been marked as a duplicate of this bug. ***

*** bug 252141 has been marked as a duplicate of this bug. ***