为提升您的使用体验,本站正在维护,部分功能暂时无法使用。如果本站文章无法解决您的问题,您想要向社区提问的话,请到 Twitter 上的 @FirefoxSupport 或 Reddit 上的 /r/firefox 提问,我们的支持社区将会很快回复您的疑问。

搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

Content-Type: multipart/mixed

  • 1 个回答
  • 0 人有此问题
  • 10 次查看
  • 最后回复者为 Matt

more options

When redirecting (not forwarding) a message from the Zimbra server, I receive it without an attachment. I am attaching a screenshot of the message header. I don't know what could be the reason. Please help.

When redirecting (not forwarding) a message from the Zimbra server, I receive it without an attachment. I am attaching a screenshot of the message header. I don't know what could be the reason. Please help.
已附加屏幕截图

所有回复 (1)

more options

Zimbra or the original sender is sending malformed mail.

The transfer type is defined as application/octet-stream in the image. According to the Internet Assigned Numbers Authority (IANA), the group responsible for registering media types that is defined as follows;

(RFC 2045 and 2046 published November 1996, subtype last updated April November 1996)
The "octet-stream" subtype is used to indicate that a body contains
arbitrary binary data.  The set of currently defined parameters is:
 (1)   TYPE -- the general type or category of binary data.
      This is intended as information for the human recipient
      rather than for any automatic processing.
 (2)   PADDING -- the number of bits of padding that were
      appended to the bit-stream comprising the actual
      contents to produce the enclosed 8bit byte-oriented
      data.  This is useful for enclosing a bit-stream in a
      body when the total number of bits is not a multiple of
      8.
Both of these parameters are optional.
An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
has since been removed.  RFC 1341 also defined the use of a "NAME"
parameter which gave a suggested file name to be used if the data
were to be written to a file.  This has been deprecated in
anticipation of a separate Content-Disposition header field, to be
defined in a subsequent RFC.
The recommended action for an implementation that receives an
"application/octet-stream" entity is to simply offer to put the data
in a file, with any Content-Transfer-Encoding undone, or perhaps to
use it as input to a user-specified process.
To reduce the danger of transmitting rogue programs, it is strongly
recommended that implementations NOT implement a path-search
mechanism whereby an arbitrary program named in the Content-Type
parameter (e.g., an "interpreter=" parameter) is found and executed
using the message body as input.

See https://www.iana.org/assignments/media-types/application/octet-stream

A PDF file which this image claims the content based on the file name (something that has no relevance in this setting except to suggest a default when saving the file, it should be transmitted as application/pdf https://www.iana.org/assignments/media-types/application/pdf

I would expect the arbitrary binary date to not be forwarded at all beyond the initial receipt. It is an elevated risk of containing a virus of some sort as the file name suggested and content type are unrelated to one another.