哪些电子邮件标头字段可以有参数？答案

【问题标题】：What email header fields can have parameters?哪些电子邮件标头字段可以有参数？
【发布时间】：2011-11-12 22:04:09
【问题描述】：

我正在尝试找出我可以在电子邮件解析库中拥有哪些通用子例程。

我知道两个经常带参数的 MIME 字段：

Content-Type: application/x-stuff;
 title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

（来自https://www.rfc-editor.org/rfc/rfc2231的示例）

和

Content-Disposition: attachment; filename=genome.jpeg;
 modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

（来自https://www.rfc-editor.org/rfc/rfc2183的示例）

它们是唯一的吗 - 还是这是一种通用机制？ https://www.rfc-editor.org/rfc/rfc822 只讨论“结构化”字段 - 上面的字段肯定是“结构化”，但 rfc822 中的示例是关于地址字段 - 这是一个不同的结构 - list 地址。

【问题讨论】：

您的术语不是很准确。据我所知，Field: value-type/subtype; type-specific-attribute=something 外观没有其他常用的标题，但不清楚这是否是您所追求的。请说清楚。在这种情况下，“参数”对您意味着什么？你需要什么答案？
在帖子开头添加了一句话说明。广告“参数”——这是 RFC 2231 所讨论的——部分问题在于它的真正含义。

标签： email mime email-headers

【解决方案1】：

Received: 标头通常是结构化的，尽管规范相当模糊，并且没有认真的标准化工作。最接近事实标准的是 Sendmail，Postfix 或多或少地模仿了它。 DKIM 签名以相当巧妙的方式结构化。 SpamAssassin 插入的 ad hoc 标头具有结构；它告诉您为什么邮件被归类为垃圾邮件。还有更多，但这应该给你一些开始咀嚼的东西。此处的示例均未使用 Mime Content-xxx 语法。

【讨论】：

The received: header field 是在 RFC 2882 中标准化，但相当松散。
呃呃，又来了，你是说RFC5382的3.6.7节吗？ 2882 是关于 RADIUS 身份验证的。
我的意思是 RFC 28*2*2，“Internet 消息格式”，第 3.6.7 节，抱歉。没有第 3.6.7 节的 RFC 5382，“TCP 的 NAT 行为要求”是什么意思？ :)
哦，好吧，我看到较新的 RFC 5322 进一步放宽了“Received:”的语法。我们甚至不再需要键/值对。不过，分号和时间戳必须到位。
这么多通过 RFC 号码进行通信（-：是的，我的意思是“当然”是 5322 ...应该意识到你的意思是 2822，显然，对此感到抱歉。

【解决方案2】：

据我所知，电子邮件中还有两个 MIME 字段：

MIME-Version: 1.0

没有参数，并且

Content-Transfer-Encoding: ...

也没有。

没有通用的“MIME头域参数规则”，只需要查找每个头域的标准定义即可。

（编辑：）在您添加到原始问题之后，您当然可以使用通用子例程。请注意，电子邮件标头解析是一项非常重要的任务（参见 RFC 2822）。我想到了这些通用子程序：

删除标头字段中的 cmets（用括号表示）。
处理制表符缩进行（续行）
解析 RFC822 日期/时间（巨大的任务:)
处理报价
解析电子邮件地址（不同形式）
处理字符编码（MIME 标头编码）

然而，这一切当然存在于许多开源库中。

【讨论】：

感谢您的回答。我会看看其他人怎么说 - 但现在我将更改标题:)
当然我正在使用一个库（Perl 中的 Courriel）——对于我们收到的其中一个电子邮件案例，它只是失败了，我现在正在尝试编写一个智能错误报告/补丁 :)