服务器 Gind.cn

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

Google Apps,SPF,softfail问题(使用validation工具进行validation,否则仍然不成功)

我想这可能是一个常见的问题和无聊的问题,但我真的很茫然,我不知道还有什么要做。 这可能是其他问题的重复,但没有解决scheme为我工作。 我search了几乎所有可以find的东西,但我仍然困惑,为什么它不工作。 我的问题的要点是,我已经为fintan.dk域名的客户设置了Google Apps。 除了从*@fintan.dk(通过Gmailnetworking界面或桌面客户端)发送到非Google Apps电子邮件的电子邮件发生软失败(我已发送到我的大学电子邮件,在MediaTemple上托pipe的电子邮件除外)甚至Hotmail)。 当发送到Google Apps或Gmail地址时,电子邮件会通过…(来自该域的所有电子邮件均通过电子邮件客户端发送)。 所以这就是我迄今为止所做的: 我已经添加了Google推荐的SPFlogging(v = spf1 include:_spf.google.com〜all),等了好几天,希望DNS更新延迟问题。 现在,三天之后,没有任何变化。 我已经多次validation了桌面客户端中的设置。 我使用validation工具(如SPF查询工具 [email protected][email protected])validation了logging。 他们都证实并通过了,说不应该有问题,但是还是有点奇怪。 所以,我真的不知道还有什么要做。 很感谢任何forms的帮助。 先谢谢你! – 以下是我从*@fintan.dk地址发送到非Google Apps / -Gmail地址的电子邮件标头,电子邮件地址为MediaTemple,邮箱地址为**@newzoo.no。 Delivered-To: ***@*** Received: by 10.204.113.141 with SMTP id a13cs215458bkq; Mon, 7 Jun 2010 14:27:23 -0700 (PDT) Received: by 10.204.83.228 with SMTP id g36mr347934bkl.133.1275946041770; Mon, 07 Jun 2010 14:27:21 […]

基于TCP的OpenVPN,可怕的延迟,但只在Win7 x64

我知道通过TCP封装TCP通常是一个可怕的想法,但是我可以处理偶尔出现的性能下降和MTU问题,TCP内部的雪球效应提供了错误控制在这两个层次上起作用的地方。 Windows 7 x64上的最新OpenVPN客户端存在可怕的延迟问题,在隧道内对主机进行ping操作会导致> 500ms的ping时间,并导致整体性能下降。 吞吐量看起来不错,它确实只是延迟。 但是,在同一台计算机上,Linux 64位上的OpenVPN客户端(Ubuntu 10.04,相同的OpenVPN版本,相同的OpenVPNconfiguration,没有不同的设置)运行完美。 〜30ms,一切都很实用。 在同一台交换机上,同样的OpenVPN客户端版本,相同的configuration文件,在Mac OS X 10.5(PowerPC)也完美地工作。 我无法解释这一点。 我已经尝试了各种各样的东西,例如将虚拟适配器的MTU值降低到1400(因为商业切换的可怕的文档提到这个不是在Windows上dynamic设置的,并且推荐这样的动作),我试过了在全球TCP设置中禁用ECN,烟囱和CTCP,开启和closuresLzo压缩,牺牲一只山羊,没有什么更好的。 有任何想法吗? 起初,我认为在Windows上OpenVPN的PMTU支持不足是造成这种情况的原因,但是我尝试了使用Windows XP,它的工作原理也是完美无缺的。 我从用户那里得到了报告,它也能在Windows 7 32位上完美地工作。 此外,文档似乎说,MTU设置对于TCP连接是毫无价值的,并且用于UDP。 tl;博士:TCP上的OpenVPN是慢的,但只有在Windows 7的64位,一切工作正常。 是什么赋予了? 非常感谢,如果有人能回答这个问题,我会永远欠我的睡眠债务。