多部分电子邮件中的"部分"是什么？

Question

一点背景......

前段时间,我在Python上编写了一个处理电子邮件消息的程序,总有一件事就是知道电子邮件是否是"多部分".

经过一些研究,我知道它与包含HTML或附件等的电子邮件有关......但我并不是真的理解它.

我对它的使用仅限于2个实例:

1.当我必须从原始电子邮件中保存附件时

我刚刚在互联网上发现了这一点(可能在这里 - 很抱歉没有记下编写它的人,但我似乎无法再找到他了:/)并将其粘贴在我的代码中

def downloadAttachments(emailMsg, pathToSaveFile):
    """
    Save Attachments to pathToSaveFile (Example: pathToSaveFile = "C:\\Program Files\\")
    """
    att_path_list = []
    for part in emailMsg.walk():
        # multipart are just containers, so we skip them
        if part.get_content_maintype() == 'multipart':
            continue

        # is this part an attachment ?
        if part.get('Content-Disposition') is None:
            continue

        filename = part.get_filename()

        att_path = os.path.join(pathToSaveFile, filename)

        #Check if its already there
        if not os.path.isfile(att_path) :
            # finally write the stuff
            fp = open(att_path, 'wb')
            fp.write(part.get_payload(decode=True))
            fp.close()
        att_path_list.append(att_path)
    return att_path_list

2.当我必须从原始电子邮件中获取文本时

也是互联网上的某人粘贴而没有真正了解它是如何工作的.

def get_text(emailMsg):
    """
    Output: body of the email (text content)
    """
    if emailMsg.is_multipart():
        return get_text(emailMsg.get_payload(0))
    else:
        return emailMsg.get_payload(None, True)

我明白了...

如果电子邮件消息是多部分,则可以迭代部分.

我的问题是

这些部分究竟是什么？你怎么知道哪个是html例如？或者哪一个是附件？还是只是身体？

Answer 1

对于如何使用多部分消息没有严格的层次结构或指导.MIME只是定义了将多个有效负载收集到单个电子邮件中的方法.我认为最初的动机之一是能够将图片嵌入文本中; 但是能够将二进制文件附加到文本消息中,并且更一般地,能够创建具有以任意方式相关的有效载荷的结构化消息,这是应用程序以他们认为合适的方式使用的简单方法.

一个常见的误解是将层次结构假定为"主要部分"和"从属"部分.创建这种结构当然是可能的,但绝不是普遍的.事实上,大多数多部分消息只有一系列没有任何层次结构的部分.用户的电子邮件客户端通常会选择"内联"部分中的一个作为首选的"主要"部分以显示在消息窗格中,但这绝不是由标准规定的,或者可能由发送方强制执行.

每个MIME部分都有一组标题,告诉你类型,编码和处理; 对于text/*默认处置类型的部分是"内联"(因此通常没有明确说明),而大多数其他部分具有默认处置"附件".您需要参考相关标准以获得严格的定义,但可能需要花费很多时间,因为许多实际应用程序并不特别符合RFC.

对于您的具体问题,找到最内部(隐式或显式)内联的叶部分,并显示一个支持您的用例作为"主"的叶部分.如果要将HTML强制为首选格式,则可以执行此操作; 但许多电子邮件应用程序将此推迟给用户决定,并且由于技术必要性,身体残疾或个人品味,一些用户肯定会更喜欢纯文本.

不幸的是,消息生产者常见的做法近期已经创建multipart/alternative容器text/plain和text/html成员,但随后提供了一个完全无用的text/plain部分,并具有在所有实际内容text/html的一部分.在这种情况下的正确安排是,text/plain如果你不能在其中放置任何有用的东西,那么根本就不提供一个部分(但我想他们只关心过去一些被误导的垃圾邮件过滤器,而不是实际上容纳收件人的偏好).