Skip parts that contain errors and log them, instead of returning an
error immediately, thereby giving up on the entire message.
Found in a message with a part containing an invalid Content-Disposition
header that contained a space in the (unquoted) filename parameter.
(Known not to pass the TestMessageInfoHandledError/hexa test for now.
It needs to be rewritten if we want this new behaviour.)
Signed-off-by: Maarten Aertsen <maarten@nlnetlabs.nl>
---
lib/rfc822/message.go | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/rfc822/message.go b/lib/rfc822/message.go
index 653cb2fe..44b68ab2 100644
--- a/lib/rfc822/message.go+++ b/lib/rfc822/message.go
@@ -123,7 +123,8 @@ func ParseEntityStructure(e *message.Entity) (*models.BodyStructure, error) {
}
ps, err := ParseEntityStructure(part)
if err != nil {
- return nil, fmt.Errorf("could not parse child entity structure: %w", err)+ log.Errorf("could not parse child entity structure: %w, skipping part", err)+ continue }
body.Parts = append(body.Parts, ps)
}
Hi Maarten -
Do you have an example message that I could try this out with? I looked through
the callstack for how this can error, and I suspect you were getting an
Unfortunately, I cannot share the full message, but I filed
https://github.com/emersion/go-message/issues/184 with the details you
are after. tl;dr illegal space in the filename param:
Content-Disposition: inline; filename=Concur _1_.png
ErrInvalidMediaParameter ("mime: invalid media parameter"). If we get this
error, we still get a valid content-disposition. I think we should check for
this specific error, log it, and add the part. Probably for any other error
(which only comes from an actually invalid Content-Disposition) should still
throw an error. There are only two valid values: inline or attachment, so I
doubt this is getting messed up from other clients.
Per above, there's the parameters to mess up too :-)
kind regards, Maarten
From the go-stdlib:
// ParseMediaType parses a media type value and any optional
// parameters, per RFC 1521. Media types are the values in
// Content-Type and Content-Disposition headers (RFC 2183).
// On success, ParseMediaType returns the media type converted
// to lowercase and trimmed of white space and a non-nil map.
// If there is an error parsing the optional parameter,
// the media type will be returned along with the error
// ErrInvalidMediaParameter.
// The returned map, params, maps from the lowercase
// attribute to the attribute value with its case preserved.