staktrace / maildir

A simple library to deal with maildir folders

maildir

A simple library to deal with maildir folders

API

The primary entry point for this library is the Maildir structure, which can be created from a path, like so:

    let maildir = Maildir::from("path/to/maildir");

The Maildir structure then has functions that can be used to access and modify mail files.

Documentation

See the rustdoc at docs.rs.

Support maildir

If you want to support development of maildir, please do so by donating your money, time, and/or energy to fighting climate change. A quick and easy way is to send a donation to Replant.ca Environmental, where every dollar gets a tree planted!

maildir's Issues

Tests are not concurrency-safe

The tests seem to be written in a way that makes them fail nondeterministically if they are run with cargo test without any special options (i.e., in parallel), which seems to be corrobated by the environment settings in .travis.yml.

I'd like to fix that, and also that the tests are operating directly on the repo content, which is also unfortunate, I think. What I'd like to do is the following:

• Copy the testdata to a newly-created temporary directory
• Run the test on the copy
• Remove the contents of the copy

I read in #1 that you prefer being cautious about adding dependencies, but I guess that does not apply (so much) to adding dev-dependencies, right? I'd like to use pre-existing crates to avoid having reinvent the wheel in the test suite.

maildir write support?

hi,

would you be willing to implement/accept pull requests implementing basic write support, i.e. storing new messages to a maildir? probably that would mean some new dependencies for gathering system info/random for a unique filename as described e.g. at https://cr.yp.to/proto/maildir.html. on the other hand i would be willing to put work into that :)

Should not expose `nix::Error` in public API

I just wanted to send a pull request to update the nix dependency to 0.16. While it compiled without any code changes, I noticed this would be a breaking change, as the nix::Error is exposed via the publicly-accessible MaildirError::Nix variant, and via the From<nix::Error> trait impl for MaildirError.

I would hence propose to change MaildirError in a way that no longer exposes nix::Error as part of the public API; that might involve making it opaque, similar to std::io::Error, or by eliminating the MaildirError::Nix variant completely -- nix::Error has large overlap with std::io::Error, so it may make sense to just map it to io::Error.

What do you think?

Support listing mails by "info" flags

The Maildir Spec supports adding flags to the filename of the emails in the directory.

Quoting the page here:

info starting with "2,": Each character after the comma is an independent flag.

Flag "P" (passed): the user has resent/forwarded/bounced this message to someone else.
Flag "R" (replied): the user has replied to this message.
Flag "S" (seen): the user has viewed this message, though perhaps he didn't read all the way through it.
Flag "T" (trashed): the user has moved this message to the trash; the trash will be emptied by a later user action.
Flag "D" (draft): the user considers this message a draft; toggled at user discretion.
Flag "F" (flagged): user-defined flag; toggled at user discretion. 

New flags may be defined later. Flags must be stored in ASCII order: e.g., "2,FRS".

Would you be willing to accept code that provided a method for listing mails in a Maildir based on these flags?

Failed to resolve: could not find `unix` in `os`

It looks like the crate does not compile on Windows: https://github.com/soywod/himalaya/runs/5290902164?check_suite_focus=true. The issue comes from use std::os::unix::fs::MetadataExt;, which is obviously not available on Windows. Why not using std::fs::Metadata?

Memmap is unmaintained

Hi I just got erooster-mail/erooster#36 on my repo as memmap is unmaintained according to danburkert/memmap-rs#90

And this lib is pulling it in.
I was wondering if there is any chance that maildir could move to a maintained crate for the memmap feature :)

Repository should contain license text

It would be good to have the complete license text in the repository, mainly to make it extra clear what the chosen license is.

Update mailparse

Could you please make a release with the updated mailparse version?

Thanks

Bumping `mailparse` crate

Following staktrace/mailparse#108 (comment), is it possible to bump your version here also?

Reading a message requires a mutable reference

I'm trying to use maildir with skim to pick emails. However, I'm kind of stuck due to the fact that the method that reads headers requires a mutable reference.

