从我的服务器交易电子邮件直接转到雅虎用户的垃圾邮件文件夹

我正在设置我们的网站门户网站,向注册用户发送注册确认电子邮件(包含确认用户电子邮件链接的简单消息)。

一切都很好,工作很好,@ gmail.com用户得到的电子邮件okey; 不过,对于@ yahoo.com用户,电子邮件直接进入垃圾邮件文件夹。

我需要补充的是,我已经花了4天的时间阅读每一个论坛发表的主题,并已经实现了每一个暗示和build议可能(注意:我不是新来的系统pipe理,所以我可以向你保证所花费的时间是挖掘而不是学习)。

总结:

  • 发送IP为64.34.222.102
  • 有一个适当的DNS和rDNS / PTR设置
  • 这个IP没有列在我在网上查过的100多个黑名单中
  • 该域有适当的MX条目设置(注意:传入的邮件服务器运行在不同的IP …这可能是一个问题?理论上它不应该)
  • 邮政局长和滥用地址已设置。
  • DomainKey被实现并validation工作
  • DKIM已经实施和validation工作
  • SPF正在实施和validation工作
  • 我们已经注册了Yahoo和Hotmail Loopback Feed程序
  • 这里是用户select的网站:www.teltub.com
  • 我已经填写了雅虎的批量发件人表格(它修复了这个问题3-4天,但它回来了 – 稍后再回来)
  • 由于我们正处于testing阶段,任何用户实际上都不可能将电子邮件标记为垃圾邮件(他们大多是朋友),而且电子邮件的性质不是营销/广告
  • 检查了从雅虎的SMTP回复,最初几天,它包括了一些暂时的延期,但在我填写表格并签署后,它就消失了。
  • testing了几个自动检查器,包括allaboutspam.com,都显得很好/绿色: http : //www.allaboutspam.com/email-server-test-report/? key=F53F072FADAFE74C8960182016769C56

我有三个问题是:

  1. 任何想法我错过了什么?
  2. 雅虎有人回答说:

    您正在使用的邮件服务器中的电子邮件最近由于其邮件的潜在问题而被优先化。

    这些去优先化是暂时的,但如果发送IPconfiguration文件仍然很差,可能会重新触发。 通常情况下,优先级降低由单个发件人或MAIL FROMconfiguration文件触发。

询问更多细节后,他们表示不能提供任何进一步的信息!

  1. 雅虎没有在电子邮件前面显示安全密钥…即使假设是垃圾邮件,它不应该显示源的真实性吗? 在另一个来自这个地址的邮件被标记为“不是垃圾邮件”的帐户,它显示的关键okey …

这是来自postfix的交付日志:

Oct 18 00:59:25 mgmt postfix/smtp[4321]: 063E0B988A6: to=<[email protected]>, relay=b.mx.mail.yahoo.com[74.6.136.65]:25, delay=1.6, delays=0.11/0.01/0.61/0.92, dsn=2.0.0, status=sent (250 ok dirdel) 

