752237 - Thunderbird Filter Duplicates Messages, sometimes with date of 01/01/1970, only in the Unified Inbox

Status: NEW

(MailNews Core :: Filters, defect)

Description

[roger]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

I have several filters set up which move certain arriving messages from the Inbox to another mailbox in my Local Folders.

I am using Thunderbird 12.0.1 under Windows 7 with all current updates.



Actual results:

When Thunderbird is **first** started and qualifying messages are waiting on the imap server, two identical copies of them are transferred, and a "ghost" message with no "Subject" or "From" and a date/time of "00/00/0000 00:00" is left in the Inbox. This disappears when focus returns to the Inbox from another mailbox.

The problem has been occuring for many months - I kept hoping an update would resolve it!

When qualifying messages arrive **after** Thunderbird has started, there are no problems. Behaviour is as expected.


Expected results:

The message should have been moved once to another mailbox, leaving nothing in the Inbox.

Comment 1

[Marcus Groeber]

This looks like it could be a duplicate of bug 519083 (or at least a close relative).

Comment 2

[roger]

Attachment: Screen shot showing two phantom messages in Inbox

This screenshot shows two phantom messages which remain in the Inbox after the messages have been moved out. These disappear when the Inbox is next selected.

Comment 3

[roger]

Attachment: Screen shot showing two duplicated messages in the destination Local Folder

THis shows two pairs of duplicated messages in the destination folder. Note that in the Folder List, Inbox is shown with 4 unread messages. Two of these are "Genuine", the other two are the phantom messages which disappear when Inbox is next accessed.

Comment 4

[roger]

Further observation:

When TB first accesses the server, waiting messages appear one at a time in the Inbox. They are then transferred one at a time to the local folder. 

The whole sequence then repeats - they appear in the Inbox again, and are transferred out again.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to roger from comment #2)
> Created attachment 621531 [details]
> Screen shot showing two phantom messages in Inbox

"Inbox - Unified Folders".

Show "Account"/"Location"/"Order Received" column for ease of your checking. 
What is shown at "Account"/"Location"/"Order Received" column of the "Inbox - Unified Folders" for these phantom mails?

Do you see the phantom messages in Inbox at View/Folder/All instead of View/Folders Unified"?
If phantom messages are shown, in which account's Inbox? What is "Order Received" column value? What is shown by View/Message Source?

What is shown by following?
(1) <maildir_path> == Location: of Server Settings of the account
    <local_path>   == Location: of Server Settings of "Local Folders"
(2) Terminate Tb.
(3) Copy <maildir_path>\Inbox to <local_path>\Inbox-Backup
(4) Restart Tb, Inbox-Backup appears at "Local Folders".
    Internal "Repair Folder"(rebuild index) is executed.
Do you still see phantom mails in Inbox-Backup of "Local Folders"?
What is difference between original Inbox of the account and Inbox-Backup of "Local Folders"?

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to roger from comment #0)
> Build ID: 20120420145725
> I am using Thunderbird 12.0.1 under Windows 7 with all current updates.

Following is shown at Help/Trouble Shooting Information/User Agent if Tb 12.0.1 for Win32.  
> Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
?
Which version is actually used when you saw your problem? Tb 12.0.0? Tb 12.0.1?

Do you see your problem with Tb 12.0.1, even after following?
(a) At View/Folders/All, folder's Properties/General/Repiar Folder of Inbox of all accounts.
(b) At View/Folders/All, folder's Properties/General/Repiar Folder of the filter's move target folder of "Local Folders".

Comment 7

[roger]

WADA: thank you for your suggestions.

I can answer some of your points, but others will have to wait until the next time the problem occurs: it only happens when qualifying messages are waiting when the computer is first turned on and Thunderbird is re-started. I have not been able to reproduce it by sending myself messages through another account. 

The phantom emails are completely transient - they appear after the messages have moved, and disappear as soon as the inbox is re-selected. They do not appear in "deleted" or anywhere else that I can think of. I cannot check whether they appear in "all folders" until the next time the problem occurs - there are none there now.

