use*_*ca8 11 microsoft-outlook email smtp microsoft-outlook-2016
我有一个问题,即发送给某些收件人的所有电子邮件都已发送但从未到达,即使是垃圾邮件,也没有错误,而发送给其他所有人的电子邮件工作正常。我很难过,正在寻找诊断正在发生的事情的方法。
我已尝试向该域发送各种测试电子邮件,但均未通过:
test@my-domain.com与我通常的 一起使用my-name@my-domain.com),它有完全相同的问题(使用 webmail 测试)。电子邮件来自我自己的域 - 我已经从相同的电子邮件地址和相同的 Outlook 向其他人发送了电子邮件,他们收到了很好的邮件。Gmail 偶尔会将它们标记为垃圾邮件,我正在调查,但其他客户端似乎没有问题。
除此之外,我什么也看不到。我敢肯定,这里还不足以诊断我的问题,所以我要求的不是解决方案,而是我可以采取的诊断步骤,例如:
我已经看到这个问题Emails not be received by some people,这很相似,但有两个不同之处:
正如泰森所建议的,我已经尝试过http://mxtoolbox.com/但不幸的是它没有提供任何线索(至少,我看不到任何线索)。如果我错过了什么,这里是结果:
正在根据 95 个已知的黑名单检查 XX.XX.XX.XX...
列出 0 次,有 1 次超时
[然后在列表末尾有很多绿色的勾号:]
TIMEOUT IPrange RBL Project [response time:] 0
所以它不在任何已知的黑名单中。我不知道为什么 IPrange RBL 检查失败,但我在http://iprange.net/rbl/lookup/手动检查,我也没有在那里列入黑名单。
所以连接时间有点慢(我不知道为什么,会调查一下),但我不明白为什么这会导致发送的邮件有时完全消失。
http://intodns.com也为我的域的所有 MX 检查提供了纯绿色的勾号。
我试过在(Centos/Linux)服务器上浏览日志文件:
/var/log/maillog——这些都是空的。我相信这些是 sendmail 日志,我目前不使用 sendmail,所以这是有道理的。/var/log/exim/reject.log充满了拒绝的蛮力尝试dovecot。我已经fail2ban并且我将继续检查我的防火墙设置等,看看我是否可以阻止他们甚至尝试,但我认为这无关/var/log/exim/main.log 还包含许多被拒绝的蛮力尝试,但也包含一些实际发送的电子邮件的记录:这是一封发给同一域中三个人的电子邮件,但对所有三个人都失败了(我编辑了一些字母数字字符串并将 IP 地址替换为 TXT.LIKE.TH.IS):
2016-02-12 08:55:41 no host name found for IP address MY.PC'S.IP.ADR
2016-02-12 08:55:49 1aU9Vw-0004vq-EG <= me@my-domain.com H=(MyPCName) [MY.PC'S.IP.ADR] P=esmtpa A=dovecot_login:me@my-domain.com S=1443429 id=000001d17563$920b5cf0$7b1622d0$@my-domain.com
2016-02-12 08:55:51 1aU9Vw-0004vq-EG => alice.domain@receives-nothing.org <alice.domain@receives-nothing.org> R=dnslookup T=remote_smtp H=cluster5.us.messagelabs.com [US.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:55:51 1aU9Vw-0004vq-EG -> brian.domain@receives-nothing.org <bob.domain@receives-nothing.org> R=dnslookup T=remote_smtp H=cluster5.us.messagelabs.com [US.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:55:51 1aU9Vw-0004vq-EG -> carol.domain@receives-nothing.org <carol.domain@receives-nothing.org> R=dnslookup T=remote_smtp H=cluster5.us.messagelabs.com [US.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:55:51 1aU9Vw-0004vq-EG Completed
Run Code Online (Sandbox Code Playgroud)
这是给成功的人的一封电子邮件(收件人收到):
2016-02-12 08:58:20 no host name found for IP address MY.PC'S.IP.ADR
2016-02-12 08:58:23 1aU9YU-0004w0-IN <= me@my-domain.com H=(MyPCName) [MY.PC'S.IP.ADR] P=esmtpa A=dovecot_login:me@my-domain.com S=23133 id=003101d61537$874b04a0$59e01ed0$@my-domain.com
2016-02-12 08:58:26 1aU9YU-0004w0-IN => zak.receives@email-normally.org <zak.receives@email-normally.org> R=dnslookup T=remote_smtp H=cluster4.eu.messagelabs.com [UK.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:58:26 1aU9YU-0004w0-IN Completed
Run Code Online (Sandbox Code Playgroud)
我看不出两者之间有任何显着差异。前后都是蛮力碎片和其他电子邮件。
我不知道cluster5.us.messagelabs.com或的意义cluster4.eu.messagelabs.com是什么,但关联的 IP 地址都是 MessageLabs IP 地址。
谷歌搜索 messagelabs.com 已经打开了这篇博客文章,它看起来很相关,并表明(顺便说一句)我的两个客户都是 MessageLabs 订阅者,但对于重要的区别,a) 与作者不同,我什至没有得到未交付收据和 b) 如果是 MessageLabs 阻止了我的电子邮件,我不明白为什么他们会为他们的一个客户而不是另一个客户阻止它。
小智 3
电子邮件故障排除可分为“发件人”问题和“收件人”问题。由于您能够发送给其他人,因此发送端可能工作正常。需要向接收方进行排查,定位问题所在。
查看日志是一个很好的步骤,它可以告诉您消息到达了哪里以及没有到达哪里。正常的电子邮件流程是这样的:
您从电子邮件软件发送到您的服务器
您的服务器发送到他们的服务器
他们的服务器发送到他们的电子邮件客户端
在这种情况下,您可以从日志中看到他们的服务器似乎是
cluster5.us.messagelabs.com
Messagelabs 是一项电子邮件过滤服务,现归赛门铁克所有。此类邮件过滤服务用于在邮件发送到客户端软件之前删除所有垃圾邮件和垃圾邮件。这意味着被 messagelabs 阻止的任何消息都不会出现在客户端软件的任何垃圾邮件或垃圾电子邮件文件夹中。它们会消失,接收者永远不会看到它们的任何迹象。在极少数情况下,他们可能会收到一条消息,指出“来自某人@example.com 的消息已被阻止。请联系您的 IT 部门以解除阻止。”
This sounds very similar to what has happened here. Technically you should get a bounce response from messagelabs like the guy in the link you posted but this is not guaranteed. They may just silently delete your message if they think it is spam. Usually messagelabs will provide an interface for the IT department at their customer where blocked messages can be released. You can ask your contact at the company to check with their IT team for any blocked messages from your email address. At least you can if you have some other way of contacting them!
Other useful general troubleshooting steps: If you didn't have access to the log files you can find out what the server should be for any domain by looking up the "MX records"
For example here: http://mxtoolbox.com/
The MX record is what an email server looks for to find out where they should send your email.
You can then initiate a manual connection to the server listed in the mx record to see if it is accepting email and what error messages you might get. Use a telnet program like Putty: http://www.putty.org/ and telnet to the email server on port 25. Some of the commands you will need are listed here: http://www.yuki-onna.co.uk/email/smtp.html
So now you can connect to their mail server and send an email using your email address as the "From" address and see how the server responds directly. Any email error codes that are returned can be looked up in google or here: http://www.serversmtp.com/en/smtp-error
Once you have checked that you can connect to the server it may tell you why your email is being rejected as spam or for some other reason, but the reason may not be easy to decipher. At this stage I would suggest you ask the messagelabs customer to contact their support number with the error codes (or lack of them) that you received from their server. Since you are not a customer of messagelabs you can't log a problem or ask messagelabs to check the settings on their customer's account. Their customer will have to ask that themselves. This would be similar for any other mail filtering provider.
Hopefully the error code would point you to a particular problem, like your server being listed on a block list or lacking a SPF record and you can fix that yourself because dealing with a mail filtering provider at third hand is never fun. The last problem I had like this took over three months to resolve before the fault was located and messagelabs fixed it.
I will defer to the answer by kubanczyk for details on SPF and DKIM settings because they seem to be much more knowledgeable than I am!
Good luck!
| 归档时间: |
|
| 查看次数: |
66799 次 |
| 最近记录: |