i am passing =?utf-8?q?=C3=A4_space?= <[email protected]> to mailparse::addrparse but it doesn't parse me out the "ä space" display name. The displayname is valid RFC2047-encoding as far as i can tell. See https://tools.ietf.org/html/rfc2047#section-8 for examples that mirror what i am trying to do.

e.g.,

"X-IncomingHeaderCount: 10\r\n"

would be parsed to

MailHeader {
            key: "X-IncomingHeaderCount",
            value: "10\r",
}

I'd love to be able to use this library to parse, modify headers, and send onward messages.

Would you be open to a PR that adds get_value_raw() -> &[u8] to MailHeader ? I think that's sufficient for my case.

Reading the source, this naming makes sense — encoded meaning "as sent", raw meaning "before character set changes"; without looking at the source, I find it a bit inscrutable. I've matched the naming of get_body_encoded() when implementing get_heades_encoded() as mentioned in #75.

It might be worth clarifying some of this naming if there's a major version bump, but I hope this is acceptable as it is for now.

When the body is encoded in base64, the get_body_raw() method decodes it before it is the returned. Is there a way to get the untouched body instead? I need to forward to another system an attachment encoded in base64, at the moment the only way to achieve it is to call the get_body_raw() and then encode the result in base64; anyway, both the decode and the following encode actions are expensive and completely useless.

Hi!

I've got "Unexpected newline in header key" on several emails from my mailbox. I did a little research and have found "\r\nContent-Type..." input to parse_header func. There's a really dirty workaround, but it works:

pub fn parse_header(raw_data1: &[u8]) -> Result<(MailHeader, usize), MailParseError> {
    let mut index = 0;
    while raw_data1[index] == 13 || raw_data1[index] == 10 {
        index += 1;
    }

    let raw_data = &raw_data1[index..];

    let mut it = raw_data.iter();
// ...
                key: &raw_data[0..v],
                value: &raw_data[ix_value_start..ix_value_end],
            },
                ix + index))
        }

How to fix it correctly?

Doing

pathes.iter()
    .map(|path| {
        let mut buf;
        File.open(path).read_to_end(&mut buf);
        parse_mail(&buf)
    })

is not possible because the lifetime of the result of parse_mail() requires the buf to outlife the function.

Can we have an interface which does not require this, please? It is really hard to use this crate otherwise.

See https://tools.ietf.org/html/rfc2045, https://tools.ietf.org/html/rfc2045 and https://tools.ietf.org/html/rfc6266#appendix-C.

Ideally the full grammar should be obeyed, rejecting control characters too.

With the parts iterator (#108) we can now iterate over subparts of a parsed mail. But there is a problem with multipart/encrypted and multipart/signed parts: indeed, once decrypted (or verified), an encrypted (or signed) part can contain new subparts that are missed by the iterator. It could be really nice to pass a "decrypter", this way every time the iterator meets an encrypted or signed part it pushes new subparts to itself. At the same time I find this option a bit out of the scope of your library (maybe I am wrong?).

I tried to wrap your iterator with a custom one but I have big issues with ownership (indeed, I cannot mailparse::parse_mail on the fly, data does not live long enough).

How would you fix this issue?

Hello,

The comment over the get_value function says that the parser should get rid of the extra whitespace introduced by MIME for multiline headers. However I think there is a problem in the implementation. Parsing around 2000 mails with this nice library made me find this problem when using multiline UTF-8 subject:

extern crate mailparse;

use mailparse::parse_header;


fn main() {
    let raw = b"Subject: =?utf-8?q?this_is_?=\n\t=?utf-8?q?a_test?=";
    let (parsed, _) = parse_header(raw).unwrap();

    let key = parsed.get_key().unwrap();
    let value = parsed.get_value().unwrap();

    println!("{}: {}", key, value);

    assert_eq!(key, "Subject");
    assert_eq!(value, "this is a test");
}

And the output is:

Subject: this is  a test
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"this is  a test"`,
 right: `"this is a test"`', src/main.rs:16:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

An extra whitespace is added, where it should not.

I can propose patch if you indicate me what to change. I am not very familiar with the RFC but I think this is a bug because a lot of mails I parse have this extra-whitespace problem in subjects.

While using your (great) lib, I had the need to iterate over parts and I came up with a PartsIterator. I thought you could be interested in it and potentially add it to your lib (it must be a common case to iterate over parts). Let me know!