Inbound Parse: All attachments have Content-Type: text/plain

[garydevenay]

Issue Summary

When receiving an attachment via Inbound Parse and using the helper, the content type of all attachments are text/plain. I have tested this with .zip and .jpg files.

I would expect these to be application/zip (or at least application/octet-stream) and image/jpg

Steps to Reproduce

1. Send email to your inbound address
2. Use the below code to spit out the content types of attachments.

Code Snippet

func HandleInbound(w http.ResponseWriter, r *http.Request) {
    parsed := inbound.Parse(r)
    for name, contents := range parsed.Attachments {
        contentType := http.DetectContentType(contents)
        fmt.Printf("%v has content type %v", name, contentType)
    }
}

Exception/Log

test.jpg has content type text/plain; charset=utf-8
test.zip has content type text/plain; charset=utf-8

Technical details:

• sendgrid-go version: v3.6.4
• go version: 1.15.1

[eshanholtz]

Hi @garydevenay

I noticed you're using http.DetectContentType(contents) to determine the content type, instead of reading the type parsed from the email by inbound.Parse. Is the content type parsed from the email using the inbound helper correct?

[garydevenay]

Hi @eshanholtz
Thanks for the reply. As I understand contents is a map[string][]byte containing the file contents with the filename as the key (Reference) Is there a separate property of ParsedEmail that contains the content type?

[eshanholtz]

Ah, my apologies. There is a ParsedEmail.Headers property that reads headers from the email, but the Content-Type header you would end up reading from there is multipart/mixed. I was able to recreate your issue using http.DetectContentType on our test email attachments. I think the best path forward here would be to extend the inbound module to give Attachments its own ParsedAttachment struct type, with its own Headers, Filename, and Content properties. The Headers property would be populated based on the data in the emailPart's Header property.

This issue has been added to our internal backlog to be prioritized. Pull requests and +1s on the issue summary will help it move up the backlog.

[garydevenay]

@eshanholtz Created a PR for the above solution.

[garydevenay]

Update on the above:
The solution above (including my amendments) still doesn't actually work with attachments. All attachments that come through inbound parse are corrupt.

I can't make any more progress on this as I'm unable to test Inbound Parse's requests on a non-production environment and the provided unit tests aren't a reflection of Inbound Parse's POST request.

This either needs to be looked at by a core member or Twilio/Sendgrid need to supply us with a valid method of testing this locally, but the service does not work as it stands.