服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

正确使用SMTP“发件人”标题?

当有人发布新内容时,我们的Web应用程序会向用户发送电子邮件 发件人和收件人都select从我们的应用程序接收电子邮件。 在准备这样的消息时,我们设置了以下SMTP头文件: FROM:[email protected] TO:[email protected] SENDER:[email protected] 我们select在FROM头中使用作者的电子邮件地址,试图为收件人提供最佳体验。 当他们在邮件客户端看到邮件时,作者很清楚。 为了避免欺骗的出现,我们添加了SENDER标头(使用我们自己的公司电子邮件地址),以明确表示我们是以作者的名义发送的。 阅读RFC 822和2822之后,这似乎是发件人标题的一个预期用途。 大多数接收邮件服务器似乎处理得很好; 电子邮件正常传送(假设收件人邮箱存在,未超过配额等)。 但是,当从一个域中的地址发送消息到同一个域中的一个地址时,一些接收域将拒绝这样的消息,其响应如下: 571不正确的IP – psmtp(回复RCPT TO命令) 我认为这意味着接收服务器只能看到FROM头域地址在它自己的域中,并且这个消息源自一个服务器,它不认为授权为那个域发送消息。 换句话说,接收服务器忽略了SENDER头。 我们有一个解决方法:webapp保留一个似乎忽略SENDER头的这样的域的列表,当FROM和TO头都在这样的域中时,它将FROM头设置为我们自己的电子邮件地址。 但是这个清单需要维护。 有没有更好的方法来达到预期的体验? 我们希望成为networking上的“好公民”,所有相关方(发件人和收件人)都希望参与并接收这些信息。 一种替代方法是始终在FROM标题中使用我们的公司电子邮件地址,并将作者的姓名/地址添加到主题中,但这看起来有点笨拙。

在VMWare快照中永久运行性能不佳?

我知道VMWare KB在长时间运行的快照上皱眉,主要是由于两件事(在我看来) 大量的快照可以填满数据存储。 快照只是增量文件。 比方说,你有一个50G的VMDK,几乎已经满了,你拍一张快照。 在你的快照中,你翻转每一个位。 您的增量文件也将是大约50 GB。 再次快照,翻转位,另一个50千兆增量文件。 这些可以快速失控。 提交大量快照会带来风险。 合并快照时,您正在将增量更改写入原始VMDK。 这需要时间,并带有风险,如果发生什么事情,你只是VMDK nucked。 他们的警告似乎是合乎逻辑的。 这就是说,从VMDK快照中永久运行我的机器本身是不好的? 我想让我的树如下: 基础 Snap1 快照2 你在这里 在安装和configuration基本系统后,将立即执行快照1和2。 这些是我打算频繁刷新的机器,所以我会简单地让我的树看起来像下面这样: 基础 Snap1 你在这里 快照2 删除Snap2并重新创buildSnap2。 我不明白这可能会有什么影响,原因如下: 由于我只是简单地安装了一个基本的图像,并在没有办法填充数据存储之后马上拿走了我的三angular洲。 假设我的基本映像只有10 GB(在50 GB精简置备的磁盘上),即使我的增量翻转每一位,最大总使用量可能是60 GB(10 GB基本VMDK已locking+ 50 GB增量快照VMDK文件)。 这假定我不创build任何进一步的快照。 由于我的使用案例不需要整合快照,所以我不会冒险整理我的错误。 当我移回Snap1并删除Snap2时,所有位于Snap2中的增量只会被​​删除。 存储负载是完全一样的,所以我应该得到相同的IOPS。 我知道一些文件(主要是系统文件)将存在于原始的VMDK上,而其他的文件(基础之后的所有文件)将存在于delta中,但是我不明白ESXI是如何处理的。 所有文件都在同一个物理数据存储上,所以性能应该等同于在没有快照的情况下引用原始VMDK中的所有内容。 有什么想法吗? ESXI 5.5与数据存储RAID'd DAS。 我没有vCenter许可证,所以模板和克隆不在桌面上。 结果的testing 我今天早些时候进行了一些testing。 结果如下。 有一个performance惩罚,但我不知道为什么。 快照之前: 快照后: