如何发送电子邮件而不是弄乱：实用提示

最初遇到电子邮件生成过程的开发人员实际上没有机会编写能够正确执行此操作的应用程序。 企业应用程序生成的电子邮件中大约有40％违反了某种标准，从而导致传递和显示问题。 这是有原因的：电子邮件在技术上比网络复杂得多，电子邮件受数百种标准监管，并且有不计其数的普遍接受（并非如此）惯例，并且电子邮件客户端是多种多样且不可预测的。 测试可以大大改善这种情况，但是实际上没有专门用于测试邮件的材料。

Mail.Ru邮件定期通过电子邮件与用户互动。 在我们的项目中，所有负责生成电子邮件甚至单个邮件的组件都经过强制测试。 在本文中，我们将分享我们的经验（并且充满坎bump）。

• 什么是电子邮件
• 谁参与测试和控制过程
• 邮件和邮政运输
• 邮件基础结构的接口和被测应用程序的边界
• 定义测试参数
• 发电应用的典型结构
• 什么时候测试
  
  1. 交付基础设施
  2. 生成应用
  3. 结构和布局信函模板
• 检查基础结构的基本要求
• 授权要求
• 验证生成的应用程序
  
  • 邮政地址要求
  • 电子邮件标题要求
  • 信件结构要求
  • URI要求
  • 布局要求
• 进行拆分测试

什么是电子邮件

该应用程序可以生成各种类型的字母。 它们可以分为几类。 通过选择收件人的方法：触发-选择性-分组。 预约：交易-营销-服务。 不同类型的字母可能有不同的要求，并且会应用不同的测试脚本。

触发电子邮件是响应任何事件（例如，用户操作或任何系统对象的状态更改）而生成的。 它们是由应用程序生成的，因此在测试方面最为有趣。 触发电子邮件既可以是交易邮件，也可以是市场营销邮件。

自定义字母将发送给符合任何条件的动态选择用户。

组消息将发送给已知的收件人组，例如所有用户或合作伙伴。 选择性信件和团体信件最经常用于市场营销，此类信件的发送是手动或根据计划启动的。

用户执行某项操作时会生成交易信件。 此类信件包括例如发票，票证或交货状态通知，带有访问恢复码的信件等。 交易电子邮件始终会触发。 最大的兼容性对他们很重要，这意味着它们应该尽可能简单，并且需要在大量客户上进行测试。

营销信鼓励用户采取任何行动，例如，它可能是基于先前购买的个人折扣的提议。 在这些字母中，可以使用事务数据，它们既可以是触发数据，也可以是质量数据-周期性或一次性的。 对于这些字母，效率更为重要，通常取决于拆分测试的结果。 为了效率，可以牺牲兼容性的某些方面。

团体营销信函，例如有关季节性优惠，促销和销售的消息，通常是“手动”发送的，不属于您的应用程序，但是您可以（并且应该）对其应用通用的测试原理。

此外，可能会有员工为自动或自动CRM，日记帐，审计或DWH系统生成的服务信函。 这些字母是触发器，这意味着它们也是应用程序的一部分，必须进行测试。

谁参与测试和控制过程

1. 质量检查工程师-参与过程的所有阶段。
2. 网络工程师-负责配置网络和消息传递基础结构。 网络工程师应参与计划基础架构测试。
3. 可传递性专家是监视信件传递的人员，他还参与监视所有已发送邮件的技术和管理参数并监视邮件处理的进度。 他有责任确保所发送的信件达到用户的最大可能百分比，并且不会陷入垃圾邮件，为此，专家必须具有一定的知识和联系方式。 如果在送达信件时出现问题，那是他必须了解可能的原因并消除它：通过消除技术障碍； 或更改信件内容； 或解决邮件提供商无法提供的支持服务问题。 此类专家（如果有的话）还应参与准备清单和测试生成应用程序和信函的基础结构。 但是，测试过程本身必须在质量检查服务的控制之下。
4. 电子邮件营销人员-确定营销活动的有效性。 在他的控制下，针对营销邮件进行了针对受众的拆分测试。 电子邮件营销人员还控制用户群的细分，所发送电子邮件的组成和频率以及向用户发送的电子邮件的可视“呈现”。

