It's the nature of SMTP that it does not implement transactional integrity.
About 6 years ago I did quite a detailled analysis of why mails from the company I was working at then were failing. I could only see as far as the receiving MTA, but this showed a very strong correlation between the type of MTA and the failure rate (at that time, Novell Groupwise and Sendmail at the remote end were the most reliable, MSExchange the least, with qmail and others in the middle). Note that this was highly empirical and may have reflected product choice vs available skills rather than intrinsic problems in specific MTAs - and its rather out of date now. Also, its not something you can effectively control.
Although, since you've got the opportunity to develop and implement your own logic on top of the MTA, there is no guarantee that:
1) if a message fails after leaving your MTA you will get any bounce notification back
2) if you send a message with a DSN request (see RFC 1891) that the remote system will actually send back the DSN
The most important things you can do to improve deliverability is to know a lot about SMTP, maintain your own MTA and configure it accordingly. One of the key problems these days is that everyone's trying to stop spam - and everyone's got their own method of doing that. And usually they won't tell you the recipe for their secret sauce. Indeed, with bayesian filtering, they may not even know!
I guess the next port of call (after you've checked your SPF is restrictive and published, and that you're not RBL'd) would be to look at how you establish if your mail is getting delivered - as I said, you can't rely on DSNs. Not can you rely on bugging your emails (e.g. by sending them out as HTML with, e.g. ) since most MUAs will not load remote content (again to prevent spam). Which just leaves the option of keeping the content serverside and sending out a clickable link to the original content. But this again assumes that your recipients always want to read your message.
Set up a production quality mail server available to your application, and let it handle all the very dirty details of reliable mail sending. You are probably hitting some of the limitations like graylisting designed to keep spambots away.
A reasonably simple scenario would be Postfix on a Linux machine. Personally I like Ubuntu
Thorbjørn and symcbean have both provided lots of useful information, but it may be overwhelming in its completeness. I'll try to make it more approachable:
About the worst thing you can do is build an SMTP client into your application and rely on that to send mail to somewhere in the world. A much better solution is to run a "standard" MTA and/or SMTP server on your own box locally or, at worst, inside your own network.
So your app only has to get mail as far as your own mail server, which will hopefully be on port 25 on the same machine. No SSL encoding, no spam filtering, not a bunch of things that can go wrong. Also, if your mail server is on the same machine as your app, they will (usually) either both be down or both up.
Once your app has pushed its mail into your local mail server (which is fast and nearly foolproof), it is that server's problem to get the mail sent to the final destination. On a Linux server you will have something like Sendmail, qmail, exim or postfix installed; on Windows, I don't know.
Any one of those "out of the box" mail servers is highly competent at getting mail out. An automatic repeat is already built in, with retries after (e.g.) 1 hour, 2 hours, 4, 12, 24 and 48 hours. Your mail server will try its darndest to deliver your mail, and will do so with no extra effort on your part. Failed attempts will show up in the mail server's log, and you can analyze that and draw your conclusions. If it fails after the last possible attempt, that is also noted in the log file, and you can conclude that something was wrong on the receiving side. All this power is already built in, and you shouldn't even think of trying to build it into a mail client of your own.
Final note: It's possible for the transfer to be successful physically, i.e. the message was delivered, but then it was treated as spam by the recipient's mail server or client; or the (human) recipient simply deleted it by accident. No software is going to solve that problem with certainty.
In my opinion, running your own mail server is quickly becoming a thing of the past.
If my app will be sending more than a few emails, I usually setup an email-as-service provider and forget about it. Most of them let you just use their SMTP in your application.
As a bonus, most of them will show you statistics about who does what with your emails.
Some of the best known names in that space are sendgrid, mailjet and postmarkApp, but you can find an interesting comparison here
发布评论
评论（5）
SMTP 的本质是它不实现事务完整性。
大约六年前，我对我当时工作的公司的邮件发送失败的原因进行了相当详细的分析。我只能看到接收 MTA，但这表明 MTA 类型和故障率之间有很强的相关性（当时远程端的 Novell Groupwise 和 Sendmail 是最可靠的，MSExchange 最不可靠， qmail 和其他中间）。请注意，这是高度经验性的，可能反映了产品选择与可用技能的比较，而不是特定 MTA 中的内在问题 - 而且现在已经过时了。而且，它不是你可以有效控制的。
虽然，由于您有机会在 MTA 之上开发和实现自己的逻辑，因此不能保证：
1) 如果邮件在离开 MTA 后失败，您将收到任何退回通知
2) 如果您发送带有 DSN 请求（请参阅 RFC 1891）的消息，远程系统将实际发回 DSN。
要提高送达能力，您可以做的最重要的事情是了解有关 SMTP 的大量信息，维护自己的 MTA 并进行相应的配置。如今的关键问题之一是每个人都在努力阻止垃圾邮件 - 每个人都有自己的方法来做到这一点。通常他们不会告诉你他们的秘方的配方。事实上，通过贝叶斯过滤，他们甚至可能不知道！
我想下一个停靠点（在您检查了您的 SPF 是否受到限制并已发布，并且您不是 RBL 后）将是看看您如何确定您的邮件是否已送达 - 正如我所说，您不能依赖 DSN。您不能依靠窃听您的电子邮件（例如，通过使用 HTML 格式发送电子邮件），因为大多数 MUA 不会加载远程内容（同样是为了防止垃圾邮件）。这只留下了保留内容服务器端并发送原始内容的可点击链接的选项。但这再次假设您的收件人始终想要阅读您的消息。
C.
It's the nature of SMTP that it does not implement transactional integrity.
About 6 years ago I did quite a detailled analysis of why mails from the company I was working at then were failing. I could only see as far as the receiving MTA, but this showed a very strong correlation between the type of MTA and the failure rate (at that time, Novell Groupwise and Sendmail at the remote end were the most reliable, MSExchange the least, with qmail and others in the middle). Note that this was highly empirical and may have reflected product choice vs available skills rather than intrinsic problems in specific MTAs - and its rather out of date now. Also, its not something you can effectively control.
Although, since you've got the opportunity to develop and implement your own logic on top of the MTA, there is no guarantee that:
1) if a message fails after leaving your MTA you will get any bounce notification back
2) if you send a message with a DSN request (see RFC 1891) that the remote system will actually send back the DSN
The most important things you can do to improve deliverability is to know a lot about SMTP, maintain your own MTA and configure it accordingly. One of the key problems these days is that everyone's trying to stop spam - and everyone's got their own method of doing that. And usually they won't tell you the recipe for their secret sauce. Indeed, with bayesian filtering, they may not even know!
I guess the next port of call (after you've checked your SPF is restrictive and published, and that you're not RBL'd) would be to look at how you establish if your mail is getting delivered - as I said, you can't rely on DSNs. Not can you rely on bugging your emails (e.g. by sending them out as HTML with, e.g. ) since most MUAs will not load remote content (again to prevent spam). Which just leaves the option of keeping the content serverside and sending out a clickable link to the original content. But this again assumes that your recipients always want to read your message.
C.
设置一个可供您的应用程序使用的生产质量邮件服务器，并让它处理可靠邮件发送的所有非常脏的细节。您可能会遇到一些限制，例如旨在阻止垃圾邮件机器人的灰名单。
一个相当简单的场景是 Linux 机器上的 Postfix。我个人喜欢Ubuntu
Set up a production quality mail server available to your application, and let it handle all the very dirty details of reliable mail sending. You are probably hitting some of the limitations like graylisting designed to keep spambots away.
A reasonably simple scenario would be Postfix on a Linux machine. Personally I like Ubuntu
Thorbjørn 和 symcbean 都提供了大量有用的信息，但其完整性可能令人难以承受。我将尝试使其更易于理解：
您能做的最糟糕的事情就是在您的应用程序中构建 SMTP 客户端，并依靠它来将邮件发送到世界上的某个地方。更好的解决方案是在您自己的本地机器上运行“标准”MTA 和/或 SMTP 服务器，或者最坏的情况是在您自己的网络内运行。
因此，您的应用程序只需将邮件发送到您自己的邮件服务器，该服务器有望位于同一台计算机上的端口 25 上。没有 SSL 编码，没有垃圾邮件过滤，没有一堆可能出错的事情。另外，如果您的邮件服务器与您的应用程序位于同一台计算机上，那么它们（通常）要么都关闭，要么都启动。
一旦您的应用程序将其邮件推送到本地邮件服务器（速度很快且几乎万无一失），服务器的问题就是将邮件发送到最终目的地。在 Linux 服务器上，您将安装 Sendmail、qmail、exim 或 postfix 等软件；在 Windows 上，我不知道。
任何一台“开箱即用”的邮件服务器都非常有能力发送邮件。已内置自动重复功能，可在（例如）1 小时、2 小时、4、12、24 和 48 小时后重试。您的邮件服务器将尽最大努力传递您的邮件，并且无需您付出额外的努力。失败的尝试将显示在邮件服务器的日志中，您可以对其进行分析并得出结论。如果在最后一次可能的尝试后失败，日志文件中也会注明，您可以得出结论，接收方出现了问题。所有这些功能都已内置，您甚至不应该考虑尝试将其构建到您自己的邮件客户端中。
最后说明：有可能物理传输成功，即邮件已送达，但随后被收件人的邮件服务器或客户端视为垃圾邮件；或者（人类）接收者只是意外删除了它。没有软件能够确定地解决这个问题。
Thorbjørn and symcbean have both provided lots of useful information, but it may be overwhelming in its completeness. I'll try to make it more approachable:
About the worst thing you can do is build an SMTP client into your application and rely on that to send mail to somewhere in the world. A much better solution is to run a "standard" MTA and/or SMTP server on your own box locally or, at worst, inside your own network.
So your app only has to get mail as far as your own mail server, which will hopefully be on port 25 on the same machine. No SSL encoding, no spam filtering, not a bunch of things that can go wrong. Also, if your mail server is on the same machine as your app, they will (usually) either both be down or both up.
Once your app has pushed its mail into your local mail server (which is fast and nearly foolproof), it is that server's problem to get the mail sent to the final destination. On a Linux server you will have something like Sendmail, qmail, exim or postfix installed; on Windows, I don't know.
Any one of those "out of the box" mail servers is highly competent at getting mail out. An automatic repeat is already built in, with retries after (e.g.) 1 hour, 2 hours, 4, 12, 24 and 48 hours. Your mail server will try its darndest to deliver your mail, and will do so with no extra effort on your part. Failed attempts will show up in the mail server's log, and you can analyze that and draw your conclusions. If it fails after the last possible attempt, that is also noted in the log file, and you can conclude that something was wrong on the receiving side. All this power is already built in, and you shouldn't even think of trying to build it into a mail client of your own.
Final note: It's possible for the transfer to be successful physically, i.e. the message was delivered, but then it was treated as spam by the recipient's mail server or client; or the (human) recipient simply deleted it by accident. No software is going to solve that problem with certainty.
在我看来，运行自己的邮件服务器很快就会成为过去。
如果我的应用程序将发送多于几封电子邮件，我通常会设置一个电子邮件即服务提供商并忘记它。它们中的大多数允许您在应用程序中使用它们的 SMTP。
作为奖励，他们中的大多数都会向您显示有关谁对您的电子邮件做了什么的统计数据。
该领域一些最知名的名称是 sendgrid、mailjet 和 postmarkApp，但您可以找到一个有趣的比较 此处
In my opinion, running your own mail server is quickly becoming a thing of the past.
If my app will be sending more than a few emails, I usually setup an email-as-service provider and forget about it. Most of them let you just use their SMTP in your application.
As a bonus, most of them will show you statistics about who does what with your emails.
Some of the best known names in that space are sendgrid, mailjet and postmarkApp, but you can find an interesting comparison here
如果您只想每天向一组有限的收件人发送几封电子邮件，仅此而已，请尝试通过 Gmail 帐户发送它们。
If you just want to send a couple of emails a day to a finite set of receivers and that's all, try to send them through a gmail account.