在开发发送通知电子邮件的应用程序时,
的最佳做法是什么附加要求:此应用程序将根据事件向单个收件人发送单个邮件。因此,向多个收件人发送相同邮件的技术将不适用。
答案 0 :(得分:5)
除了检查您的邮件服务器管理员(如果它是共享主机帐户/不在您的控制中)之外,您不能做很多事情。但如果要求是每个事件向一个收件人发送一封电子邮件,那么这不应该是一个问题。容易阻塞邮件系统的东西是包含数百(或更多)收件人的电子邮件。不淹没邮件服务器的最佳技术
如果您一直关闭事件,可以考虑合并它们并发送一封定期汇总的电子邮件。
从特定用户发送消息,但仍然清楚地从您的应用程序发送消息(以确保投诉等回复给您),而不会破坏良好的电子邮件礼仪
您可以使用“回复”标题完成此操作,然后在撰写电子邮件时,客户端将使用该地址而不是“发件人”地址。
你还应该设置任何电子邮件的“Return-Path”标题,因为没有这封邮件的电子邮件通常会被过滤掉。
离。
From: me@me.com
Return-Path: me@me.com
Reply-To: auto@myapp.com
配置和使用sender-id,domain-keys,SPF,reverse-dns等,以确保您的电子邮件被正确识别
这完全取决于您对邮件和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,但这要求您可以控制邮件服务器,如果它首先不匹配。
如果您可以更具体一点,我可以提供更多建议,但一般来说,对于需要发送应用程序邮件,并且没有对其环境进行大量控制的人,我会建议如下:
答案 1 :(得分:0)
首先快速修正前一个
return-path:是根据收到邮件的信封发件人收到系统添加的标题
要使用spf,返回路径/信封发件人需要是yourapp@yourdomain.com
并确保yourdopp @yourdomain.com的yourdomain.com {或if-user spf}的spf记录允许邮件来自托管应用程序的服务器/发送电子邮件
此信封发件人是接收所有退回/错误的地址
现在sender-id完全不同,它会检查return-path / envelope-sender 和 from:地址{存储在消息内} 如果发送 来自:hisname yourapp@yourdomain.com 回复:hisname hisaddres@hisdomain.com
这将是一个非问题 如果发送 来自:hisname hisaddres@hisdomain.com
它将是你必须添加一个 Resent-From:hisname yourapp@yourdomain.com 因为这指定忽略from:for sender-id支票,请使用它,因为它是由您代表发送的
答案 2 :(得分:0)
现在用于其他有价值的比特
提到的ip是你的邮件服务器让你的ip的ptr指向一个也解析为同一个ip的名字 FQDN的
b将您的服务器helo / ehlo与whatever.domain.com一起使用,其中domain.com与步骤A中的域名相同{不同于下面的resons的名称}
c,helo / ehlo服务器名也解析为服务器的IP
将以下spf记录添加到helo / ehlo名称“v = spf1 a -all” {意思是允许helo / ehlo使用此名称来自ip,此名称仅指向}
将以下sender-id行添加到helo / ehlo名称{纯粹是为了完整性 “spf2.0 / mfrom,pra -all”{即没有用户@ this-domain}
将以下spf添加到FQDNS名称和服务器的任何其他主机名 “v = spf1 -all”{即没有机器会像这个名字一样helo / ehlo而没有用户@ this-domain}
{因为fqdns名称可以由机器人/感染确定,最好永远不要让这个名字直接用在helo / ehlo问候语中就足以让它来自与helo / ehlo身份相同的域来证明两者的有效性}