所有这些角色不必由单独的员工来执行：营销人员的角色可以由产品经理之一扮演，而交付能力专家的角色可以由例如支持员工或网络工程师来担任。 在很有可能的初创公司中，所有这些都必须由一个人来完成，他们可能会成为质量专家。

邮件和邮政运输

邮件结构类似于一个巨大的冰山，它有两个层次。 监管邮件的标准有一百多种，但是几乎所有标准都属于以下两个级别之一：

冰山的水下部分是一项网络服务，其基本协议是RFC 5321定义的SMTP应用程序协议。它负责传递字母。 为了发送信件，形成了一个所谓的SMTP信封，其中包括SMTP级别的发送者和接收者的地址。 其他网络服务（例如DNS）也负责传递信函。 网络基础结构的主要组件是邮件传输代理，或者更经常使用缩写MTA。 MTA负责处理邮件传递队列和到收件人服务器的传递过程。 MTA的示例是Postfix，Sendmail，Exim，Microsoft SMTP服务。

冰山的这一水下部分包括MTA，DNS参数和其他网络参数，我们将其称为邮件基础结构或邮件传递基础结构。

冰山的表面就是字母本身。 字母的基本结构在RFC 5322中定义。字母由服务标头和一个或多个带有数据的部分组成。 数据可能包含纯文本和/或HTML文本，嵌入式图像或几乎任何类型的附件。

邮件基础结构的接口和被测应用程序的边界

通常，邮件基础结构具有一个或多个用于发送信件的接口（它进入MTA传递队列）。 例如，SMTP提交服务，PHP中的mail()函数，向外部邮件或sendmail应用程序的数据传输，内部或外部服务的API（例如，GetResponse，SendPulse或Amazon SES）。 我们将这些接口视为基础架构的一部分。 通常情况下，应用程序A为信件和收件人列表准备数据，然后通过其API将其传输到应用程序B（对于批量邮件营销，这可以通过用户界面-UI手动完成），而应用程序B已经在其中生成了邮件消息。 RFC 5322格式，以某种方式将其排队等待MTA传递。 从应用程序A（以及对其进行测试时）的角度来看，应用程序B将成为邮件基础结构的一部分。 应用程序B API或UI将是应用程序A的邮件基础结构接口。 尽管从应用程序B的角度来看，情况将有所不同，并且其邮件基础结构将是较低级的网络应用程序或协议。

定义测试参数

在测试每个应用程序时，重要的是突出显示它使用的所有邮件基础结构（可能有多个），对于每个基础结构，选择所使用的接口（每个基础结构也可能有多个）。 对于每个接口，将尽可能准确地确定传输到该接口的数据的组成和格式，例如：TEXT / HTML中的消息文本，TEXT / PLAIN中的消息文本，消息主题，收件人名称，收件人地址，发件人名称，发信人地址（RFC5321。 ），即SMTP导体的发送者的地址（RFC5322.mailfrom）。 接下来，为每个参数（表示，编码，边界值等）制定一组要求，确定每个参数的控制方法（如何将实际结果与预期结果进行比较）。

发电应用的典型结构

通常，我们正在测试的产品负责在其中生成字母和数据。 这通常是服务器（但有时是客户端）应用程序。 它定义了字母的结构，服务标头的一部分，数据封装的格式，字符串表示和文本编码。 这种应用程序的一个简单示例是一个脚本，该脚本形成一个字母并调用mail()函数。

需要控制的应用程序的主要元素：

• 如果动态生成字母结构和/或描述其结构的静态字母模板，则负责生成标头和/或字母结构的代码；
• 字母的HTML部分的布局（理想情况下，这是一个单独的实体或字母模板/布局的一部分，但可以缝入应用程序代码中）；
• 用字母（或字母模板）替换应用程序数据；
• 应用程序与信函传递基础结构集成，将参数的正确性转移到基础结构接口。

