我正在编写一些代码来解析转发的电子邮件。我不确定是否有一些 Python 库、一些我可以坚持的 RFC 或一些其他资源，这些资源可以让我自动完成任务。
准确地说，我不知道转发电子邮件的“布局”是否包含在某些标准或建议中，或者它是否已经经过多年发展，所以现在大多数电子邮件客户端都会为文本部分生成类似的输出：
Begin forwarded message:
> From: Me <me@me.me>
> Date: January 30, 2010 18:26:33 PM GMT+02:00
> To: Other Me <other-me@me.me>
> Subject: Unwise question
- 并为附件疯狂（以及任何其他 MIME 部分可以在那里）。
如果它仍然不够精确，我会澄清它，只是我不是 100% 确定要问什么（RFC、Python lib、约定或其他）。
与许多其他人所说的不同，转发电子邮件有一个标准，RFC 2046，“多用途 Internet 邮件扩展 (MIME) 第二部分：媒体类型”，已有十多年的历史。特别参见其第 5.2 节，“消息媒体类型”。
RFC 2046 背后的基本思想是将一条消息封装到另一条消息的 MIME 部分，类型为（不幸的是）命名message/rfc822（永远不要忘记 MIME 是递归的）。Python的MIME 库可以很好地处理它。
我没有否决其他答案，因为它们在一个方面是正确的：并非每个邮寄者都遵循该标准。例如，mutt邮件程序可以转发 RFC 2046 格式的消息，也可以转发 adhoc 格式的消息。因此，在实践中，邮件程序可能不能只处理 RFC 2046，它还必须解析各种其他和未指定的语法。
正如其他答案已经表明的那样：没有标准，您的程序也不会完美无缺。
您可以查看标头，特别是User-Agent标头，以了解使用了哪种客户端，以及专门针对最常见客户端的代码。
要了解您应该考虑支持哪些客户，请查看此受欢迎程度研究。各种 Outlook、Yahoo!、Hotmail、Mail.app、iPhone 邮件、Gmail 和 Lotus Notes 排名很高。大约 11% 的邮件被归类为“无法检测到”，但使用转发电子邮件的标头可能会做得更好。请注意，统计数据是通过在电子邮件中放置图像来收集的，因此结果可能会出现偏差。
另一个问题是 HTML 邮件，它可能包含也可能不包含纯文本版本。我不确定客户在这方面的通常行为。
根据我的经验，几乎所有电子邮件客户端都以不同的方式转发/回复。通常，您在邮件包底部的 mime 中会有一个纯文本版本和一个 html 编码版本。邮件标头确实有 RFC ( http://www.faqs.org/rfcs/rfc2822.html "2822" )，但不幸的是邮件正文的内容超出了范围。
您不仅要应对邮件客户端的差异，还要应对用户偏好的差异。例如：Lotus Notes 将回复放在顶部，Thunderbird 将回复放在底部。因此，当 Thunderbird 用户回复 Lotus Notes 用户的回复时，他们可能会在顶部插入他们的回复，并在底部留下他们的签名。
另一个陷阱可能与回复链的自动换行竞争。
>>>> 超出限制的外部回复被
中间回复的邮件客户端自动换行\n
>> 中间回复的消息正文
> 上一个回复
最新回复
我不会解析消息并将其留给用户在他们的脑海中解析。或者，我会从另一个项目中借用代码。
回复/转发的标准是 > 在每一行前面加上邮件嵌套的次数，包括谁发送了初始电子邮件，这取决于客户进行整理。因此，您需要在 python 中做的只是将 > 添加到每一行的开头。
imap Test <imap@gazler.com> Wrote:
>
>twice
>imap Test wrote:
>> nested
>>
>> imap@gazler.com wrote:
>>> test
>>>
>>> --
>>> Message sent via AHEM.
>>>
>>
>
附件只需要附加到消息中，或者正如您所说的那样“疯狂”。
我不熟悉python，但相信代码是：
string = string.replace("\n","\n>")