Improvements to filters to help finding huge emails

[Byron]

When receiving emails with attachments, the mailbox may get bloated.

Especially in conjunction with eventually deleting emails as in #16 , it would be useful to add filters specific to the size of an email.

Possible filters

Items marked with MVP seem desirable to have in the first incarnation.

• min size in Kb (MVP)
  • a slider to filter emails smaller than the minimum size.
  • Probably '0' as value would mean the filter is disabled, but there might be better ways to indicate this from a UX perspective.
• attachment
  • a checkbox to require emails to have an attachment
  • file extension multi-selection
    • Lists all actually used extensions and allows to focus on emails which have at least one of them.

Possible GUI Improvements

Extended statistics about displayed emails

Along with knowing how many emails are currently displayed, it would certainly be useful how much storage space they require. Maybe this information could be added to the top of the GUI.

Real-time updates when changing the filter

This would allow to remove the 'apply' button and would probably make it fun to play with sliders. It might also be an interesting exercise in async programming to make it deal with possibly longer filtering times gracefully. If filtering through 650k emails gets sluggish, one might consider throwing multiple threads into the mix.

[terhechte]

Hey, thanks for the feedback. I agree that having a size filter would be useful. Initially I wanted to collect attachment information during the mail parsing (e.g. amount of attachments, maybe even file type) but this led to a slowdown in email parsing. So I wonder if just having the size of the email (which would be very fast) is enough, or if it is useful to also scan detailed attachment information (maybe as an optional setting?). It certainly would be nice to be able to see all emails containing PDF files > 2 MB.

[Byron]

Great to hear!

So I wonder if just having the size of the email (which would be very fast) is enough […]

This looks like an MVP to me, it's fast, it's easy to implement, and it's a first step in this direction.

I wonder if it would be fast to learn about 'attachments - yes or no' instead of parsing them in detail. That would certainly help to differentiate huge emails with swaths of texts and those who have a big attachment.

Personally I wouldn't worry too much about parsing speed as it's already fast enough seemingly (except for the initial silence where it seems to extract an archive), and there seem to be some opportunities for improvements as well.

[terhechte]

Awesome, this sounds like a good initial approach. Once the app implements its own imap client (via imap) this can be accomplished with two imap queries:

• The size of the message in total (FETCH NNN RFC822.SIZE)
• The list of attachment filenames and content types (not their individual sizes though)

[Byron]

That's an interesting proposition. To me postsack is a batch processor with the performance benefits that go with it. imap seemed to be useful for features like the eventual deletion of emails, and querying information mail-by-mail seems too slow to be used in a filter.

Maybe I misunderstood and imap would be another avenue for the importer to extract mail information though.