什么时候测试

不管我们是否喜欢，整个冰山都需要进行测试。 有几个主要组件需要测试：

1.交付基础设施

测试的重点应放在：信件的可传递性； DNS记录的正确性，包括PTR / FCrDNS，MX和A记录； SMTP协议设置（HELO，使用TLS）； 信件授权书（SPF / DKIM / DMARC）； SMTP信封地址（如果不受应用程序管理）； 正确处理基础结构接口的输入参数； 跟踪，会计和处理未送达的信件。

在初始实施期间以及每次对基础结构本身进行更改（MTA，DNS或网络更改的配置）或发送信件的接口进行更改时，都必须测试基础结构； 使用新的域，网络或API 大大改变了所发送电子邮件的特性，例如其语言，大小或数量。 根据经验，基础设施往往会在不宣战的情况下发生变化，因此即使没有任何变化的信息，也应定期进行基本测试。

网络工程师和可交付性专家可以并且应该参与计划的准备和基础结构测试的清单。

2.生成应用程序

您应该控制SMTP信封的地址（如果它们是由应用程序控制的，即传输到接口-信封从，信封到），服务消息标头的值（日期，消息ID，列表取消订阅，自动提交等）。 p。），字母授权（DKIM / DMARC），MIME编码（base64，带引号的可打印格式），字母格式的一般正确性，例如，标头中没有非ASCII字符，替换数据的组成，触发器的正确​​触发，取消订阅机制，跟踪机制字母和统计信息收集（邮局主管标头，例如，反馈ID或X-Mailru-Msgtype，以及跟踪像素） 。

您需要在应用程序的开发过程中，更改其所有负责生成和存储数据的相关组件，对字母模板进行重大更改，更改所使用的基础结构或其接口以及在常规回归框架中进行测试。

3.结构和布局字母模板（可以是生成应用程序的一部分，也可以单独开发）

检查邮件的结构（内容类型，内容处置，字母的多部分的嵌套，文本编码，字符串参数），目标值和显示的标题（从，收件人，回复至，主题），邮件显示在字母列表中，并且在阅读时在各种界面中，微格式（例如，将日历事件识别为日历事件，或将机票识别为机票），品牌。

每次进行至少最小的更改时，都应测试电子邮件模板，并且还应分别进行测试，例如，在服务器部分准备就绪之前，字母进入应用程序的情况下。

建议您使用电子邮件营销商和可传递性专家来编写用于测试信函模板的清单。

检查基础结构的基本要求

为邮件服务器选择的IP地址应与邮件服务器的IP地址尽可能相似。 建议使用whois实用程序进行检查。 特别是，发件人地址不应属于可以被视为动态的网络； 所选网络必须具有可以向其发送投诉的有效联系人； 必须使用网络（RIPE中的状态为ASSIGNED）。 IP地址必须具有正确配置的PTR记录。 可以通过托管控制面板或使用提供商的支持服务来独立配置它。 PTR记录必须指向真实的主机名，同时必须有意义，解析回相同的IP地址（所谓的FCrDNS检查），不提醒动态主机名，并且不包含大量数字或字符。 一个很好的例子是mailserver.example.com。

信封地址或邮件头中使用的每个域都必须具有指向主机的A记录的有效MX记录，该记录至少可以处理有关传递失败的消息。 对于MX，不允许直接引用IP地址。

控制SPF，DKIM，DMARC的通过。 SPF允许域所有者在TXT记录中指定有权发送此域中具有返回地址的电子邮件的服务器列表。 它被配置为域DNS区域管理部分中的“信封自”（SMTP信封）中使用的地址。 DKIM使用数字签名技术来验证消息的作者身份或属于特定域的发件人，该技术已添加到消息本身（在其DKIM-Signature标头中）。 通常，DKIM签名是在MTA（基础结构）级别配置的。 DMARC设置了检查特定域中的传入邮件的策略，并对未通过SPF或DKIM身份验证的字母采取措施。 当您尝试违反此策略时，结构化报告将附带有关此类尝试的信息。 DMARC和SPF在域区域中作为TXT记录发布。

