I've come across a number of emails where the subject, which contains encoded words, was modified by the recipients' mail server such that the final subject became something like:

[SUSPECTED SPAM]=?utf-8?B?VGhpcyBpcyB0aGUgb3JpZ2luYWwgc3ViamVjdA==?=

I understand this does not get decoded as it is missing a space before the encoded word as required in the spec

Ordinary ASCII text and 'encoded-word's may appear together in the same header field. However, an 'encoded-word' that appears in a header field defined as '*text' MUST be separated from any adjacent 'encoded-word' or 'text' by 'linear-white-space'.

Would it be possible to add support for parsing these types of malformed fields, seeing as mail servers which do this are relatively common?

I would like to be able to get MessagePart::Message as something like an u8 slice. My use case is: save the attached message with the orignal file name as an eml file. Actually I can only get the parts of the attached message.

Thanks!

I am attempting to use this library to create a new message, but I want to keep all the existing headers in the same order they were present in the original message so that things like Received headers don't move around compared to the rest of the headers.

Is this a use case that was considered for this library?

I am not sure the best way to build it since right now it means iterating over all of the RawHeaders and sorting them by their offsets.

The API guidelines recommend avoiding get_() prefixes:

https://rust-lang.github.io/api-guidelines/naming.html#getter-names-follow-rust-convention-c-getter

These seem to be very common in the mail-parser API, and it sticks out as a little unidiomatic. Maybe consider renaming?

Hi guys,

Great little library!! But...

This example:

use mail_parser::Message;

const INPUT: &[u8; 314] = br#"From: <[email protected]>
Subject: Redacted
To: <[email protected]>
Message-ID: <[email protected]>
MIME-version: 1.0
Content-Type: text/html;
 charset=utf-8
Content-Disposition: =?utf-8?Q?invalid?=
Content-Transfer-Encoding: quoted-printable
Content-Disposition: =?utf-8?Q?invalid?=

<p>foo</p>"#;

fn main() {
    let message = Message::parse(INPUT);
    dbg!(message);
}

Will panic with this message:

thread 'main' panicked at 'HeaderValue::get_content_type called on non-ContentType value', /home/arif/.cargo/registry/src/github.com-1ecc6299db9ec823/mail-parser-0.4.4/src/lib.rs:693:18

despite Message::parse advertising it never will; and that it does a best effort.

Could we have a look into it? Thanks!

I'm trying to sort a list of emails by datetime, and it appears the DateTime struct doesn't allow this -- what do you think the best solution is for this?

The library is great, thanks for putting it together! I was wondering if there are plans to have a parser for reading&parsing files in mbox format?

I noticed that in your most recent release (0.3.1) you added a variant of Messagepart: Multipart and I was wondering how I should handle this when rendering attachments. Is there a test case for this?

Hello, I have an issue with MHTML parsing from snapshots taken with the Chrome API.

Given the following file found here:

https://gist.github.com/quesurifn/f6d5c7068a916b9f46927a01fd87ed36

When iterating through attachments and parsing each one, the first attachment to be passed through to for_each is the css. E.g.

"sM5MNb" aria-live=3D"polite" class=3D"SaJ9Qe"></div></div></body></html>
------MultipartBoundary--iWpBqfSwVqslpqB6usfCGkX1ZOR2Vavef3mICKj83Y----
Content-Type: text/css
Content-Transfer-Encoding: quoted-printable
Content-Location: cid:[email protected]

@charset "utf-8";

html, body, h1, input, select { font-family: arial, sans-serif; }

body, h1 { font-size: 14px; }

h1 { font-weight: normal; margin: 0px; padding: 0px; }

h3 { font-weight: normal; margin: 0px; padding: 0px; font-size: 20px; line-=
height: 1.3; }

body { margin: 0px; background: rgb(255, 255, 255); color: rgb(32, 33, 36);=
 }

