Allow blank filenames in Content-Disposition field

[robinroestenburg]

Attachments containing an empty string as a filename in the Content-Disposition header are skipped.

This was introduced as a side-effect of commit b1b1796.

Take, for example, the following Content-Disposition header:

Content-Disposition: inline;
  filename=""

Prior to that commit the parameters in the ContentDispositionField class would return:

{"filename"=>"\"\""}

After the commit the following is returned:

{"filename"=>""}

This is correct, but the code returning the filename from the ContentDispositionField class checks on !blank?. Which would return true before, and now returns false.

This would result in Message#find_attachment not decoding the attachment because nil instead of "" is returned.

For this PR I made the ContentDispositionField#filename implementation match the one in ContentTypeField#filename.

[robinroestenburg]

Added some specs as well. I copied some specs from the ContentTypeField specs, as the implementation should be the same (imo).

Note:

• Content-Type allows empty filenames using filename=. This gets sanitize by the ContentTypeField#sanatize method. I believe this is incorrect, as values should always be quoted strings? These filenames are not not possible for the Content-Disposition header.
• The spec/mail/fields/content_type_field_spec.rb file contains the 'should locate an encoded name as a filename' spec. I did not add this to the specs for Content-Disposition, because in order to make it work I had to copy method_missing, stringify and parameters methods from the ContentTypeField class. I could do this in another PR.

[grosser]

empty filenames could create more problems down the line when for example trying to store things ...
imo find_attachment is incorrect anyway since it only looks for filename, I'm using this:

return filename if filename.present?
if self['Content-Disposition'].to_s.split(";").first == "attachment" ||
      (type && type.split("/").first != "text") ||
      type == 'text/calendar'
    )
  generated_attachment_name
end

[jimmysoho]

Empty filenames could create problems for mail consumers, but that is unfortunately not mail's concern, if the email says the filename is "" then that's what it is.

I do agree that the implementation of find_attachment is incorrect, we use code similar to yours. I think a separate pull request is needed to fix that up.

[grosser]

thx for merging/fixing all these issues @jeremy ! ❤️