I have copied Inbox as you suggest. There are no phantom emails in either box. But whereas there are 17 messages (all read) in inbox, there are 108 messages (12 unread) in inbox-backup.

User agent is Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
Build ID is currently 20120428123112. The problem has occured both in TB12.0.0 and 12.0.1.

I have repaired Inbox on all accounts, with no visible changes.

I will post again when I have any further information.

Comment 8

[roger]

WADA - further observations

1. The phantom messages are only visible in Inbox Unified-Folders. They do not appear in any of the 'component' inbox folders, or in the inbox-backup made immediately after the messages arrived.
2. inbox-backup is about twice the size of Inbox (305kB/150kB) and includes the messages which were transferred to the local folder. Whereas 2 copies of each of the 3 messages appeared in the local folder, there are THREE copies of 2 of them and 2 of the other one in inbox-backup.
3. The three phantom messages have sequential 'order received' numbers ranging from 11109 to 11111, in sequence with other messages in inbox.
4. In the local folder, the duplicate copies have different, non-sequential, 'order received' numbers around 2150000. In inbox-backup, they are also non-sequential, around 235000.

I hope this information helps in diagnosing the problem.

Comment 9

[roger]

Another observation with a rather different behaviour:

This morning I have a phantom message in Inbox but no messages transferred to the Local Folder and no entries in the filter log.

It is possible to open the phantom message, and it is in fact a message which was deleted 10 days ago.

It appears in the Unified Folders Inbox, but not under any of the individual inboxes within it. It does not disappear on re-opening the folder (as previous cases have done). It disappeared when I deleted it, but did not appear (in any recognisable form) in the Deleted folder.

Comment 10

[roger]

This behaviour has recently changed. Now, every message which is downloaded when the computer is first switched on (with TB in the Startup folder) appears duplicated in the inbox. When one of the copies is selected, the other also goes into 'read' format. Moving away from Inbox leaves a marker of one unread message. Moving back removes this, and only one of the copies remains.

This suggests that the problem is occuring at download time, and is not now related to filters.

Thunderbird has recently updated to 15.0.1.

Comment 11

[roger]

This problem has not gone away, but I have discovered that it does not occur if Inbox (unified) is not the current folder when Thunderbird loads. (Now using Thunderbird 17.0.2).

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to roger from comment #11)
> This problem has not gone away, but I have discovered that it does not occur
> if Inbox (unified) is not the current folder when Thunderbird loads. (Now
> using Thunderbird 17.0.2).

So to summarize, this is only in the Unified Inbox, and the underlying inbox is not affected?  No filters are involved?  And you have no filters or addons which might impact this?

Comment 13

[Marcus Groeber]

Attachment: tbird_log.zip

I have been experiencing a very similar issue to what Roger reports over the past few years now (IMAP, new messages duplicated upon arrival, effect goes away when the Inbox is /not/ the current folder). However, I also see this without using the unified inbox.

