Eudora downloads duplicate mail
r. dale shipp
I am having a problem with Eudora downloading email messages more than
once. If I read and delete a message -- no problem. But if I keep it
in a mailbox, then the same message will often turn up again in a day or
so.
If it matters, when messages come in, they are sent to various mailboxes
using filters.
Does anyone else see this? Or know how to prevent it?
--
R. Dale Shipp
spam_catcher3 (at) _delete_this_comcast (dot) net
mm
<spam_c...@comcast.net> wrote:
>
>I am having a problem with Eudora downloading email messages more than
>once. If I read and delete a message -- no problem. But if I keep it
>in a mailbox, then the same message will often turn up again in a day or
>so.
>
>If it matters, when messages come in, they are sent to various mailboxes
>using filters.
>
>Does anyone else see this? Or know how to prevent it?
I've had that for years on occasion, though not for 6 months or a year
or more now. The file that keeps track of the last email you fetchedd
gets messed up. Or maybe something at the server.
I don't know how to prevent it, but I've gotten used to handling it.
My inbox gets most of my mail. I store my mail in the order they come
in, which is alwasy close to date order. I look up the column of
dates until I find an early one E with a late one L above it. I look
at the early one and note the sender, title and date, then look
further up until I find the same email as E, called E-first
I guess I could just delete everything from E first to L, but I like
to keep the first copy for some reason (maybe I've labeled them or
replied to them and the second copy won't indicate that.)
So if I want to delete the second set, go back to the lower email E.
I noted the sender, title and date of L, the one just above it, and go
to the bottom of the list to look for a duplicate of L, L-second.
L-second is alwasy near the hottom but the ones below it are new. So
I delete everytihng from E to L-second.
In the other mailboxes there are never more than 7 or 8 of dups, and I
can do all this looking without any scrolling.
BTW scrolling with the scroll bar and the cursor doesn't change which
email is highlighted, but page-up and page-down, up-arrow and
down-arrow do.
Han
news:MPG.286b4333d...@free.teranews.com:
>
> I am having a problem with Eudora downloading email messages more than
> once. If I read and delete a message -- no problem. But if I keep it
> in a mailbox, then the same message will often turn up again in a day
> or so.
>
> If it matters, when messages come in, they are sent to various
> mailboxes using filters.
>
> Does anyone else see this? Or know how to prevent it?
The file that keeps track of which emails have been seen is called
lmos.dat. There are also backup files called lmos.dat.001 through 003.
The files are in your email directory in subdirectories under spool, for
each mail personality. These files shouldn't get messed up <grin>. It
has been a VERY long time since I had problems with these files. I hope
you're using the most recent Eudora, 7.1.0.9.
If you have reason to believe that a particular lmos.dat file is messed
up there ae 2 approaches, both of which involve downloading duplicate
emails. You can delete the lmos.dat file, and it will be regenerated on
the next mailcheck (but that involves re-downloading all the emails on
the server for that personality). Or you can delete lmos.dat and rename
lmos.dat.001 to lmos.dat. Remember, it goes by personality.
Another possibility is messed up toc files. Generally, it is considered
best to keep in, out and trash mailboxes small, because all their data
are loaded in memory when EUdora runs. For other mailboxes that is only
when you open them.
Eudora mailboxes are like a database with all the email data in 1 file
separated by markers (mbx, which is a textfile) and with an index file
(toc, table of contents, a binary file) that tells Eudora which records
in the mbx file to display. That can become a problem when you do a lot
of deleting and rearranging (such as by filters). That is because the
emails stay in the mbx file, and the toc file is needed to remember
which email should be displayed. The solution here is called
compacting. This can be done with Eudora running (menu Special|Compact
mailboxes) for all mailboxes, or individually by clicking on the box at
the lower left of a mailbox window where it says something like
1/30/287K/32K in black. After clicking it becomes 1/30/287K/0K in grey,
indicating that 32K has been freed up by compacting. I have compacting
set to be performed automatically when I close Eudora. See
<http://www.eudora.com/techsupport/kb/1712hq.html>
HTH
--
Best regards
Han
email address is invalid
John H Meyers
http://www.eudora.com/techsupport/kb/1598hq.html [Windows]
http://www.eudora.com/techsupport/kb/1685hq.html [Mac]
--
r. dale shipp
wlf...@ix.netcom.com says...
>
> On Wed, 22 Jun 2011 01:10:24 -0400, "r. dale shipp"
> comp.mail.eudora.ms-windows:
Thanks to all for the responses.
>
> >
> > I am having a problem with Eudora downloading email messages more than
> > once.
> Do you have "leave mail on server" set? Along with "delete from
> server when emptied from trash"?
I do, and will try turning that off. It should work ok without doing
that, but ...
>
> I'd have thought Eudora smart enough to track messages moved into
> other boxes via filters, but perhaps it is getting confused -- it sees a
> message on the server that has not been flagged to be deleted (not in
> trash nor trash emptied) but is not in the inbox.
So would have thought also.
John H Meyers
> I'd have thought Eudora smart enough to track messages moved into
> other boxes via filters, but perhaps it is getting confused -- it
> sees a message on the server that has not been flagged to be deleted
> (not in trash nor trash emptied) but is not in the inbox.
Why don't we organize a "witch trial"
and present these fanciful theories as our evidence?
The "server status" of any message
is stored only in Eudora's LMOS.dat file for that server,
and has nothing to do with what mailbox it's in,
or whether there are ten copies of it in ten mailboxes.
Even if you delete a message from all mailboxes,
its last-set "server status" remains in the LMOS file,
and if that status says "fetch from server" or "delete from server,"
that's what will still occur during the next POP session with that server.
Has it occurred to anyone that aside from the possible user error
of targeting the exact same server account in two separate personalities
which both check for new mail,
perhaps the SERVER is the cause of what's happening?
The POP protocol requires the SERVER to assign a somewhat arbitrary
"unique ID" to every message, and to remain absolutely consistent
in always associating that same ID with that same message
(note that these IDs are _not_ the same as in "Message-ID:" headers)
When the server fails to perform this task to perfection,
you will get duplicate downloaded messages. In the most extreme case,
when we changed our server software responsible for performing POP functions,
this action once re-numbered all messages on our server, after which
every user's mail client re-downloaded every single message on our server
(and then tied up our phone lines for quite some time afterward :)
Some people who were terrified of computers and inclined to feel guilt
about anything might have thought that a cookie crumb on their mouse pad
may have been responsible, but we had to let them off the hook by confessing
that our server software update did it all,
and nothing they did could possibly have had anything to do with it.
You can blame Eudora if you like, or your mother if you like,
but the probability is near 100% that either a fundamental
misconfiguration of personalities or a server-side error is the cause,
and a good set of session logs would be a better tool for diagnosis
than an overactive (or over-reactive) imagination.
--
John H Meyers
Connection problems may also contribute to causing possible
duplicate reception of messages, because even in SMTP protocol,
a complete message may be transmitted from point A to point B,
but if the entire session is not finally concluded with no error,
the assumption, for safety's sake, is that in lieu of "A" having
received B's acknowledgment of successful receipt,
"A" will transmit the message again, at some later time.
SMTP servers do not, like POP mail clients,
attempt to remember any history of previous receipt of messages,
so as far as B (your POP server) is concerned,
the second transmission is a new message,
and will be assigned a new, arbitrary "unique ID,"
for POP clients to remember which messages
they have already downloaded.
Due to subtle, small time delays in the Postini
(now owned by Google) spam filtering service we once used,
plus certain impatient servers "A" in particular other domains,
we ("B") sometimes received _hundreds_ of the same message
whose complete receipt we ("B") had actually acknowledged to Postini,
but whose receipt Postini had not managed to acknowledge in time to "A"
before "A" disconnected, a new one typically coming every half hour or so.
Postini had themselves worked out an elaborate way
to remember, recognize, and stop these re-deliveries,
but they turned that system off during one major server farm move,
and we went through the same experience all over again
until they realized that they had forgotten
to turn the system back on again after completion of the move.
So remember, your ISP is not necessarily perfect, like God,
as you probably know from other experiences with them,
and they should not be above being one of "the usual suspects."
--