Mailpile fails to apply tags (such as Inbox!) if an e-mail is in multiple mailboxes

[GregSutcliffe]

I've got Mailpile configured with a single account. As you'd expect, the sidebar lists my tags, followed by an folder for all mail in the account (i.e. named after the login address), which then contains the IMAP subfolders. All fine.

However, I'm noticing that some mail is skipping the proper Inbox tag, and is only visible in the account folder. I have no "skip inbox" filters that don't also apply another tag (i.e i have things like "list@[email protected] -inbox" and "in:data -inbox" but that's all), but the affected emails don't match the search part. I'm struggling to figure out a pattern to the affected mail though :(

Is there a known reason for this to be happening, or more debugging I can provide? Right now I "work around" the problem by regularly checking the account folder, but I'd like to not have to :)

Platform details: OS: Archlinux Version: Mailpile 1.0.0rc3 Running as a systemd service in /var, not in my homedir

[BjarniRunar]

I'm not sure what the cause would be here, except that it might have found messages in IMAP subfolders - those won't automatically end up in the Inbox. And to confuse matters further, Mailpile does duplicate suppression, so if it FIRST discovers a message in a subfolder, and then later discovers it again in the Inbox, it will ignore the second discovery.

Could that be what's going on?

Aside, regarding running via systemd in /var... I hope you're not running Mailpile as root. :-)

[GregSutcliffe]

Could that be what's going on?

I've just logged into the IMAP inbox itself, and the most recent example of a mail that had this issue is definitely in the IMAP inbox and not in any other folder. This is GMail though, so goodness knows if it's any unmarked labels...

I took a risk, and fired up Thunderbird (which does have filters enabled, so it took a while to filter all the mail since I switched to Mailpile :P), and again, Thunderbird can only find one copy of that email in the IMAP account. So no, it doesn't appear to be duplicated or in the wrong place.

Aside, regarding running via systemd in /var... I hope you're not running Mailpile as root. :-)

Please. It's running as an unprivileged user :). Main benefit is process detaching, syslog, and not filling up my homedir with GBs of mail :p

[BjarniRunar]

Very strange about the mail not appearing, this is the first such report I've had.

Hmmmm. Is your Mailpile configured to download from the "All Mail" pseudo-folder?

If it's downloading from both "All Mail" and "Inbox" and only "Inbox" is linked with the Mailpile Inbox, that could cause this, since messages will appear in both and it will become random which ones get the Inbox tag applied and which don't.

Did you let Mailpile configure the tags automatically, or did you do anything by hand? I'm starting to think this might be a problem to do with how Mailpile configures GMail IMAP by default.

(and regarding the root thing: :smile: :smile: :smile: )

[BjarniRunar]

I am realizing that this is definitely a problem triggered by how Mailpile configures GMail by default. Renaming issue to clarify.

I need to fix the tagging logic so duplicates don't get entirely suppressed, but get tagged with the union of all the tags that should have applied.

The workaround will be to disable downloads from All Mail, which will require some CLI magic. Copying from another issues, a rough workaround for this, looks like so:

• Use the CLI to set sources.ID1.mailbox.ID2.policy = ignore
  • Discover ID1 by using print -flat sources (find the GMail source)
  • Discover ID2 by using print -flat sources.ID1.mailbox (find the All Mail "mailbox")

Those CLI commands must be run either in the terminal, or in the web UI by clicking the CLI button on the Settings page. The Settings page is found by clicking the gearbox at the top right.

[GregSutcliffe]

That seems plausible, yes. I don't recall being given any option to choose which folders to sync when I added the account during initial setup - perhaps I missed it? I'll give those commands a try and monitor for a while - one cannot prove a negative conclusively, but if I don't seem any missed mails in a week or so, I think that would be sufficient proof ;)

[BjarniRunar]

I think this is going to be a two-stage fix; temporarily blacklisting the All Mail from default configs to mitigate, and then we can bring it back once the duplicates behave correctly.

[GregSutcliffe]

Setting successfully updated. I'll monitor and report back.

[GregSutcliffe]

For the record, I've not seen any further examples of this happening since the settings change, so I think you've nailed it :)

[AndrewDavis]

I have the same or a very similar issue, and this is an important problem for me in my usage of Mailpile.

I use a number of labels in GMail, some of them overlapping. Mailpile has downloaded all of my emails successfully, however it is not applying the labels correctly when I click on one of the tags in Mailpile. If I pull the GMail and Mailpile views up side by side, GMail has significantly more emails listed under some of the labels. It doesn't seem to have anything to do with which of the other labels are applied, the date of the emails, whether the emails have been read or not, etc. I don't see any patterns that would cause some of these emails to get tagged and others not.

I would really like to be able to trigger it to re-tag all of my emails so they're organized correctly. The reason this is important is because I would like to be able to do batch operations (like search or export) on some of the tags, etc. Mailpile's real feature in my opinion is not privacy or security but (visual!) backups and batch operations and such; this sort of thing should be prioritized.

Thanks