You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So the part itself has a single Content-Type: message/delivery-status header, followed by a group of "per-message" headers, followed by a group (or more) of "per-recipient" headers, all of which ends up in the "body" of the part. So I grab the part, run MessageParser on the body, grab the headers, run it again on the body of the new message, and so on.
It all works swimmingly right up until the end: because Delivery Status Notifications generally don't contain a trailing newline, msg.headers() will contain the last header, but with HeaderValue::Empty. Now, this is admittedly a bit of an abuse of the parser, and headers do normally contain a trailing CLRF, but I feel like if the message from the parser's perspective appears to end inside of a header value, the more expected behaviour would be to return what it has as the value.
I'm using
mail_parser
to parse an email containing a Delivery Status Notification. They come in a message part that looks something like this:So the part itself has a single
Content-Type: message/delivery-status
header, followed by a group of "per-message" headers, followed by a group (or more) of "per-recipient" headers, all of which ends up in the "body" of the part. So I grab the part, runMessageParser
on the body, grab the headers, run it again on the body of the new message, and so on.It all works swimmingly right up until the end: because Delivery Status Notifications generally don't contain a trailing newline,
msg.headers()
will contain the last header, but withHeaderValue::Empty
. Now, this is admittedly a bit of an abuse of the parser, and headers do normally contain a trailing CLRF, but I feel like if the message from the parser's perspective appears to end inside of a header value, the more expected behaviour would be to return what it has as the value.Here's a test to reproduce this:
With the
pretty_assertions::assert_eq!
macro, this produces:The text was updated successfully, but these errors were encountered: