我正在编写一个规范，基本上需要在电子邮件中的ASCII字符。 我记得电子邮件可以有一个外语编码的主题，但我不知道是什么编码被称为。 我不认为这个主题的编码和说UTF-8或UTF-16一样简单，因为其他的变化可能存在。 什么编码可以用于电子邮件主题行？
tcp_rfc1337设置似乎有一个TIME-WAIT暗杀的解决scheme。 第一个问题是旧的重复数据可能在新的连接中被错误地接受，导致发送的数据被破坏。 第二个问题是，由于旧的重复数据包进入新的连接，连接可能变得不同步并进入ACK循环，这将变得不同步。 第三个也是最后一个问题是旧的重复数据包可能会错误地input新build立的连接并终止新的连接。 从我所读到的问题来看，要解决这个问题，设置在套接字处于TIME-WAIT状态时忽略RST（重置）数据包 。 那么，为什么这个设置默认是启用的呢？ 使用这个有什么缺点？ 当我研究阻止SYN泛滥攻击时，我实际上已经了解了这个variables。 你认为这个设置有助于阻止它们吗？
似乎有很多SMTP的实现要么立即拒绝消息，要么接受其他消息，然后反弹消息。 在操作上，由于标题通常更复杂，所以接受比反弹要难一些。 有人会用某个接受而不是反弹，或者是一个立即反弹的架构呢？ 什么是错误思想的例子？ （例如，如果设置了唯一的发件人，接受比反弹可以检测到无效的电子邮件地址。VERP）
今天，我们有5家公司都使用谷歌的电子邮件服务 example1.com. 3w IN MX 10 mail.Google.com. example2.com. 3w IN MX 10 mail.Google.com. example3.com. 3w IN MX 10 mail.Google.com. example4.com. 3w IN MX 10 mail.Google.com. example5.com. 3w IN MX 10 mail.Google.com. 下周我们将使用另一个供应商（思科）。 我们可以指向MX中的A或CNAME吗？ example1.com. 3w IN MX 10 myCNAMEToCisco.example.com. example2.com. 3w IN MX 10 myCNAMEToCisco.example.com. example3.com. 3w IN MX 10 myCNAMEToCisco.example.com. example4.com. 3w IN MX […]
是否有为信封日记（或BCC日记）定义的正式标准？ 我是一名软件开发人员，并且希望确保我正确实施了日记function。 我的参考模型是Exchange 2010和2003，但我不知道这些格式有多普遍
所以我知道在SLAAC中有一些扩展可以通过RA来实现DNS发现（RFC 6106）。 但是最初的意图是什么？ IPv6devise人员如何设想在没有DNS的情况下工作？ 为什么多点传送DNS从Windows中被丢弃？ 我可以find关于SLAAC的大量信息，它缺less对DNS的支持，以及SLAAC / DHCPv6的争论（以及提议的但不受支持的扩展），但没有讨论原始的基本原理。
背景 – 标准 RFC 5321§4.5.5规定： 所有其他types的消息（即，标准跟踪RFC不要求具有空的反向path的任何消息）应该被发送有效的，非空的反向path。 为了避免疑问， RFC 2119§3将“ 应该 ”定义为“ 在特定情况下可能存在忽略特定项目的有效理由，但在select不同的课程之前，必须理解并仔细权衡全部含义 ”。 情况 正在考虑的“特定情况”是爱丽丝不希望收到送达状态通知（与她所发的电子邮件有关）的情况。 她有几个select： 忽略/丢弃任何这样的通知，当她收到它 – 明显这种行为是完全正确的，但这是一个滋扰（和她的资源浪费）; 拒绝在较低的级别接受这样的通知 –可以想象，反向path将不再是“有效的”（可悲的是，在RFC中没有定义），如果是的话，这样的行为是违背RFC的build议的; 要么 用一个空的反向path发起电子邮件，这样就不会首先产生通知 – 明显违背RFC的build议。 问题 我非常肯定，这些情况构成了忽视RFC引用的上述build议的“合理原因” – 但我想确定我已经理解了选项2和3的“全部含义”。 我特别注意到： 在选项2下，一些代理可能检测到反向path无效 在选项3下，一些代理可能会把特殊情况下的空path作为对待 无论哪种方式，代理可能因此拒绝接受/转发/发送电子邮件，或可能使用这些信息，以增加被标记为垃圾邮件的可能性。 这种措施在实践中有多普遍？ 我应该考虑其他问题吗？
查找SMTP错误代码时，有时会看到“550”或“5.5.0”。 有时虚线代码中的数字是不同的。 我find了RFC 821中定义的数字代码和RFC 3463中的虚线代码。 对于同样的事情，这只是不同的表示法，还是这些不同？ 如果它们不同，协议的哪些部分负责返回每个代码，以及为什么不同的代码？
我们所使用的两种不同的第三方电子邮件产品对电子邮件的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.. 一个电子邮件产品将其解释为embedded式图像。 另一个解释这是一个普通的附件（不embedded）。 如果我们完全删除Content-ID行，两个产品都认为附件没有embedded。 有没有一个特定的RFC明确地断定哪个行为是正确的？ 一位同事和我回顾了RFC2392，在开篇摘要中说： 在电子邮件中使用[MIME]传达网页及其内容 关联的图像需要一个URLscheme来允许HTML引用 到消息中包含的图像或其他数据。 Content-ID 统一资源定位符“cid：”用于此目的。 […]“cid”scheme是指消息的特定身体部分; 其使用通常仅限于在引用身体部位的相同消息中引用其他身体部位。 “中”scheme也可以通过包括内容ID的地址来引用指定消息内的特定身体部位。 所以，虽然不是绝对的，但是我们倾向于相信，因为所有embedded的项目都需要一个cid来引用它们，并且它“通常仅限于同一消息中的其他身体部分”，并且附件不需要cid作为“embedded意图”的指示符，电子邮件产品将cid的存在视为合理的行为。 我可以得到这个确认吗？
我一直在看RFC5424来查找正式指定的标记，这将结束syslog事件。 不幸的是我找不到它。 所以，如果我想实现一些小的系统日志服务器，对某些消息作出反应什么是结束消息的标记（是的，事件通常是一条线，但我只是无法在规范中find它） 澄清 ： 我把它称为事件，因为我把一条消息与一条线联系起来。 事件可能是一些事情 Type: foo Source: webservers 而给我的信息是这样的： Type: foo Source: webservers http://tools.ietf.org/html/rfc5424#section-6定义： SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG] STRUCTURED-DATA和MSG都不能告诉我这些字段是如何结束的。 特别是MSG被定义为MSG-ANY / MSG-UTF8 ，它几乎扩展到任何东西。 没有什么说一个换行标志着结束（或一个8或一个这个问题）。 给出示例消息（6.5节）： 这是一个有效的消息，或者2个有效的消息，取决于你说任何MSG元素中都不能出现HEADER元素： 文字空白 <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su – ID47 – <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su – ID47 | is this an end marker? \t代表一个标签 <34>1 2003-10-11T22:14:15.003Z […]