检查对主要邮政服务的信件传递-俄罗斯，Mail.Ru，Yandex，GMail，Microsoft（Hotmail / Outlook.com / Office365），Rambler，nic.ru。 在信件中，您需要验证HELO的正确性； PTR / FCrDNS，SPF，DKIM和DMARC支票的可用性和通过； 标头及其中数据的有效性，尤其是日期中小时的同步性和时区的正确性。



某些参数（例如授权，可传递性和垃圾邮件）的形成受所有组件的整体影响，但是通常有单独的操作工具来控制它们-DMARC和FBL报告，邮政主服务API，电子邮件跟踪工具以及传递统计信息。 测试应考虑到公司运营监控工具的实施水平-例如，在没有DMARC报告的运营监控的情况下，您应该定期测试邮件授权，而在缺乏对可传递性的运营监控的情况下-定期检查信件的接收方式和位置，即使没有与发送信件有关的发展没有进行。

要检查基础结构，可以使用专门的服务，例如mail-tester.com ， mxtoolbox.com 。 详细的基础结构要求可以在本文中找到。

授权要求

通常可以使用收件人服务器上的Authentication-Results标头检查SPF，DKIM，DMARC的通过。

检查SPF记录的有效性，以了解语法和DNS查询的限制（例如，使用mxtoolbox.com）。 形成SPF时，应考虑所有邮件来源（不要忘记CRM系统，所有使用的传递基础结构，包括进行一次性营销活动的那些基础结构）。 建议通过网络列表（“ ip4” /“ ip6”）为域设置允许的服务器。 从SMTP信封中检查SPF以查找发件人地址。 验证SMTP信封域（envelope-from）是否与From头中的域匹配。 本文列出了常见的SPF错误。

检查DKIM DNS记录，DKIM签名的有效性和组成。 验证您使用的是至少1024位的DKIM密钥。 推荐的DKIM签名的哈希模式：宽松/宽松。 确保所有重要标头均已签名（“发件人”，“收件人”，“主题”，“日期”，“邮件ID”，MIME版本，“内容类型”），跟踪标头（“接收”，“传递至”，“返回路径”）未签名，并且DKIM已针对基本邮政服务。 设置将邮件服务之一转发到另一服务； DKIM不应在转发的信件上“跳动”。 验证DKIM签名域是否与From头中的发件人域匹配。

检查DMARC中的基本邮件服务。 检查DMARC报告，确定基础结构的所有IP地址的SPF和DKIM并进行故障排除。

验证是否使用加密（TLS）将邮件传递到了外部服务器。 有时，您可以通过收件人服务器上的Received标头检查TLS：例如，指定ESMTPS协议或存在以下形式的参数（版本= TLS1_2密码= ECDHE-RSA-AES128-GCM-SHA256位= 128/128）； 表示存在TLS。

验证生成的应用程序

邮政地址要求

信封地址
我们使用SMTP信封中的地址开始验证生成的应用程序。

信封地址是邮件基础结构级别的地址。 它们对用户不可见，但对于传递很重要，因为这封信是从哪个邮箱获得的，它是由信封的地址精确确定的。

信封中的收件人地址（信封，也称为RCPT TO ：）是信件实际寄达的地址。

• 对于除注册以外的所有信件，必须根据行政要求对地址进行合法签名和验证，以便邮寄。
• 对于新闻通讯，该地址必须是“实时”的，不能定期向其发送信件的地址应标记为无效，不应该发送邮件。 但是，某些类别的字母（例如，访问恢复）也可能需要发送到以前标记为无效的地址。

