I'm testing some software and want to be able to keep getting the same mail item from the server. But Eudora doesn't seem to let me - it knows it's already got it! How can I defeat this without throwing away the Eudora Folder and starting from scratch (tedious)? Its in a file somewhere, presumably.
In article <timstreater-E977B2.22242625062...@news.individual.net>, Tim Streater <timstrea...@waitrose.com> wrote:
> I'm testing some software and want to be able to keep getting the same > mail item from the server. But Eudora doesn't seem to let me - it knows > it's already got it! How can I defeat this without throwing away the > Eudora Folder and starting from scratch (tedious)? Its in a file > somewhere, presumably.
This is really more a server-side issue, and is dependent on the server being used and on the protocol: IMAP can actually be quite annoying in this regard because UID's are really a hierarchical triple of the mailbox, UID-validity-timestamp, and a UID number. As a result, you cannot move a message between IMAP folders and preserve its logical identity without tracking it on the client side in ways that are intrinsically flawed. Conversely, the one-mailbox model of POP means that its UID's almost never have any reason to be changed, so most POP servers don't have any logic for making that happen.
So while the direct answer to your question is that the server UID for a message is mapped to the Eudora copy of the message in the resource fork of the mailbox that the message is in, there is probably some better approach that actually causes the server to assign a new UID instead of getting Eudora to forget that it has seen a message. If you really want Eudora to forget that mapping (and all metadata about a message that isn't in the actual data) for a POP-delivered message you can close the file in Eudora, remove the resource fork, and change the modtime on the data fork, and make sure you have Eudora's duplicate elimination turned off (in the "Really Miscellaneous" setting pane.) I don't think relaunching Eudora is necessary, but it could be. You might be able to be less destructive to an entire mailbox by editing out the part of TOCF #1001 (and 1002 if it exists) in the mailbox resource fork that refers to the message in question, but that would be a very advanced technique (sub-task #1: reverse-engineer the meaning of the TOCF structure...) For an IMAP-delivered message, you can also manually tell Eudora to "Remove Cached Contents" with the menu hiding under the server status column and you MIGHT be able to use AppleScript to tell Eudora to flip the "will be fetched" property of a message to force re-fetching. I have not tested that...
The better way to deal with this would probably be to change your requirement from "get Eudora to re-fetch the same message repeatedly" to "make the server present a copy of a message with a new UID" if that is possible.
> In article <timstreater-E977B2.22242625062...@news.individual.net>, > Tim Streater <timstrea...@waitrose.com> wrote:
> > I'm testing some software and want to be able to keep getting the same > > mail item from the server. But Eudora doesn't seem to let me - it knows > > it's already got it! How can I defeat this without throwing away the > > Eudora Folder and starting from scratch (tedious)? Its in a file > > somewhere, presumably.
> This is really more a server-side issue, and is dependent on the server > being used and on the protocol: IMAP can actually be quite annoying in > this regard because UID's are really a hierarchical triple of the > mailbox, UID-validity-timestamp, and a UID number. As a result, you > cannot move a message between IMAP folders and preserve its logical > identity without tracking it on the client side in ways that are > intrinsically flawed. Conversely, the one-mailbox model of POP means > that its UID's almost never have any reason to be changed, so most POP > servers don't have any logic for making that happen.
> So while the direct answer to your question is that the server UID for a > message is mapped to the Eudora copy of the message in the resource fork > of the mailbox that the message is in, there is probably some better > approach that actually causes the server to assign a new UID instead of > getting Eudora to forget that it has seen a message. If you really want > Eudora to forget that mapping (and all metadata about a message that > isn't in the actual data) for a POP-delivered message you can close the > file in Eudora, remove the resource fork, and change the modtime on the > data fork, and make sure you have Eudora's duplicate elimination turned > off (in the "Really Miscellaneous" setting pane.) I don't think > relaunching Eudora is necessary, but it could be. You might be able to > be less destructive to an entire mailbox by editing out the part of TOCF > #1001 (and 1002 if it exists) in the mailbox resource fork that refers > to the message in question, but that would be a very advanced technique > (sub-task #1: reverse-engineer the meaning of the TOCF structure...) For > an IMAP-delivered message, you can also manually tell Eudora to "Remove > Cached Contents" with the menu hiding under the server status column > and you MIGHT be able to use AppleScript to tell Eudora to flip the > "will be fetched" property of a message to force re-fetching. I have not > tested that...
Phew!
> The better way to deal with this would probably be to change your > requirement from "get Eudora to re-fetch the same message repeatedly" to > "make the server present a copy of a message with a new UID" if that is > possible.
Yes, as it happens. I'm using ImportServer to serve up the mail items. If I change the name of the .mbx file that ImportServer reads, then apparently different UIDs ensue.
I did poke around in the Settings file with ResKnife (thinking that's where the UIDs might be stored), but to no avail. I suppose I could make Eudora use .toc files and examine those, but that would be a distraction.
I set myself a little task - to write a PHP script to export the contents of an Odysseus mail folder. It's been quite interesting so far, learning about the PDO interface to SQLite in PHP, as well as how mail items are structured. I'm testing on a large mailbox now (35k mail items).
On Wed, 25 Jun 2008 16:24:26 -0500, Tim Streater wrote: > I'm testing some software > and want to be able to keep getting the same mail item from the server. > But Eudora doesn't seem to let me - it knows it's already got it!
Exactly; that's what UIDs (server-assigned unique IDs for every message) are for, so that POP clients can avoid repeatedly downloading messages which the user instructs them not to order the server to delete, by storing all the current UIDs and comparing them to the set presented by the server next time; the user typically chooses such a "leave mail on server" (LMOS) setting either to share mail between multiple clients, or to allow re-fetching recent mail if a client computer fails, or to share access with a "webmail" viewer.
> How can I defeat this without throwing away the > Eudora Folder and starting from scratch (tedious)? > Its in a file somewhere, presumably.
Indeed it must be, but Eudora doesn't document where for Mac (it's in distinct files named "lmos.dat" under Windows).
Can you back up an "initial" Eudora Folder with settings already made, and just keep restoring that entire backup folder, to in effect start anew, without having to re-define any settings?
If you want to find out exactly where those UIDs are, you could capture some UID samples either by manually logging in with a "telnet" client and viewing the results of a UIDL command, or by using some other email client whose UIDs are more easily found, then search all Eudora files for matching strings; after all, they do have to be somewhere, and it would hardly make any sense to encrypt or disguise them in any way that a tool for finding files containing a string can't find.
In addition, the modification time stamps on files can narrow the search to those which are modified upon fetching new messages or deleting old messages from the server, when LMOS is in effect.
> On Wed, 25 Jun 2008 16:24:26 -0500, Tim Streater wrote:
> > I'm testing some software > > and want to be able to keep getting the same mail item from the server. > > But Eudora doesn't seem to let me - it knows it's already got it!
> Exactly; that's what UIDs (server-assigned unique IDs for every message) > are for, so that POP clients can avoid repeatedly downloading messages > which the user instructs them not to order the server to delete, > by storing all the current UIDs > and comparing them to the set presented by the server next time; > the user typically chooses such a "leave mail on server" (LMOS) > setting either to share mail between multiple clients, > or to allow re-fetching recent mail if a client computer fails, > or to share access with a "webmail" viewer.
> > How can I defeat this without throwing away the > > Eudora Folder and starting from scratch (tedious)? > > Its in a file somewhere, presumably.
> Indeed it must be, but Eudora doesn't document where for Mac
That was the conclusion I came to.
> (it's in distinct files named "lmos.dat" under Windows).
This came to light after a search on the Eudora website.
Tim Streater <timstrea...@waitrose.com> wrote: > I'm testing some software and want to be able to keep getting the same > mail item from the server. But Eudora doesn't seem to let me - it knows > it's already got it! How can I defeat this without throwing away the > Eudora Folder and starting from scratch (tedious)? Its in a file > somewhere, presumably.
I don't know where the UID's are stored, but one way to get all the mail still on server is to check mail special, then click on "fetch all message headers to Inbox."