The attached zipfile contains two IMAP logs (created as described in http://email.about.com/od/mozillathunderbirdtips/qt/et_mail_log.htm):

 - tbird_log.txt from a session where I started Thunderbird, and then immediately moved away the focus from the Inbox, so no duplication occurred

 - tbird_log_dup.txt from a session where I started Thunderbird and left the focus on the Inbox, and duplicated reading occurs

Each time, I had sent two messages with subject "Test 1" and "Test 2" to myself before starting the session.

These logs are from Thunderbird 17.0.8 on Windows 8, but I have seen similar behaviour over many years with earlier versions almost every time I check for new mail.

Perhaps this helps in tracking down things. To me, this feels like it could be a race condition related to when the \Seen flag on the server is set, but this is just a wild guess...

Comment 14

[roger]

I am not certain whether it only occurs with unified folders. I cannot reproduce it under controlled conditions, but it occurs in the following situation:

1. The computer is switched on with Thunderbird as a start up program, and unified inbox as the current folder.
2. An email arrives from one of a certain group of senders.
3. A filter activates to move this email to another local folder.

The email is moved, then appears to be moved again instantly (almost as if another copy arrived). Two copies end up in the other folder, and a 'null' entry is left in the (unified) inbox.

Selecting any other folder then returning to inbox deletes the null entry.

I cannot reproduce this on demand because I cannot send a qualifying email to be waiting at startup time.

This does ***not*** occur when an email arrives after the initial startup, or when the current folder is not inbox at startup.

Comment 15

[roger]

I have now done a test where the folder view is not unified at startup. The problem did not occur - behaviour was as it should be.

Comment 16

[Tsukasa OI]

I have this issue and was able to easily reproduce this issue (I believe) on a clean environment.



[HOW TO REPRODUCE]

1. Create folders "1A", "1B", "2" and "3" on local folders
2. Create following four mail filters ("Filters for" is set to process received emails; this issue occurs on both <ACCOUNT_NAME> and "Local Folders")
| Name = abc_1a
| - Filter after Junk Classification
| - Subject begins with "AB"
| - Move message to "1A" on local folders
| Name = abc_1b
| - Filter after Junk Classification
| - Subject ends with "BC"
| - Move message to "1B" on local folders
| Name = abc_2
| - Filter after Junk Classification
| - Junk status isn't junk
| - Move message to "2" on local folders
| Name = abc_3
| - Filter after Junk Classification
| - Match all messages
| - Move message to "3" on local folders
3. Send a non-spam email (with subject "ABC", "ABBC" or some) to be filtered by Thunderbird
4. Three copies of a message will be created at "1A", "2" and "3" on local folders



[FILTER LOG]

By enabling filter log, I get this log (partially modified). Note that "1970/01/01 9:00:00" is the UNIX epoch at local time because I'm testing this at Japan (JST = UTC+0900).

| Applied filter "abc_1a" to message from "TESTMAIL" <[e-mail]> - ABC at 2015/02/28 1:32:03 moved message id = [e-mail] to mailbox://nobody@Local%20Folders/1A
| Applied filter "abc_2" to message from - at 1970/01/01 9:00:00 moved message id = to mailbox://nobody@Local%20Folders/2
| Applied filter "abc_3" to message from - at 1970/01/01 9:00:00 moved message id = to mailbox://nobody@Local%20Folders/3



[ANALYSIS : SERVER PROTOCOL DEPENDENT?]

No. I tested both POP3 and IMAP environments but both showed the same duplication bug.
But I first found this bug on IMAP environment because I tried to filter "all messages" on IMAP Inbox and move "unfiltered" messages to the local Inbox.



[ANALYSIS : FOLDER DEPENDENT?]

I think yes. When I modify the test environment and make all filters to move messages to "account-dependent" folders, I couldn't reproduce the issue.
Sorry that I haven't tested the case when "some" filters move messages to local folders.



[ANALYSIS : CONTEXT DEPENDENT?]

I think yes because in my environment this issue occured only on "Filter after Junk Classification" context.



[ANALYSIS : FILTER CLASSES]

In my environment, match by "Junk Status" and "Match all messages" are causing issues.
When a filter matches and moved to other folders, it should stop filtering. However, in my environment, a few unexpected behavior occurs. If two filters both match and both filters try to move a message to another folder, behavior like this happens.

Pattern 1 :: FILTER: (other?) -> FILTER: (other?)
| Only first filter matches [expected]

Pattern 2 :: FILTER: "Junk Status isn't Junk" -> FILTER: "Junk Status isn't Junk"
| Both filters match and causes message duplication [UNEXPECTED]

Pattern 3 :: FILTER: "Match all messages" -> FILTER: "Match all messages"
| Both filters match and causes message duplication [UNEXPECTED]

Pattern 4 :: FILTER: (other?) -> FILTER: "Junk Status isn't Junk"
| Both filters match and causes message duplication [UNEXPECTED]

Pattern 5 :: FILTER: "Junk Status isn't Junk" -> FILTER: (other?)
| Only first filter matches [expected]

Pattern 6 :: FILTER: (other?) -> FILTER: "Match all messages"
| Both filters match and causes message duplication [UNEXPECTED]

Pattern 7 :: FILTER: "Match all messages" -> FILTER: (other?)
| Only first filter matches [expected]

Pattern 8 :: FILTER: "Junk Status isn't Junk" -> FILTER: "Match all messages"
| Both filters match and causes message duplication [UNEXPECTED]

Pattern 9 :: FILTER: "Match all messages" -> FILTER: "Junk Status isn't Junk"
| Only first filter matches [expected]

Using my reproduction method, you can reproduce unexpected patterns 4 and 8. I tested other combinations and got results above.

Comment 17

[Tsukasa OI]

My test environment of comment 15 was...

- Thunderbird 31.5.0
- Microsoft Windows on x86
- Time zone : Japan Standard Time (UTC+0900)

Comment 18

[Tsukasa OI]

Stack Trace on Earlybird 31.5.0 built from TB source code
- Captured when message filter log is generated (nsMsgFilter::LogRuleHit)
- Configuration just as comment 16

When running "correct" filter (e.g. "abc_1a"):
>	xul.dll!nsMsgFilter::LogRuleHit(nsIMsgRuleAction * aFilterAction, nsIMsgDBHdr * aMsgHdr) Line 481	C++
>	xul.dll!nsMsgFilterAfterTheFact::ApplyFilter(bool * aApplyMore) Line 471	C++
>	xul.dll!nsMsgApplyFiltersToMessages::RunNextFilter() Line 954	C++
>	xul.dll!nsMsgFilterAfterTheFact::AdvanceToNextFolder() Line 366	C++
>	xul.dll!nsMsgFilterService::ApplyFilters(int aFilterType, nsIArray * aMsgHdrList, nsIMsgFolder * aFolder, nsIMsgWindow * aMsgWindow) Line 1002	C++
>	xul.dll!nsMsgDBFolder::OnMessageClassified(const char * aMsgURI, unsigned int aClassification, unsigned int aJunkPercent) Line 2351	C++
>	xul.dll!nsImapMailFolder::OnMessageClassified(const char * aMsgURI, unsigned int aClassification, unsigned int aJunkPercent) Line 9142	C++
>	xul.dll!nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow * aMsgWindow, bool * aFiltersRun) Line 2809	C++
>	xul.dll!nsImapMailFolder::HeaderFetchCompleted(nsIImapProtocol * aProtocol) Line 5859	C++
>	xul.dll!`anonymous namespace'::SyncRunnable1<nsIImapMailFolderSink,nsIImapProtocol *>::Run() Line 119	C++
>	xul.dll!nsThread::ProcessNextEvent(bool mayWait, bool * result) Line 715	C++
>	xul.dll!NS_ProcessNextEvent(nsIThread * thread, bool mayWait) Line 263	C++
>	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate) Line 136	C++
>	xul.dll!MessageLoop::RunInternal() Line 229	C++
>	xul.dll!MessageLoop::RunHandler() Line 223	C++
>	xul.dll!MessageLoop::Run() Line 197	C++
>	xul.dll!nsBaseAppShell::Run() Line 166	C++
>	xul.dll!nsAppShell::Run() Line 191	C++
>	xul.dll!nsAppStartup::Run() Line 279	C++
>	xul.dll!XREMain::XRE_mainRun() Line 4008	C++
>	xul.dll!XREMain::XRE_main(int argc, char * * argv, const nsXREAppData * aAppData) Line 4077	C++
>	xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData, unsigned int aFlags) Line 4289	C++
>	thunderbird.exe!do_main(const char * exePath, int argc, char * * argv) Line 124	C++
>	thunderbird.exe!NS_internal_main(int argc, char * * argv) Line 214	C++
>	thunderbird.exe!wmain(int argc, wchar_t * * argv) Line 112	C++

When running "incorrect" filter (e.g. "abc_2"):
>	xul.dll!nsMsgFilter::LogRuleHit(nsIMsgRuleAction * aFilterAction, nsIMsgDBHdr * aMsgHdr) Line 481	C++
>	xul.dll!nsMsgFilterAfterTheFact::ApplyFilter(bool * aApplyMore) Line 471	C++
>	xul.dll!nsMsgApplyFiltersToMessages::RunNextFilter() Line 954	C++
>	xul.dll!nsMsgFilterAfterTheFact::OnStopCopy(tag_nsresult aStatus) Line 1040	C++
>	xul.dll!nsMsgCopyService::ClearRequest(nsCopyRequest * aRequest, tag_nsresult rv) Line 212	C++
>	xul.dll!nsMsgCopyService::NotifyCompletion(nsISupports * aSupport, nsIMsgFolder * dstFolder, tag_nsresult result) Line 687	C++
>	xul.dll!nsMsgLocalMailFolder::OnCopyCompleted(nsISupports * srcSupport, bool moveCopySucceeded) Line 1359	C++
>	xul.dll!nsMsgLocalMailFolder::EndMove(bool moveSucceeded) Line 2558	C++
>	xul.dll!nsCopyMessageStreamListener::EndCopy(nsISupports * url, tag_nsresult aStatus) Line 134	C++
>	xul.dll!nsCopyMessageStreamListener::OnStopRequest(nsIRequest * request, nsISupports * ctxt, tag_nsresult aStatus) Line 144	C++
>	xul.dll!nsStreamListenerTee::OnStopRequest(nsIRequest * request, nsISupports * context, tag_nsresult status) Line 54	C++
>	xul.dll!nsImapCacheStreamListener::OnStopRequest(nsIRequest * request, nsISupports * aCtxt, tag_nsresult aStatus) Line 8630	C++
>	xul.dll!nsInputStreamPump::OnStateStop() Line 704	C++
>	xul.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream) Line 439	C++
>	xul.dll!nsInputStreamReadyEvent::Run() Line 86	C++
>	xul.dll!nsThread::ProcessNextEvent(bool mayWait, bool * result) Line 715	C++
>	xul.dll!NS_ProcessNextEvent(nsIThread * thread, bool mayWait) Line 263	C++
>	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate) Line 95	C++
>	xul.dll!MessageLoop::RunInternal() Line 229	C++
>	xul.dll!MessageLoop::RunHandler() Line 223	C++
>	xul.dll!MessageLoop::Run() Line 197	C++
>	xul.dll!nsBaseAppShell::Run() Line 166	C++
>	xul.dll!nsAppShell::Run() Line 191	C++
>	xul.dll!nsAppStartup::Run() Line 279	C++
>	xul.dll!XREMain::XRE_mainRun() Line 4008	C++
>	xul.dll!XREMain::XRE_main(int argc, char * * argv, const nsXREAppData * aAppData) Line 4077	C++
>	xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData, unsigned int aFlags) Line 4289	C++
>	thunderbird.exe!do_main(const char * exePath, int argc, char * * argv) Line 124	C++
>	thunderbird.exe!NS_internal_main(int argc, char * * argv) Line 214	C++
>	thunderbird.exe!wmain(int argc, wchar_t * * argv) Line 112	C++

Comment 19

[Tsukasa OI]

I also tested with Earlybird 38.0a2 (2015-02-27) and I could not reproduce the issue (filters work as expected; including complex filter combinations). This bug might be disappeared during filter engine improvements.
I hope current Thunderbird 31.x to be fixed anyway but ... maybe we can close this ticket when version 38 is released.

Comment 20

[WADA:World Anti-bad-Duping Agency]

(In reply to Tsukasa OI from comment #16)
> [FILTER LOG]
> | Applied filter "abc_2" to message from - at 1970/01/01 9:00:00 moved
> message id = to mailbox://nobody@Local%20Folders/2
> | Applied filter "abc_3" to message from - at 1970/01/01 9:00:00 moved
> message id = to mailbox://nobody@Local%20Folders/3
>(snip)
> Pattern 2 :: FILTER: "Junk Status isn't Junk" -> FILTER: "Junk Status isn't Junk"
>(snip)
> Pattern 4 :: FILTER: (other?) -> FILTER: "Junk Status isn't Junk"
>(snip)

What is difference of "above on filter log of this bug" from Bug 762318(patch was proposed to Bug 935934)?

Comment 21

[WADA:World Anti-bad-Duping Agency]

> Bug summary : (A) Thunderbird Filter Duplicates Messages, (B) sometimes with date of 01/01/1970, only in the Unified Inbox

This bug is for which problem?
   (i)  only (B), without (A) 
   (ii) only (A), without (B)
   (iii) (A) with associated (B)

Comment 22

[Tsukasa OI]

(In reply to WADA from comment #20)

> What is difference of "above on filter log of this bug" from Bug
> 762318(patch was proposed to Bug 935934)?

I see no differences looking at the logs but there are several differences.

* There is actually a "message duplication" bug as original post
  (this is not only a logging issue)
* The log output on comment 16 looks not exactly affected by Bug 935934 because
  they have different code paths (see stack trace at comment 18).
  It could be other kinds of difference (refactoring, etc...) though.

I wanted to show something is going wrong but the log may not be a good idea...

Comment 23

[Tsukasa OI]

(In reply to WADA from comment #21)

> This bug is for which problem?
>    (i)  only (B), without (A) 
>    (ii) only (A), without (B)
>    (iii) (A) with associated (B)

The bug I can reproduce (easily) is (ii) [message duplication without timestamp changes].
But I saw some timestamp changes at my personal TB environment at the same time as message duplication (I could not be reproduced though). So it *might be* (iii) [message duplication *WITH/WITHOUT* timestamp changes] (I don't have any proofs though).

Comment 24

[WADA:World Anti-bad-Duping Agency]

(In reply to Tsukasa OI from comment #23)
> > This bug is for which problem?
> >    (i)  only (B), without (A) 
> >    (ii) only (A), without (B)
> >    (iii) (A) with associated (B)
> The bug I can reproduce (easily) is (ii) [message duplication without timestamp changes].
> But I saw some timestamp changes at my personal TB environment at the same time as message duplication (I could not be reproduced though). 
> So it *might be* (iii) [message duplication *WITH/WITHOUT* timestamp changes] (I don't have any proofs though).

Oh, "(A) Thunderbird Filter Duplicates Messages" was reproducible...
As easily known by Bug 935934(and Bug 762318), I could reproduce "(i)  only (B), without (A)" only, with "Just Before Classificatin" only.
Please note that "After Junk Classifiction" was a simple workaround of Bug 762318.

(In reply to Tsukasa OI from comment #19)
> I also tested with Earlybird 38.0a2 (2015-02-27) and I could not reproduce the issue
> (filters work as expected; including complex filter combinations).

Did both "(A) with Junk After Classification" and "(B) with After unk Classicication" disappear in Tb 38?

Comment 25

[Tsukasa OI]

(In reply to WADA from comment #24)

> Please note that "After Junk Classifiction" was a simple workaround of Bug
> 762318.
I see.

> Did both "(A) with Junk After Classification" and "(B) with After unk
> Classicication" disappear in Tb 38?
I tested only (A) [message duplication] because I could not reproduce or test (B) [with timestamp changes] in the stable way (more of that, [B; not A] in my personal TB 31.5.0 environment disappeared after messing around message filters and I don't know how did I "fix" this).
So I don't know whether timestamp changes issue is fixed in TB 38. Sorry. At least, my test at TB 38 did not cause any unexpected timestamp changes.

Comment 28

[Stephen]

Still seeing this bug on Thunderbird 60.9.0 (32-bit) running on Windows. I have a number of filters running on a Gmail IMAP account. Occasionally messages are duplicated with the filter log indicating no sender/message title and a date of 1970-01-01 (although the duplicated message itself is perfectly formed). An example of the filter log:

[2021-01-21, 12:57:30] Applied filter "Move remaining mail to subscriptions" to message from "Someone" <a@b.c> - Message Title at 2021-01-21, 12:57:15 moved message id = [e-mail] to mailbox://nobody@Local%20Folders/Inbox/Subscriptions

[2021-01-21, 12:57:30] Applied filter "Move remaining mail to subscriptions" to message from "Someone" <a@b.c> - Message Title at 2021-01-21, 12:57:15 execution stopped

/* Logging of the duplication appears to start below */

[2021-01-21, 12:57:31] Applied filter "Move remaining mail to subscriptions" to message from - at 1970-01-01, 02:00:00 moved message id = to mailbox://nobody@Local%20Folders/Inbox/Subscriptions

[2021-01-21, 12:57:31] Applied filter "Move remaining mail to subscriptions" to message from - at 1970-01-01, 02:00:00 execution stopped

Comment 29

[roger]

I'm still seeing it on 78.6.1 under Windows 10.

Comment 30

[Stephen]

@roger Have you tried the workaround described here? It appears to work for me. I can see that occasionally this filter rule fires (from the filter log) and, importantly, no duplicate messages are produced.

By the way, I am not using a unified inbox.

Comment 31

[roger]

I probably tried it some years ago. Interestingly, it didn't happen this morning when I opened TB. Waiting messages were moved just as they should have been. But it's no real problem to me - I can live with it. Maybe somebody will fix it one day!

Comment 32

[roger]

Attachment: Screenshot showing effect. WIndows 10, TB 78.6.1, Unified folders

Comment 33

[roger]

Just to confirm, attached is a screen shot this morning. Note 5 spurious entries. The messages have been correctly moved. The spurious entries disappear on going to another folder then returning to inbox.

Comment 34

[Stephen]

@roger Interesting, in my case the spurious entries do not disappear. I have to manually delete the duplicate messages. At most a single duplicate message is produced having exactly the same title and date as the original (unlike your image). However, in the message filter log the duplicates are logged as having no title and a date of 01-01-1970 (see my log file snippet above).

Perhaps, we are seeing different but possibly related issues. Bug 519083 better describes the behaviour I am seeing.

Comment 35

[Wayne Mery (:wsmwk)]

Roger, Stephen, Najoll,
Still see this after updating to version 128?

Comment 36

[roger]

Yes, but slightly different. The message is copied to the destination but remains visible in the unified inbox, where it cannot be selected. Moving to another folder and back, the message disappears from the inbox.

Comment 37

[Stephen]

I have not seen this for a while but I sometimes get completely blank messages on Thunderbird 115. See below. I'm not sure if it is related. I've updated to 128 and will keep an eye out.

From - Tue Oct 08 18:37:35 2024
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Comment 38

[[:nickname]JN]

Today in Thunderbird 128.4.2esr I see a newly arrived message dated 1970. We will see about version 128.4.3esr.

Comment 39

[[:nickname]JN]

Today in Thunderbird 128.5.2esr an important message appeared without a title and with the date of 1970. That caused me, for a while, to ignore that important email.

Comment 40

[Wayne Mery (:wsmwk)]

(In reply to [:nickname]JN from comment #39)

Today in Thunderbird 128.5.2esr an important message appeared without a title and with the date of 1970. That caused me, for a while, to ignore that important email.

Without a subject? In a unified folder?
Did you also check the underlying Inbox folder (not the unified folder)?

You'd need to attach/post the message headers.

Comment 41

[[:nickname]JN]

@wsmkw

Thanks Wayne, but the email at issue is long gone. If I see another such email, I will try to post the headers here. (I'm not seeing such emails - not quite - at the moment. Instead I am seeing what appear to be duplicate emails, with, admittedly, no subjects, but with accurate dates. Or at least I think that is what I have seen.)

Comment 42

[[:nickname]JN]

Just now I saw an email with no subject field, no recipient field, no sender field, and a 1970 date. When I opened it, it was blank. When I told Thunderbird to show all headers, the email was still blank. The email remained blank when I tried to forward it.

When I moved away from the inbox and back again, the email had disappeared - or, perhaps, become a duplicate of a functioning, and correctly dated, email. For, now, the inbox did contain a duplicate. The inbox is a 'unified one'; the email in question was from gmail; in the inbox specific to gmail there was a single email (no duplicates and indeed only a single email in total). I attach, with some redaction, the headers of that email - headers extract from the single email within the gmail inbox.

PS: the Posteo email address that is bound up with this bug report is a one that I deleted long ago.

Comment 43

[[:nickname]JN]

Attachment: Headers.txt