R. H. Breener said:
I have the email filter set to delete them at the
server. They don't download to my PC. Everything over 800 KBs gets killed
at the server. I don't care what they sent, if it's over 800 KB, it dies on
the gmail server.
My server-side rule moves it into the Trash or Junk folder. The e-mail
provider cleans those folders out after around 7 days. So if the sender
wonders why I didn't look at his big attachment or reply about it then I
still have a short time to use the webmail client to go look at it.
Although I have an always-on broadband Internet connection, I'm still
not interesting in some boob sending me a huge e-mail with tons of
attachments rather than providing links to them. A bigger message store
(database) means a slower e-mail client. I can get add-ons that
automatically slice out attachments and save them into files (with a
file link left behind in the e-mail) but I'm really not interested in me
having to implement workarounds for rude senders.
Right... and MS shouldn't deny us that right. It costs MS nothing for
people to use the old email program so why disable it? A monopoly suite?
Dropped support. Why would any software vendor be including old
software they no longer support with newer software they do support?
That isn't just behavior by Microsoft. That's behavior by every company
producing software and even single programmers distributing their own
code.
They're not going to bundle something into their new product that they
don't support anymore and has known bugs that they will never address
since the product isn't supported anymore (e.g., OE corrupting its .dbx
database files when they exceed 2GB in size, corruption of indexing on
compaction or when .dbx files have an excessive count of records, etc).
Also, many programs rely on libraries as part of the OS or included in
frameworks to provide many of the functions executed within a program.
Well, when the libraries get updated, replaced, or deleted with newer
versions of the OS then those old programs won't work anymore.
Sometimes you can get the old libraries or ancilliary support files for
the old program (since they aren't included in the program then you have
to get them separately) but don't expect the vendor of the newer version
software to provide them to you. They're moving forward, not with their
tail clamped down in the long past trying to keep a tip of themselves
present to back then.
Simple answer: the old stuff isn't supported. Unsupported software
isn't (and should never) be bundled with supported software. It's
supported or it's not. The workarounds you performed to revive the old
unsupported softare is a procedure that is not supported. Expect
problems later, be happy if none show up.
WLM appears to download the messages OPEN, unlike OE or WM. You can read
them without clicking on them and unlike WM, they all have their own folders
which they do this in.
The downloaded e-mails are stored into files. In OE, the downloaded
e-mails were downloaded into .dbx database files. In neither case are
those e-mails "opened" until you actually use something to view them.
There are differences in view points. From the server's view point, you
opened the message to download it (see SMTP's DATA command). From the
client's point of view, it is storing the data stream into a file but is
not "opening" any message. An anti-virus program that interrogates your
e-mail client will "open" the message but does so on the fly (it
interrogates the e-mail traffic during transfer or by opening the file
on a later manual or scheduled scan). Not until you select to view the
message are you "opening" it.
The size of each email isn't the issue. I have size set to 800KBs per
email. It's the same old deleted emails coming down constantly.
The server has no concept of what is new or old or what has been read or
not. There is no attribute on a message up on the server that says it
was read. Whether a message is read or not is an attribute tracked by
the client. So it appears there is a defect in the client.
When the client downloads the message, it first gets a list of UIDs
(unique IDs). The server assigns those to each message. The client
then determines which UIDs it has not previously downloads. That way,
the client only downloads the UIDs it hasn't downloaded before instead
of all messages. You can, for example, configure your e-mail client to
not perform the default action of deleting messages from the server
after retrieving them; i.e., your client does the RETR (retrieve)
command but you tell it to not send the default DELE (delete) command.
The message stays up on the server because the client didn't delete it.
The server doesn't know whether you have read the message or not in your
local e-mail client and doesn't care. Tracking "read" status is
something the client does within its own message store.
I have had problems with a mail server when it got restored that old
messages got re-retrieved by my e-mail client. That's because the
restore ended up assigning new UIDs to the messages up on the server so
they all looked new to the client. They were new UIDs that the client
had never yet retrieved.
If the client is the one continually retrieving the same UIDs then it
looks like the client has a problem recording those UIDs. I don't know
the internals of WLM that well but do know how this situation can arise
when using Outlook. Some users configure the mail poll interval at
ridiculous and abusively short intervals, like under 5 minutes. When
their e-mail client is retrieving new messages, that takes time.
Transfer is not immediate but dependent on many bytes have to get
transferred. If the transfer takes longer than the mail poll interval,
the current mail poll gets aborted. That means the client had a failed
mail session so it doesn't record the list of UIDs of e-mails that it
received so far. It got some of the e-mails from the server, a new mail
poll got started which aborted the current mail poll, and the client
never got around to recording the list of UIDs for what it already
partially retrieved from the server. So the client didn't record those
UIDs to have them available in the next mail poll (that interrupt the
prior mail poll). Also, anything that interrogates your e-mail traffic
will lengthen the time to complete a mail poll. An anti-virus program
interrogating your e-mail traffic has to take time to do that (and why
sometimes this delay can lead to timeouts between e-mail client and
e-mail server with the intervening interrogation by the AV program).
So try disabling your anti-virus program from scanning your e-mails.
See what happens when you lengthen the mail poll interval to 10 minutes,
or more. If that doesn't work then maybe the database for the message
store in the e-mail client is corrupt and not saving the UIDs so it can
use them in the next mail poll to NOT download those same messages.
Someone in the WLM newsgroup can tell you how to slide out the old
message store (probably by renaming the store folder and creating a new
empty one) so you can see if it's a database or indexing problem.
Not in WLM. I can read them without clicking on them. Are you using WLM?
How did you set it so only the header of the email shows and no text?
As I said, to "open" means using some application to view them whether
it's WLM or using a text editor to go look at the .eml file. You also
saw headers in OE and WM. What do you think is all that info in the
headers pane showing sender, subject, date, and size?