如何从您的应用程序发送干净的电子邮件？
在开发发送通知电子邮件的应用程序时，避免
- 被托管公司标记为垃圾邮件发送者的最佳实践是什么。 （涵盖以下任意一项：）
- 防止邮件服务器泛滥的最佳技术
- 如果您要建立自己的邮件服务器产品，最好的邮件服务器产品
- 就像来自特定用户一样发送消息，但仍然清楚地来自您的应用程序（以确保您收到投诉等信息），而不会违反良好的电子邮件礼仪
- 任何其他经验教训
- ？没有被接收者的客户标记为垃圾邮件？ （涵盖以下任意一项：）
- 配置和使用发件人 ID、域名密钥、SPF、反向 DNS 等，以确保正确识别您的电子邮件
- 在为用户发送电子邮件时避免被标记为垃圾邮件的最佳 SMTP 标头技术（例如，同时使用“发件人”和“发件人”标头）
- 任何其他经验教训
附加要求：此应用程序将根据事件向单个收件人发送一条消息。 因此，向多个收件人发送相同消息的技术将不适用。
When developing an application that sends out notification email messages, what are the best practices for
- not getting flagged as a spammer by your hosting company. (Cover any of:)
- best technique for not flooding a mail server
- best mail server products, if you were to set up your own
- sending messages as if from a specific user but still clearly from your application (to ensure complaints, etc come back to you) without breaking good email etiquette
- any other lessons learned
- not getting flagged as spam by the receiver's client? (Cover any of:)
- configuring and using sender-id, domain-keys, SPF, reverse-dns, etc to make sure your emails are properly identified
- best SMTP header techniques to avoid getting flagged as spam when sending emails for users (for example, using Sender and From headers together)
- any other lessons learned
An additional requirement: this application would be sending a single message to a single recipient based upon an event. So, techniques for sending the same messages to multiple recipients will not apply.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
现在，对于其他值得提及的
IP，是您的邮件服务器，
让您的IP的ptr指向一个也解析为相同IP的名称
FQDNS
b 让您的服务器 helo/ehlo 带有whatever.domain.com，其中domain.com 与步骤 A 中的名称域相同{下面的名称与下面的名称不同}
c 让 helo/ehlo 服务器名称也解析为服务器的 IP
d 将以下 spf 记录添加到该 helo/ehlo 名称“v=spf1 a -all”
{意思是仅允许 helo/ehlo 具有该名称所指向的 ip 的名称}
e 将以下发件人 ID 行添加到 helo/ehlo 名称{纯粹是为了完整性
"spf2.0/mfrom,pra -all" {即没有 users@this-domain}
f 将以下 spf 添加到服务器的 FQDNS 名称和任何其他主机名
"v=spf1 -all" {即没有机器会使用这个名称，也不会使用 users@this-domain}
{因为 fqdns 名称可以由机器人/感染确定，最好永远不要允许在helo/ehlo 直接问候，只要它来自与 helo/ehlo 身份相同的域就足以证明两者的有效性}
now for the other bits that are worthwhile
ip's mentioned are your mailservers
a have your ip's ptr point to a name that also resolves to the same ip
FQDNS
b have your server helo/ehlo with whatever.domain.com where domain.com is the same as the domain of the name in step A {not the same name for resons below}
c have that helo/ehlo servername also resolve to the ip of your server
d add the following spf record to that helo/ehlo name "v=spf1 a -all"
{meaning allow helo/ehlo with this name from ip's this name points to only}
e add the following sender-id lines to the helo/ehlo name {purely for completeness
"spf2.0/mfrom,pra -all" {ie there are no users@this-domain}
f add the following spf to the FQDNS-name and any other hostnames for your server
"v=spf1 -all" {ie no machines will ever helo/ehlo as this name and no users@this-domain}
{as the fqdns name can be determined by bots/infections its better to never allow this name to be used in helo/ehlo greetings directly it is enough that it be from the same domain as the helo/ehlo identity to prove the validity of both}
除了与您的邮件服务器管理员检查之外，您对此无能为力（如果它是共享托管帐户/不在您的控制范围内）。 但如果要求是每个事件向单个收件人发送一封电子邮件，那么这应该不是什么太大的问题。 容易堵塞邮件系统的是具有数百（或更多）收件人的电子邮件。
如果您一直有事件发生，也许可以考虑合并它们并定期发送一封电子邮件来总结它们。
您可以通过使用“Reply-To”标头来完成此操作，然后客户可以使用该标头撰写电子邮件时，该地址而不是发件人地址。
您还应该设置任何电子邮件的“返回路径”标头，因为没有此标头的电子邮件通常会被过滤掉。
前任。
这在很大程度上取决于您对邮件和 DNS 服务器的所有权。 spf/sender-id 等...都是 DNS 问题，因此您需要访问 DNS。
在你的例子中，这可能会带来很大的问题。 当您将邮件设置为来自特定用户时，该用户必须在其 DNS 中设置 SPF（例如），以允许您的邮件服务器作为有效的发件人。 您可以想象，对于具有不同域名的大量用户来说，这会变得多么混乱（如果不是完全不可能的话）。
至于反向DNS之类的，那就要看情况了。 大多数客户端 ISP 等...只会检查反向 DNS 是否已设置。 （即，1.2.3.4 解析为 host.here.domain.com，即使 host.here.domain.com 未解析回 1.2.3.4）。 这是由于共享主机的数量（其中邮件服务器通常将自己报告为客户端的域名，而不是真正的邮件服务器）。
有一些严格的网络需要匹配反向 DNS，但这要求您能够控制邮件服务器（如果它一开始就不匹配）。
如果您可以更具体一点，我也许可以提供更多建议，但一般来说，对于需要发送应用程序邮件并且无法对其环境进行大量控制的人，我建议以下内容：
not a lot you can do about this beyond checking with your mail server admin (if it's a shared hosting account / not in your control). but if the requirement is one email to a single recipient per event, that shouldn't be too much of an issue. the things that tend to clog mail systems are emails with hundreds (or more) of recipients.
if you have events firing off all the time, perhaps consider consolidating them and having an email sent that summarizes them periodically.
you can accomplish this by using the "Reply-To" header, which will then have clients use that address instead of the From address when an email message is being composed.
you should also set the "Return-Path" header of any email, as email without this will often get filtered off.
ex.
this is all highly dependent on how much ownership you have of your mail and DNS servers. spf/sender-id etc... are all DNS issues, so you would need to have access to DNS.
in your example this could present quite the problem. as you are setting mail to be from a specific user, that user would have to have SPF (for example) set in their DNS to allow your mail server as a valid sender. you can imagine how messy (if not outright impossible) this would get with a number of users with various domain names.
as for reverse DNS and the like, it really depends. most client ISP's, etc... will just check to see that reverse DNS is set. (ie, 1.2.3.4 resolves to host.here.domain.com, even if host.here.domain.com doesn't resolve back to 1.2.3.4). this is due to the amount of shared hosting out there (where mail servers will often report themselves as the client's domain name, and not the real mail server).
there are a few stringent networks that require matching reverse DNS, but this requires that you have control over the mail server if it doesn't match in the first place.
if you can be a bit more specific i may be able to provide a bit more advice, but generally, for people who need to send application mail, and don't have a pile of control over their environment, i'd suggest the following:
首先对之前的返回路径进行快速更正
：是接收系统根据传入消息的信封发送者添加的标头，
以便 spf 正常工作，返回路径/信封发送者需要为 [电子邮件受保护]
并确保 yourdomain.com 的 spf 记录{或者如果是每用户 spf} < a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="225b4d5750435252625b4d5750464d4f434b4c0c414d4f">[email protected] 允许邮件源自托管应用/发送的服务器 该信封发件人的电子邮件
是收到所有退回邮件/错误的地址，
现在发件人 ID 完全不同，它会检查返回路径/信封发件人
和
发件人：地址{存储在消息内}
如果发送
来自：他的名字 [电子邮件受保护]
回复：他的名字[电子邮件受保护]
这将不是问题
如果发送
from: 他的名字 [email protected]
将会是，您必须添加
重新发送者：他的姓名[电子邮件受保护]
因为这指定忽略发件人：对于发件人 ID 检查，请使用它，因为它是由您代表他发送的
first a quick correction to the previous
return-path: is a header added by recieving system based on the envelope-sender of the incomming message
for spf to work the return-path/envelope-sender needs to be [email protected]
and ensure the spf record for yourdomain.com {or if per-user spf} for [email protected] allows mails to originate on the server that hosts the app/sends the email
this envelope-sender is the address that will recieve all bounces/errors
now sender-id is different entirely it checks the return-path/envelope-sender
and the
from: address {stored inside the message}
if sending
from: hisname [email protected]
reply-to: hisname [email protected]
this will be a non-issue
if sending
from: hisname [email protected]
it will be and you must add a
Resent-From: hisname [email protected]
as this specifies to ignore the from: for sender-id checks use this instead as it has been sent by you on his behalf