SMTP信封中的发件人地址（通常称为信封发件人，smtp.mailfrom或Return-Path）-有关无法传递信件和自动回复的消息将传递到该地址。 该地址对用户不可见。 此地址也用于SPF授权。 我们验证：

• 地址可用；
• 它不是员工的地址，也不会重定向到他的位置以排除自动答复，有关无法访问的消息等；
• 它由脚本处理，该脚本会将无法访问的用户的地址标记为不活动；
• 该地址可以自动生成，即 每个字母唯一；
• 到该地址的信件不应导致任何响应信件的产生，例如，有关包装箱溢出的消息。

电子邮件标题地址

这些地址对用户是直接可见的，或者在回复信件时使用。

发件人地址（From :)标题是字母列表中和阅读字母时显示的地址和发件人名称。 我们验证：

• 这是识别公司的“易于阅读”的友好地址。
• 它不仅包含电子邮件，还包含发件人的姓名。
• noreply @是可能的，但是只有在我们要强调我们不希望收到对该信件的答复并且不会被阅读时，才可以。 最好在信件的文本中重复这个想法。
• 在存在非ASCII字符（例如，西里尔字母）的情况下，发件人名称必须按照MIME进行编码，在存在非ASCII字符的域中必须使用Punycode进行编码。
• 相同类别的字母应具有相同的地址；不允许使用自动生成的地址。 这是由于以下事实：发件人：通常是人们使用过滤器将字母分类到文件夹中的。
• 对于交易，市场营销和紧急信件（例如来自支持服务的信件），地址应该不同（最好在不同的子域中）。 这也是由于用户可以将营销电子邮件标记为垃圾邮件或将其过滤到不可读的文件夹中。
• 发件人地址和SMTP信封地址必须在同一域或同一组织域的子域中，以便在DMARC中传递SPF。
• 地址必须来自组织的域。 在发件人中使用免费邮件服务和其他公共邮件域是不可接受的，因为此类邮件在DMARC框架内不会通过SPF和DKIM身份验证。

回复地址-当用户回复信件时，“手动”回复将发送到该地址。 它是可选的：如果不存在，则将From的地址用于响应。 检查回复对象：

• 它可以自动生成，即 字母所特有的（使您可以找出答案的字母）。
• 它不应掉入员工的邮箱中以避免接听电话，而理想情况下应将其“包装”在CRM中。
• 它可以生成标准的CRM自动应答，但不应生成多余的内容，例如，有关包装箱溢出的消息。 生成自动响应时，必须采取避免循环的措施，它们在RFC 3834中列出。
• 它可以来自不一定与“发件人”一致的任何域，但是有时这会在回答时使用户感到恐惧。
• 可能不存在，然后“发件人”地址将执行其功能。
• 除地址外，还显示发件人的姓名。

解决：

• 它应该包含收件人的电子邮件（否则它会使邮件的收件人感到恐惧并保护反垃圾邮件）。
• 理想情况下，它应该包含收件人的姓名。 但是，如果姓名不明或可疑（例如，地址尚未确认），则最好不要注明（有人可能输入名字不正确的人的地址，而收件人可能会被您冒犯）。

电子邮件标题要求

文本的实际编码应与标题中指示的编码匹配。 建议在字母的所有标题和部分中使用一种编码。 建议您将UTF-8用作广泛支持的UTF-8。 在Content-Type标头和HTML部分的<META>标记中指示编码。

From：，Message-ID：和Date：标头必须直接在脚本中形成，以发送字母（并按照标准-以及字母文本），并且始终采用正确的格式。 如果它们不存在或格式不正确，则其中一个传输服务器可以添加这些标头，这将导致DKIM签名的完整性受到侵犯。

标头中应缺少8位字符，包括主题行（主题）和附件的文件名（Content-Type和Content-Disposition）； 所有非ASCII字符（包括西里尔字母）都必须使用带引号的可打印字符或base64进行编码。

信件结构要求

对于字母的HTML部分，希望形成一个替代部分-文本（纯文本）部分。 还必须检查字母的纯文本部分（如果有）的一致性和可读性以及字母的一般结构。