这里是雅虎的消息标题:

 From TELTUB Mon Oct 18 04:59:23 2010 X-Apparently-To: [email protected] via 98.136.167.26; Sun, 17 Oct 2010 21:59:25 -0700 Return-Path: <[email protected]> X-YahooFilteredBulk: 64.34.222.102 Received-SPF: pass (mta1015.mail.sk1.yahoo.com: domain of [email protected] designates 64.34.222.102 as permitted sender) X-YMailISG: HGiMWDwcZAr2nMseAcs8EMjEoTTXRB5jVgymRipvWi77dSrO PuvRZPjN1WbGfxHFAyLo99VgChGrTm8Ve_nCA4PLyzhfFKfcsQ8v9FlY3uHJ wt3y34DU2ZChx3ud4Scg1ReSSA8b3d3FY5YmWhQDeeckNZUbGYET0MVbjddu UX9Z6q3fsIfhsMhedk.6ZT3vsJHs8YiWGcAAiKgipdUnPYhQ36axREymHV8L EupzrPp6JE7PM4Ah12Cj8vw8sozDSUiShQM00sD0IC6HUqh4jDRpoISyur.G TbHTaa6rZKcNTtaKfE.BRZCJIBQA3oKvFtPt9QZFcDU98adBzlxK8oZxiOuQ txWdBWL4zveDo8yqH84sRB2jBLfR8Hig4mZ5bZrUMHnq9P.fNB.6z8XEZoMi UBO8eJsYf7Sxug9FtJr9.7.DIRcXshikZker0F0ygc1.ghJwEWLATbGA8UZg l2ekjauSWgt1XJQjr9JOpRWwgBTH4N6lXZLE5BQ8q38m6ZspaAZ3glRNSZLU YpnRNwRHHy8HLxryXONeR_Q5NcZivZZbof3r2SKvJjZ_DZF9wiuEnlSWng15 QUd5BAbnA0fSxlaAjS7ayr9HLq0khsSVdlSYeGQpU.3LU6iZt17x3hjZoCXJ kB2YBa9ZHH3LkJIezOnNooc9LiYzwnsm1_FaVmvGk1XZzDEsJaadXxtf39o_ wo2RQVHNaGbt9huEEy4fAiFx6_ZX3pNhepJLnJf2BgNLCi0ix0bw30EPxPPy 5IaL0vnBeF4S3ReZa2z5cex3apsUULu3vl2zG_HVtsCuvE8- X-Originating-IP: [64.34.222.102] Authentication-Results: mta1015.mail.sk1.yahoo.com from=teltub.com; domainkeys=pass (ok); from=teltub.com; dkim=pass (ok) Received: from 127.0.0.1 (HELO mgmt1.prod.teltub.com) (64.34.222.102) by mta1015.mail.sk1.yahoo.com with SMTP; Sun, 17 Oct 2010 21:59:25 -0700 Received: from www1.prod.teltub.com (localhost.localdomain [127.0.0.1]) by www1.prod.teltub.com (Postfix) with ESMTP id DF46118E81BB for <[email protected]>; Mon, 18 Oct 2010 00:59:23 -0400 (EDT) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 mgmt1.prod.teltub.com 063E0B988A6 DomainKey-Signature: a=rsa-sha1; s=teltubdk; d=teltub.com; c=simple; q=dns; b=PAHMrH/tt9jRbjOcmeaO6IgbiK+MUfgwP9NZtIMKYNva/ISbDkjUWhHlnbEP1Icji axsb+4Q2QrO8zIsT9tWZw== X-DKIM: Sendmail DKIM Filter v2.8.3 mgmt1.prod.teltub.com 063E0B988A6 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=teltub.com; s=teltubdkim; t=1287377964; bh=xiqqKdrY0J4R8qUgsW9WMXUKnak=; h=Content-Type:MIME-Version:Content-Transfer-Encoding:From:To: Subject:Message-Id:Date; b=q7FEBCnitX/Ohw0RXnjaEZPkXi+hOJHof+hbGarbyC0zWqTpXiknI2bC6k7+QigEH ZL4JjzA8WK1MZqSaE6oOjTc3yxy+Dj7niAiB4t5cI8GPvvtegLSO6d2yVTmGa5wDFV 5f4i5OpHnccPRHkEQ3ShKMzkjKMgVPkdaObAvMFA= Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "TELTUB" <[email protected]> To: [email protected] Subject: This is just a test Message-Id: <[email protected]> Date: Mon, 18 Oct 2010 00:59:23 -0400 (EDT) Content-Length: 111 

仅供参考,我find了答案! 问题在于DKIM签名仍处于testing模式(DNS条目中的't = y')。 我用一个新的IP重新整理了所有东西,并得到了相同的结果。 但是注意到我使用的DKIM签名生成工具在签名中间留下了't = y'。 请注意,我之前从政策条目中删除了t = y,但这并没有办法:

teltubdkim._domainkey IN TXT “V = DKIM1; G = *; K = RSA; 吨= Y; P = MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtMbAffP / NxX4JcglM + 1G2M6xB / va6k1pZijAgZxRKXbbzACUdbSv0MFip5TAAFyZkH4VIUgUq + BAgbAzLZOBEB0SZu2uDb87XMj1acvSOVs // QpUDnbmaLjz4I7HGCY70jZtjFzdEt42730bXJ6eoK1zTGHAx3KLtFFkurHJVXwIDAQAB”; —– DKTI teltubdkim for teltub.com _ssp.teltubdkim._domainkey TXT“dkim = unknown”

要特别小心…

看起来你已经在你的最后设置了正确的东西,你发布的头文件显示DomainKeys和SPF设置是可以接受的。 重要的是要记住,大多数垃圾邮件系统的工作总计各种分数。 将Google应用包含在发件人列表中可能不会有助于此评分。 64.34.222.96/27是一个非常大的networking掩码。 任何使它更具体的机会?

没有人可以从你提供的头文件中知道的是雅虎的贝叶斯filter所持有的东西 – 也不是你发送电子邮件的速度。 在后者的情况下,sendmail( 可能与Postfix一起工作)有几个milters,但我build议看看policyd

就您发送的内容而言 – 要说这是否是一个促成因素,要更加棘手。 当然,在没有DSN失败的情况下进行testing并不是一件容易的事,可以根据需求来确定如何重新创build问题。

如果您尝试将邮件从yahoo.com发送到[email protected],会发生什么情况? 它应该工作,即使它去了位斗。 同时确保滥用和邮寄主pipe地址都是有效的。