The issue lies mostly in the context of converting a message into a string (e.g.: skim::SkimItem) I only have a non-mutable reference to the message. This makes sense; creating a text-based representation of an item does not need to mutate it.

I see the same applies for most methods that read a message: the require a mutable reference. I think the main issue lies in the fact that read_data() actually mutates the message. Probably returning the data (instead of assigning to self.data) should work.

Add cargo feature to make mailparse optional

Here the use case: I would like to use maildir to interact with a Maildir folder but I would like to use another crate than mailparse for parsing emails. Would you agree to add a cargo feature to achieve this aim? I can propose a PR. Thank you!

mailparse 0.11

Hello,

I would appreciate very much if you could update mailparse dependency to latest. This would help me in maintaining this crate in Fedora.

Thanks!

feature flag gethostname

Hi, I use maildir as a dependency for https://git.alexwennerberg.com/crabmail/ and I'm trying to minimize the dependency tree. I don't use the part of this library that uses gethostname (and therefore libc) -- is there any way you could feature flag this functionality so I don't require the dependency? I could put together a PR for this as well

Alex

Maildir++ folder feature

First of all, thanks for your great libs around emails. I'm already using mailparse, and now I'm using maildir for my project (a CLI email client). I try to build a common interface between different email backends like IMAP, POP, Maildir, Notmuch etc. I started with IMAP and Maildir, here what I've got so far:

pub trait BackendService<'a> {
    fn connect(&mut self) -> Result<()>;
    fn get_mboxes(&mut self) -> Result<Mboxes>;
    fn get_envelopes(&mut self, mbox: &str, filter: &str, sort: &str, page_size: usize, page: usize) -> Result<Envelopes>;
    fn add_msg(&mut self, mbox: &str, msg: &[u8], flags: &str) -> Result<String>;
    fn get_msg(&mut self, mbox: &str, id: &str) -> Result<Msg>;
    fn copy_msg(&mut self, mbox_source: &str, mbox_target: &str, id: &str) -> Result<()>;
    fn move_msg(&mut self, mbox_source: &str, mbox_target: &str, id: &str) -> Result<()>;
    fn del_msg(&mut self, mbox: &str, ids: &str) -> Result<()>;
    fn add_flags(&mut self, mbox: &str, ids: &str, flags: &str) -> Result<()>;
    fn set_flags(&mut self, mbox: &str, ids: &str, flags: &str) -> Result<()>;
    fn del_flags(&mut self, mbox: &str, ids: &str, flags: &str) -> Result<()>;
    fn disconnect(&mut self) -> Result<()>;
}

The 3 I have issue with are get_mboxes, copy_msg and move_msg, because they don't exist with Maildir. However, the Maildir++ extension allow the usage of other folders/mailboxes (if they start by a dot, like .Sent or .Draft). Can I propose a PR to support the folder feature of Maildir++?

RFD: Should this crate to offer mail parsing functionality?

In principle, the functionality in this library can be used with any crate that provides a parser for email messages; I thus wonder if it would make sense to discuss whether coupling this crate to mailparse makes sense; the Maildir format is only about the directory layout, and does not really dictate the message format; quoting from maildir(5):

The message is normally in RFC 822 format, starting with a Return-Path line and a Delivered-To line, but it could contain arbitrary binary data. It might not even end with a newline.

If implemented, this proposal would remove a few methods from MailEntry, and in return giving the crate a more clearly delineated scope of responsibility, and not imply users should use mailparse for dealing with message content.

API Questions: flags and store

Hi, I'm currently implementing an email synchronizer in rust and wanted to dump email that I fetch via IMAP into Maildir, for which I am using this crate (thanks for all your work on this btw!).

I've hit a few issues/questions though:

• I'd like to store emails that I download via IMAP in Maildir and keep track of their Maildir ID. Unfortunately neither Maildir::store_new nor Maildir::store_cur_with_flags support that (they don't return the message ID). Would you consider changing the APi to support that? This should be a relatively simple change in Maildir::store().
• Is there a particular reason why flags are handled as &str (beside obviously simplicity) and not as a enum?

P.S.: from another Rust newbie: I've found this crate pleasant to work with so far :)