Given the following code:

   let path = fs::canonicalize(Path::new("./src/file.txt")).unwrap();
   let foo = fs::read_to_string(path).unwrap_or_default();
   let message = Message::parse(foo.as_bytes()).unwrap();
   let mut body = message.get_html_body(0).unwrap_or_default();
   message.get_html_bodies().for_each(|f| {
       let id = f.get_content_id().unwrap();
       println!("{}", id)
   });
   message.parts.iter().for_each(|f| {
      >>> let m  = f.parse_message().unwrap(); <--- Panics here
       let id = m.get_content_id().unwrap();
       println!("{}", id)
   });

With the following stack trace:

thread 'main' panicked at 'Expected message part.', /Users/kylefahey/.cargo/registry/src/github.com-1ecc6299db9ec823/mail-parser-0.4.8/src/lib.rs:436:18
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:616:12
   1: mail_parser::MessagePart::parse_message
             at /Users/kylefahey/.cargo/registry/src/github.com-1ecc6299db9ec823/mail-parser-0.4.8/src/lib.rs:436:18
   2: sandbox::main::{{closure}}
             at ./src/main.rs:17:18
   3: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::for_each
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/slice/iter/macros.rs:211:21
   4: sandbox::main
             at ./src/main.rs:16:5
   5: core::ops::function::FnOnce::call_once
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:248:5

I would gladly accept a performance penalty in exchange for not using unsafe code. If there were a feature on this crate to allow that tradeoff, I would use it. As it stands, I cannot use this library because of the use of unsafe.

It seems that my previous patch was not totally correct (for example, it does not work with DecodeResult::Borrowed). So I have rewritten it to to use only stream.pos and state.mime_boundary.as_ref(). But I am not totally satisfied yet: the specific problem is when there is a RFC822 message contained in an RFC5322 message, mail-parser wrongly include the MIME delimiter from the parent in the child, RFC822 email. I want to fix it and validate all this logic on your test emails.

Retrospectively, I am not sure that offset_last_part is really needed, but having a body_raw in Part is required: an IMAP server must not decode content and return its raw size, not its decoded size.

Also, I am a bit worried with my new fields: it might break your tests, so we need to check that and maybe update them. I will not be available in the next weeks but hope to finish this work until the end of the summer.

In the end, I think you should take into account this information if you want to make a release during this time: my previous PR might not be that great. If you really need to make a release, I would recommend that you rollback it.

Sorry, I thought that the problem might be easier to address.

First of all, thanks a lot for this library and the great amount of work that went into it🙏🏻

As far as i can tell images that are appended as inline attachments are not automatically inlined in the resulting body HTML string.

For example, this element is in an email by Confluence:

<img style=3D"vertical-align: top; display: block;" src=3D"cid:page-icon" alt=3D"page icon" title=3D="page icon" height=3D"16" width=3D"16" border=3D"0">

This references an attachment, page-icon, by Content-ID which is appended later in the email body:

------=_Part_565_1697167297.1654852801463
Content-Type: image/png; name=page-icon.png
Content-Transfer-Encoding: base64
Content-ID: <page-icon>
Content-Disposition: inline; filename=page-icon.png

iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAAPFBMVEX///+1tbWwsLCtra3////5
+fmLi4vZ2dnT09P8/PzPz8+rq6uhoaHR0dFycnJwcHB6enp4eHiDg4OAgIBog/vRAAAADnRSTlMA
IiJV3e7u7u7u7u7u7rDOyYEAAABUSURBVHhepcpLDoAwCABRqkBbP9Dq/e9qLYS1ibN8GQBYWFVG
fQWLWyFEJG0uknGmuz+CDnjYEzDqDpF8BrV+HBRHNThjyBP42qpBufmFxOIpJ3gAPTUGaYiilrsA
AAAASUVORK5CYII=
------=_Part_565_1697167297.1654852801463

Now when i get the HTML body of the email like this:

message.get_html_body(0).unwrap()

...the image source still says cid:page-icon. Is there a way to automatically inline those attachments? Or is this something that should be handled by the user?

Other libraries, such as the Nodemailer mailparser do this automatically.