附件可以嵌套在MIME中吗? [英] Can attachments be in a nested multipart in MIME?

问题描述

我知道多部分电子邮件的每个部分本身都可以是多部分.附件是仅作为顶级部件添加，还是也可以嵌套在多层部件中?

I know that each part of a multipart email message can be a multipart itself. Are attachments added only as top-level parts, or can they be in a nested multipart as well?

例如，我的意思是，这里attachment1.doc是嵌套的，而attachment2.doc将是顶级部分.

For example of what I mean, here attachment1.doc is nested, while attachment2.doc would be a top-level part.

multipart/mixed
   |---Title: text/plain
   |---Text content: text/plain
   |---Nested multipart: multipart/mixed
   |      |--- attachment1.doc (BASE64)
   |---attachment2.doc (BASE64)

我之所以问是因为我在 https://stackoverflow.com/a/27556667/492336 中遇到了这段代码:

I'm asking because I encountered this code from https://stackoverflow.com/a/27556667/492336:

    # Iterate the different parts of the multipart message.
    for part in msg.walk():
        # Skip any nested multipart.
        if part.get_content_maintype() == 'multipart':
            continue

它是Python语言，它们遍历邮件的不同部分以搜索附件，但是跳过本身是多部分的任何部分.

It's in Python, and they iterate through the different parts of the message to search for attachments, but skip any part that is itself a multipart.

他们这样做正确吗?我尝试阅读 RFC3501 ，但是找不到任何明确的说明文件附件是否可以或不嵌套.

Are they correct to do that? I tried reading the RFC3501, but couldn't find anything definitive saying whether file attachments can be or not be nested.

推荐答案

没有限制的处方，并且很难为所有multipart类型的单一策略争辩-它们具有完全不同的目的.

There is no prescription for limitations, and you would be hard pressed to argue for a single policy for all multipart types -- they have quite distinct purposes.

例如，带有类似消息

multipart/mixed
  +-- multipart/alternative
  |     +-- text/plain
  |     +-- multipart/related
  |           +-- text/html
  |           +-- image/png
  |           +-- image/png
  +-- application/octet-stream; name="attachment.pdf"

...对于大多数想要提供消息HTML视图的客户端来说，理智的行为是在multipart/alternative中选择multipart/related及其所有附件，并在显示消息时使用它来显示消息. PDF作为单独的附件.如果仅处理顶级multipart/mixed，则您仅 会看到附件，这似乎不是理智的方法.

... the sane behavior for most clients which want to provide an HTML view of the message would be to pick the multipart/related inside multipart/alternative with all its attachments, and use that for displaying the message, while displaying the PDF as a separate attachment. If you only process the top-level multipart/mixed you only see the attachment, which doesn't seem like a sane approach.

另一种可能发生完全任意嵌套的情况是message/rfc822，其中附件消息是其自身的完整MIME消息，可能依次包含另一个message/rfc822等.

Another case where completely arbitrary nesting can occur is message/rfc822 where the attached message is a complete MIME message of its own, which might in turn contain another message/rfc822, etc recursively.

带有(显式或隐式)Content-Disposition: attachment的任何内容都是附件"；您有时确实会看到附件"，例如multipart/alternative这意味着附件仅在您显示消息的备用视图时才有意义-我很难提出一个例子，说明这是正确的，并且可能会推测应该将其视为错误，并在呈现其他替代方案时显示附件，以防万一.

Anything with an (explicit or implied) Content-Disposition: attachment is an "attachment"; you do sometimes see "attachments" inside e.g. multipart/alternative which would imply that the attachment only makes sense if you are displaying that alternative view of the message -- I am hard pressed to come up with an example where this would be true, and might actually speculate that it should be regarded as an error, and display the attachment when rendering another alternative, just in case.

这篇关于附件可以嵌套在MIME中吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！