wei said:
This AM, went one step further - I ERASED the entire IDENTITIES
FOLDER! Now OE should have no mailboxes, right? Well, guess what?
When OE starts it shows the SAME inbox, and still hangs up. I give
up.
If the .dbx files are missing then OE recreates them when it loads.
That doesn't populate them with any records but just creates the
database files. When you started OE, I bet you were not disconnected
from the Internet, so OE dutifully performed its mail poll as you
configured it to do, downloaded all the e-mails again from the server
(since they all look new/unread to OE since e-mail clients track that
and not the server), and your Inbox got repopulated because it polled
your account to add records to the new .dbx files you had OE create when
it started.
Disconnect from the Internet. Turn off the router, yank the RJ45 from
your computer's port or to where it goes to the router, or right-click
on the connectoid in the Network applet in Control Panel and select
disconnect (disable). Then exit OE and delete the .dbx files. Then
load OE which will recreate the .dbx files. Because you are
disconnected from the Internet, OE cannot poll your e-mail account on
the server. At that point, is OE working okay?
If OE "hangs up" when you connect your host to the Internet so OE can
poll your e-mail account then you could have issues with software
outside of OE or with the mail server to which OE connects. It is
possible an e-mail is corrupted up on the mail server. It simply
doesn't know when the message ends or fails to read the file for it so
it never sends the dot-delimiter line. Your e-mail client is going to
send a RETR[ieve] command after which the server is supposed to send a
DATA command (to mark that it is going to send the message) followed by
the headers and body of the message followed by a dot-delimiter line (a
dot or period character in position 1 of the line followed by a newline
so that the entire line is just the period character). The
dot-delimiter tells the client that the server is done transmitting the
message to the client. To test if this is the cause (of a corrupted
e-mail up on the server), use the webmail client to access your e-mail
client. Then move out ALL message from the Inbox folder. Stick them in
another user-defined folder or read them and delete them. Then load OE
and see if it now works okay when your mailbox is empty up on the
server.
If that doesn't fix your problem, determine what software you installed
on your host that interrogates your e-mail traffic. One usual suspect
is anti-virus (AV) software. Some work as transparent proxies that
inspect the e-mail traffic on-the-fly. As the server sends the bytes
after the DATA command, the AV proxy looks at them a few at a time and
then passes them onto your e-mail client. That way, your e-mail client
doesn't timeout waiting for the message to arrive from the server. Of
course, if the AV proxy is farked then it won't be delivering the e-mail
traffic from the server to your client. I've seen that happen in
Norton's AntiVirus product when its transparent proxy went brain dead
and requires reloading the services and background processes (in the
proper order) to get their proxy working again; however, unless you have
batch files to do the stop and restart of their services and processes,
it's easier to just reboot your host to get their proxy working again.
Some AV programs pretend to be both the client and the server. When
your e-mail client sends an e-mail, their AV proxy grabs the whole
message by pretending it is the mail server. Your client is really
sending e-mails to the AV inspector instead of to the real mail server.
After the AV inspector gets done interrogating the entire message then
it pretends it is the client and connects to the mail server to send it
your message. Likewise, on receiving e-mails, the AV inspector pretends
it is the client and retrieves the entire e-mail (your e-mail client
doesn't have anything of it yet). The AV inspector interrogates the
content of the e-mail looking for malware. When it is happy then it
pretends to be the server and passes the e-mail down to your real e-mail
client. The delay of when the real e-mail client sent a RETR command,
the AV inspector sending it to the real e-mail server, the server
sending the DATA command, message, and dot-delimiter to the AV
inspector, the AV inspector to inspect the e-mail, and finally for the
AV inspector to actually deliver it to your e-mail client can take so
long that your e-mail client timesout (but before the timout it hangs
there waiting). "Hangs forever" doesn't say how long you waited. I
don't remember what is the timeout setting in OE (the one that is there
is for the handshaking to establish a connection and mail session, not
how long to wait during a DATA transfer). I suspect it is 5 minutes
(the same time IE waits before timing out for a non-responsive site).
So how long did you wait while OE was hung before determining it was
likely hung forever?
Interrogation of e-mails looking for malware is superfluous as it adds
no additional protection against any attached malware in the e-mails.
The same engine that is scanning your e-mails is the same one used to
scan the files that you create when you extract attachments to save them
as files (whether you save them separately as files you use later or
save them temporarily by using an "open" function in the e-mail client).
Often to resolve e-mail client problems means disabling e-mail scanning
by the AV program and retest.
If you deleted the .dbx files and started OE when you had *no* Internet
access and OE hung then we know there is a problem within OE. If OE
works okay when loaded and recreating new .dbx files when you do *not*
have Internet access then the problem is outside of OE, like corrupted
e-mails up on the server or security software interferring with OE.
