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.
Dearest Reviewer,
Issue stalwartlabs#90 brought up the issue that if there was no newline. the user
provided an easy reproduction case. I was able to track it down to the
parse raw function.
The issue is that the loop hits the end of the string and returns Empty.
However, if there is a start offset then some characters were found. This
code just checks the offset after the loop.
If this is not the correct behavior please close.
Thanks for your time
Becker
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: