X-Mozilla-Status code for deleted messages in Thunderbird's mbox files

[Michael A. Puls II]

If you have a pop account (using Tbird latest trunk), have a message in
your Inbox and delete it, in the "Inbox" mbox file, the message will have
an "X-Mozilla-Status: 0009" header. Then, the message won't show in your
Inbox view and will only show in the Trash view. A copy of the message
will also then appear in the "Trash" mbox file with the same 0009 status.

Then, if you go to your Trash view and empty trash, the message will
disappear from the trash view (and the "Trash" mbox file), but will still
be in the "Inbox" mbox file with "X-Mozilla-Status: 0009".

A few questions:

1. Is "X-Mozilla-Status: 0009" the proper way to detect that the message
is deleted?

2. If so, can one count on "X-Mozilla-Status: 0009" remaining as the
deleted signifier for a long time?

3. Is there any way to detect that a message in an mbox file has been
deleted AND has been removed from the Trash view, and just not compacted?
I'm thinking that the only way to do that is to see if a message with
status 0009 in an mbox file is also in the "Trash" mbox file. If it's not
also in the "Trash" mbox file, then the message has been deleted, emptied
from the Trash and just not compacted. Otherwise, it's just deleted and
being shown in the Trash view.

Thanks

--
Michael

[Michael A. Puls II]

Also, on a side, is there a tag or header for the message in the mbox file
that says that it has been fetched but not removed from the server? Or, is
something like that only known in the index?

--
Michael

[Marcel Berteler]

Michael A. Puls II wrote the following on 2010/01/26 11:49:
>
> Also, on a side, is there a tag or header for the message in the mbox
> file that says that it has been fetched but not removed from the server?
> Or, is something like that only known in the index?
>

Although related to TB2 this might still be helpful:

http://forums.mozillazine.org/viewtopic.php?f=30&t=403997

"getting the state should just be a matter of looking for the messageid
of the message in the popstate file and also using the msg_flag_partial
flag to see if it was only partially downloaded.."

Marcel

[Michael A. Puls II]

On Tue, 26 Jan 2010 08:18:01 -0500, Marcel Berteler <plu...@gmail.com>
wrote:

I see. The id entry for the message in popstate.dat disappears when the
message is removed from the server.

Thanks

--
Michael

[Andrew Sutherland]

On 01/25/2010 04:32 AM, Michael A. Puls II wrote:
> If you have a pop account (using Tbird latest trunk), have a message in
> your Inbox and delete it, in the "Inbox" mbox file, the message will

You shouldn't be programming against the mbox file. What are you trying
to do?

Andrew

[Michael A. Puls II]

Test importing in various clients and coming up with ways to avoid
importing the hidden, deleted messages and to avoid importing messages
that are still on the server.

--
Michael

[Andrew Sutherland]

On 01/26/2010 11:22 AM, Michael A. Puls II wrote:
> Test importing in various clients and coming up with ways to avoid
> importing the hidden, deleted messages and to avoid importing messages
> that are still on the server.

That's a very good reason to program against the mbox files!

Those status lines are reliably present and will be reliably updated.

The status bits are from these flags:
http://mxr.mozilla.org/comm-central/source/mailnews/base/public/nsMsgMessageFlags.idl

If you look at the definitions there, the 9 is really 1 for read and 8
for expunged. You want to ignore the expunged messages.

I don't think you should need to correlate against the trash folder. If
something is expunged, Thunderbird is not going to show it and may not
even know about the message anymore. (The status bit just tells us to
ignore it if the msf file gets blown away and we need to rebuild things.)

Andrew

[Michael A. Puls II]

On Tue, 26 Jan 2010 14:47:48 -0500, Andrew Sutherland
<somb...@alum.mit.edu> wrote:

> On 01/26/2010 11:22 AM, Michael A. Puls II wrote:
>> Test importing in various clients and coming up with ways to avoid
>> importing the hidden, deleted messages and to avoid importing messages
>> that are still on the server.
>
> That's a very good reason to program against the mbox files!
>
> Those status lines are reliably present and will be reliably updated.

Cool, thanks.

> The status bits are from these flags:
> http://mxr.mozilla.org/comm-central/source/mailnews/base/public/nsMsgMessageFlags.idl
>
> If you look at the definitions there, the 9 is really 1 for read and 8
> for expunged. You want to ignore the expunged messages.

I see. So, it won't be 0009 always. For example, if a reply to the message
was successfully sent and then you delete the message, it'd be 000b.

Since it won't always be 0009, what should I be doing programming bitwise
to compare the status against 0x00000008 to always detect if it's expunged
no matter what the status is?

> I don't think you should need to correlate against the trash folder. If
> something is expunged, Thunderbird is not going to show it and may not
> even know about the message anymore. (The status bit just tells us to
> ignore it if the msf file gets blown away and we need to rebuild things.)

Well, I was thinking about when you import the Trash mbox and the Inbox
mbox at the same time for example. You'd want to avoid duplicates. But,
the rule in that case would be to ignore 0x00000008 messsages in mboxes
not named "Trash".

Thanks

--
Michael

[Andrew Sutherland]

On 01/26/2010 12:55 PM, Michael A. Puls II wrote:
> Well, I was thinking about when you import the Trash mbox and the Inbox
> mbox at the same time for example. You'd want to avoid duplicates. But,
> the rule in that case would be to ignore 0x00000008 messsages in mboxes
> not named "Trash".

I think your observation regarding the bit masks of messages in the
Trash is suspect. I am not aware of any code that inverts the meaning
of the Expunged bit based on the message residing in a trash folder.
When I just looked in my own local trash folder, the message there only
had the read bit marked and not the expunged bit.

Andrew

[Michael A. Puls II]

(resending this. It didn't seem to go to the list yesterday)

Yeh, I'm seeing the behavior you're seeing now. (So, then, I wouldn't need
the "not named "Trash" rule that I mentioned.)

I was pretty sure the expunge bit was on messages in the trash. But,
unless I reproduce that, I'll consider myself crazy. :)

Thanks

--
Michael

[Michael A. Puls II]

On Tue, 26 Jan 2010 15:55:06 -0500, Michael A. Puls II
<shado...@gmail.com> wrote:

> On Tue, 26 Jan 2010 14:47:48 -0500, Andrew Sutherland
> <somb...@alum.mit.edu> wrote:
>
>> On 01/26/2010 11:22 AM, Michael A. Puls II wrote:
>>> Test importing in various clients and coming up with ways to avoid
>>> importing the hidden, deleted messages and to avoid importing messages
>>> that are still on the server.
>>
>> That's a very good reason to program against the mbox files!
>>
>> Those status lines are reliably present and will be reliably updated.
>

> Cool, thanks.

>
>> The status bits are from these flags:
>> http://mxr.mozilla.org/comm-central/source/mailnews/base/public/nsMsgMessageFlags.idl
>>
>> If you look at the definitions there, the 9 is really 1 for read and 8
>> for expunged. You want to ignore the expunged messages.
>

> I see. So, it won't be 0009 always. For example, if a reply to the
> message was successfully sent and then you delete the message, it'd be
> 000b.
>
> Since it won't always be 0009, what should I be doing programming
> bitwise to compare the status against 0x00000008 to always detect if
> it's expunged no matter what the status is?
>

Is this correct?:

bool isExpunged(const unsigned long status) {
return (0x00000008 & status) == 8;
}

--
Michael

[Andrew Sutherland]

On 01/27/2010 02:29 AM, Michael A. Puls II wrote:
> Is this correct?:
>
> bool isExpunged(const unsigned long status) {
> return (0x00000008 & status) == 8;
> }

That works.

Andrew

[Michael A. Puls II]

Thanks

--
Michael