根据RFC 5322，字母中的行长不应超过998个8位字符。 请注意，在UTF-8中，一个字符可以占用几个八位字节。 电子邮件中各行的终止符是一对CRLF（<cr> ascii 13，lf> ascii 10），占2个八位位组。 您需要检查字符串终止符的正确性，因为字母通常是使用Unix脚本发送的，在Unix中，行终止符是单个lf字符-这是电子邮件错误。 您还应该检查字符串终止符是否破坏了UTF-8编码的字符：您不能允许在相同字符的两个八位字节之间存在字符串终止符，例如，西里尔字母。 , base64.

— «Content-Disposition: inline», , , «Content-Disposition: attachment», .
, , : , multipart- (mixed, alternative, related), multipart/mixed , multipart/related — , multipart/alternative — plain text- HTML-. , -, :

multipart/alternative
— text/plain
— text/html

, text/plain text/html multipart/related. , HTML-, - — plain-.

- :

multipart/alternative
— text/plain
— multipart/related
—— text/html
—— image/… (-)
—— image/… (-)

- Content-Disposition: inline multipart/related-.

, , , :

multipart/mixed
— multipart/alternative
—— text/plain
—— multipart/related
——— text/html
——— image/png
——— image/png
...
— application/octet-string (content-disposition: attachment)
— application/octet-string (content-disposition: attachment)
...

(multipart/related- multipart/alternative- , multipart/mixed-)

URI

URI ( src, href, ..) ( https://example.com/somepath ). (/somepath) (//example.com/somepath), , .. file://.

• ASCII- ( , ) URI percent encoding.
• , (.. URL, ), <>, . - , . href A , - . «», .
• htt://, htts:// milto:.
• http:// htts://.
• (, example.com :8080/somepath), .. .
• HTML- - (, , ..) , .. - , ; , , , ( - GET-, POST PUT).
• List-Unsubscribe, , - , .. .
• , , , (, ). . , , , , , .
• 因为 URI , URI data:. URI.
• , . , , .
• - .

?

. — (XSS, Crossite scripting), (interface spoofing), DOM clobbering, / (, IP- ) .., . , . :

• ,
• / ,
• ,
• ( ),
• (.. ) ,
• HTML- ( Microsoft Exchange / Outlook RTF, - Outlook ),
• .

, - URI cid://, . , Mozilla Thunderbird cid:// .

- - .

. , URI, - , - , . : , ( , ).

:

• , , , , .
• .
• , , , . ( ). . , .
• , .
• , , .. -, - , c, , ( , , , , - ). , , .
• .
• , , , . (, - ), , , , .
• .
• :
  
  • : « » Mail.Ru, Yandex, Gmail, Rambler Outlook.com;
  • ;
  • , IMAP, , iPhone, Pixel ( Android), Samsung ( Android), MIUI ( Android-);
  • : Chrome, Firefox, Edge, Internet Explorer, Opera .;
  • ( ), Thunderbird, Outlook Apple Mail, The Bat! Opera Mail;
  • - (Exchange, Roundcube, Communigate, Zimbra, SquirrelMail) — B2B-;
  • Retina-, .
• :
  
  • , SPF/DKIM/DMARC.
  • : , .
  • : , , , (, «»).
  • : , .., .
  • .
  • .
  • .
  • , . , , - , , .
    
    
    
    
• ( ) , . , .
• , , , .. , , , «» .
• . , DKIM- - ( DNS DKIM-, ), - ( , , From, Date Message-ID) - ( , , ). «» , .

-

, , .

, , ( ). . , , .

CTR — . postmaster.mail.ru . (), . CTR < 10% — , . CTR > 30%. CTR («») . ( ). , — . , , : https://help.mail.ru/developers/mailing_rules/technical .

- . CTR . ( ). «» — 10 000 , .

: , , . « » . , .

z3apa3a s4ever . EdT 4Alexander .