Content-Disposition is not parsing out the filename parameter

[LeeBear35]

I have an email with an attachment that has the following headers, and the Content-Disposition is not reporting the filename parameter:

Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=Partnership Marketing Agreement  
 Form - Mega Brands - Easter Toys - Week 11.pdf

The MimePart does have the header:

•   [2] {Content-Disposition: attachment; filename=Partnership Marketing Agreement   Form - Mega Brands - Easter Toys - Week 11.pdf}    MimeKit.Header
  

Let me know if you need any additional information.

[jstedfast]

The problem is that the sending client did not properly quote the value. Spaces are not allowed.

[jstedfast]

Looks like MimeKit already has a workaround for this. I've added a unit test and it passes.

[LeeBear35]

What is the workaround? I could not find anything in the ContentDisposition or the MimePart, so I when back to the MimePart Headers and Parsed the ContentDisposition header myself.

[jstedfast]

You don't need to do anything. It just parses it already.

Here's the unit test I added to verify it:

49607bf

[jstedfast]

n/m, it's failing for you because it has a newline in the middle of the value (which, again, is illegal...).

I've "fixed" it, but now your filename value will have a newline in it.

fc98384

You really need to complain LOUDLY to the authors of the software that is constructing that message to have them fix their bugs.

[LeeBear35]

I would love to complain LOUDLY to a lot of vendors that only get part of it right. You are right that because the header is so long it is getting wrapped, but not properly. I do not know the source email system the other headers in the email do not give any indication, the receiving system was Exchange, but there is also a library used to convert from MSG to EML, and that might have introduced the error.

The good thing is that we are migrating away from that library to a much better performing library "MimeKit" we just have to make sure our bases are covered for the few hundred million email that we deal with, and the exceptions like this.

I thought it was interesting when looking at the dump because the headers for the MimePart have a nice cleaned up header, but did not have the FileName set. I used the following, not sure it is the quickest way, but it should only get hit once every 100,000 emails.

        if (a is MimeKit.MimePart)
        {
          MimeKit.MimePart part = (MimeKit.MimePart)a;
          if (string.IsNullOrWhiteSpace(part.FileName))
          {
            foreach (MimeKit.Header h in a.Headers)
            {
              if (h.Id == MimeKit.HeaderId.ContentDisposition)
              {
                foreach (string parameter in h.Value.Split(new string[] { "; " }, StringSplitOptions.RemoveEmptyEntries))
                {
                  if (parameter.StartsWith("filename", StringComparison.InvariantCultureIgnoreCase))
                  {
                    char[] tempName = System.IO.Path.GetFileName(parameter.Substring(9)).ToCharArray();
                    string invalids = new string(System.IO.Path.GetInvalidFileNameChars());
                    for (int i = 0; i < tempName.Count(); i++)
                    {
                      if (invalids.IndexOf(tempName[i]) >= 0)
                      {
                        tempName[i] = '_';
                      }
                    }
                    part.FileName = new string(tempName);
                  }
                }
                break;
              }
            }
          }

Thank you again for a great library and support.

[jstedfast]

If you use the latest MimeKit from git master, you won't need to re-parse it anymore.

Filtering out invalid characters is still a good idea to do, though.

[LeeBear35]

I will have to try that in my other project this one is currently configured for the NuGet release.

[jstedfast]

What a royal pain in the ass it was to work around this brokenness :-\

[tbiggins]

But you did. Because you're awesome. ;-)
On Aug 11, 2015 6:00 PM, "Jeffrey Stedfast" [email protected]
wrote:

What a royal pain in the ass it was to fix this :-\

—
Reply to this email directly or view it on GitHub
#159 (comment).