Questions tagged «rfc»

我们拥有两种不同的第三方电子邮件产品，它们对电子邮件的MIME源中存在content-id标头的反应不同。这导致我们试图解决的用户体验不一致。 这是一个例子： --boundary-example Content-Location: CID:somethingatelse Content-ID: <foo4atfoo1atbar.net> Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV wbGljYXRpb24gcHJvaGliaXRlZC4A etc.. 一种电子邮件产品将其解释为嵌入式图像。另一个将其解释为普通附件（未嵌入）。如果我们完全删除Content-ID行，则两种产品都认为附件未嵌入。 是否有特定的RFC明确地确定哪种行为是正确的？我和一位同事回顾了RFC2392，该文件在开篇摘要中说： 在电子邮件中使用[MIME]来传达网页及其 相关图像需要URL方案，以允许HTML引用 消息中包含的图像或其他数据。Content-ID 统一资源定位符“ cid：”用于该目的。[…]“ cid”方案是指消息的特定正文部分；它的使用通常仅限于在与引用正文部分相同的消息中引用其他正文部分。通过包括内容ID的地址，“中”方案还可以指代指定消息中的特定正文部分。 所以，虽然不是绝对的，我们倾向于认为，既然所有的嵌入式项目需要的CID引用他们，并且它是“一般仅限于相同的消息在身体其他部位，”和附件并不需要一个CID ，电子邮件产品将cid的存在作为“嵌入意图”的指示是合理的行为。 我可以得到确认吗？

11 email  mime  rfc 

在RFC 2822（定义电子邮件）中定义，任何行都不应超过78个字符（不包括CRLF）且不得超过998个字符。用带引号的可打印更长的行将分成更多的行，并以'='结尾，直到达到真正的换行符为止。如果邮件包含多于78个（或998个）字符的行，但已用quoted-printable编码，则使该邮件符合标准？ 有这样的说法，这是不合规的，因为接收方的邮件客户端在对带引号的可打印消息进行解码后具有更长的行。 编辑：按照大卫·卡里（David Cary）的要求来澄清问题：是的，我的意思是引号可打印的编码邮件应与引号可打印兼容，这意味着行数不能超过76个字符。但是，解码后的消息的行数可能会超过此限制。所以我的问题是：实施RFC 1521的客户端软件是否应该在解码带引号的可打印文本内容后处理无限长的行？到目前为止，两个答案都得到了肯定的回答（谢谢），但受​​到Netiquette（RFC 1855）的限制。但是Netiquette甚至将行长度限制为65个字符，几乎没有人遵守该限制。

9 email  rfc 

如果域及其名称服务器不共享TLD，则胶水记录通常不可用，并且如果它们不共享相同的二级域，则从技术上讲也不需要胶水记录，这可能导致解析域的额外步骤。解析程序必须先查找名称服务器的地址，然后才能找到您的域的地址。但是从理论上讲，您可以在其中添加更多步骤，而不仅仅是这两个步骤。 这里的问题是，该链条可以保留多长时间？ if xyz.com使用nameserver ns1.xyz.info， 并xyz.info使用nameserver ns1.xyz.co， 并xyz.co使用nameserver ns1.xyz.cc， 并xyz.cc使用nameserver ns1.xyz.co.uk，...依此类推 ...您可能最终需要很长的链来让解析程序解开，才能解析您最初想要的名称。 大概有一个实际的限制-BIND应该只愿意遍历这么多的链接，否则就有可能遭到拒绝服务。但是有官方限制吗？某些步骤是否正式不需要解析器进行？

8 domain-name-system  rfc 

我正在构建一个设备，该设备由通过设备内部的以太网连接的几个子设备组成。设备将连接到客户网络。客户网络可以使用私有IP地址。与内部网络的地址冲突将是一个问题（连接到两个网络的子设备将被混淆）。不能选择IPv6。 我应该购买IPv4地址吗？或者，也许我可以摆脱使用TEST-NET-3（203.0.113.0/24）之类的麻烦？最佳做法是什么？

8 networking  local-area-network  ip-address  ipv4  rfc