达芬奇密码

除了技术，无它

439篇博客

最新博客

最新资源下载

编辑推荐

网易数帆开源API网关与容器云项目，让云原生生产落地“多快好网易汪源：统一负载与多云环境的“开放姿态”，才是云原生网易数帆如何用 Kubernetes“原语”搞定云原生中间件快手打新挤爆券商系统，网易数帆推出券商稳定性保障方案探索智慧校园新模式，网易有数在教育行业的实践分享金融行业大数据治理之路——数据模型篇

Abuse Report Format (ARF) 学习笔记

达芬奇密码2018-08-02 11:56

【为啥写这篇东东】
    近来手头有一个关于电子邮件report功能的需求，需要用到一种叫  Authentication Failure Reporting Format([ AFRF]) 的report格式。这个[ AFRF]可以看作是基于现有的 Abuse Report Format 规范扩展出来的一种新的report类型。
    无奈之前对 Abuse Report Format 了解不深，只能dip into [ ARF]的RFC文件，于是默默地打开了IETF官网找RFC和Wiki。。。
    网上关于 Abuse Report Format规范（下面都简称ARF）的资料不多，几乎无中文资料。于是将学习笔记整理成这篇博文，与大家伙分享，抛砖引玉，更具体的信息还需大家回头查阅RFC了。
    约定一下：本文中出现的形如 [ xxx] 的地方，是表示一份RFC或Wiki，可以在本文最后的【相关RFC和wiki】中找到其对应的地址。

【为啥要有ARF】
    随着垃圾邮件等问题日益严重，电子邮件服务提供商（Email Service Provider，ESP）之间或和一些第三方厂商之间会互相发送各种report（如abuse report），一开始不同厂商都DIY自己的report格式，无形间增大了接收方的阅读成本和阅读程序的维护成本。
    为了解决这类问题，需要有一份通用的标准协议来规范这些report的格式，这就是催生ARF的主要原因。
    其实ARF不仅用于abuse report这一类报表，还被 拓展到其他用途，如俺需要弄的这个[ AFRF]等。。。

【ARF简介】
    Abuse Report Format，ARF，于 2010年1月正式定义于RFC 5965号文档中，是IETF推荐的一份关于电子邮件report的协议。它定义了一种新的规范化报表格式，用于ESP发送各类abuse feedback report给其他第三方机构。
    ARF主要是基于[ REPORT]的 multipart/report [ MIME]类型扩展出一种新的 message/feedback-report [ MIME]类型，并基于这个新类型来重新定义一份报表格式。

    这份新报表格式有几点要求：
  1. 对人和对程序都可读。
  2. 需包含原始邮件的信息，至少需要包含其header部分（body部分可不包括）。
  3. 程序可读部分需按规范提供元信息（meta-data）。
  4. 格式是可扩展的（可以基于它来扩展出其他新格式）。


【ARF规范】
  1. multipart/report类型的report-type参数设置为 feedback-report 。
  2. 第一个[MIME] part为对人可读易读的信息，主要描述发送这份报告的原因等描述性信息，必要。content type可设为text/plain等，Content-Transfer-Encoding建议为7-bit。
  3. 第二个[MIME] part为对程序可读的信息，主要包含原始邮件的一些元信息（meta-data），必要。content type设为message/feedback-report（详见下文）。
  4. 第三个[MIME] part为原始邮件的信息，必要。content disposition设为inline，而content type有两种选择：
    5.    4.1  设为 message/rfc822（定义于[ MIME-TYPES]），内容为原始邮件的整体（header+body） 。
       4.2  设为 text/rfc822-headers（定义于[ REPORT]），内容为原始邮件的整个信头部分 
  5. 有些report产生方出于隐私等方面考虑，在第三个[MIME] part中不发送mail body部分，但IETF推荐发送 。
  6. 每一份report只能是关于某一封原始邮件，而不能将多封原始邮件的报告汇总在一份report里去发送。
  7. report的信头Subject字段内容需与原始邮件的信头Subject字段一致，但非强制，允许去掉原主题中的转发前缀（如FW:）。
  8. report接收方在做abuse分析和取证过程中，要先使用第三个[MIME] part的内容，其次才取第二个[MIME] part的内容。而第一个[MIME] part限用于解释性的可读信息，不能作为分析和取证之用。

【message/feedback-report定义】
  1. ARF定义了一种叫 message/feedback-report 的新[MIME]类型，此新类型已经在[IANA]注册。
  2. 此新[MIME]类型使用于report的第二个[MIME] part，记录着提取自原始邮件的各种元信息（meta-data），帮助report接收方的程序做分析工作。
  3. 其内容由各个字段（fields）组成，格式类似于[MAIL]的信头字段。包括一些必要字段（Required Fields）和一些可选字段（Optional Fields），这些字段也已经在[IANA]注册。
  4. 尽管这些fields和[MAIL] header fields的格式是一样的，但语义却不一样，所以这些fields的内容不能简单拷贝自原始邮件的信头相应字段。
  5. 必要字段（Required Fields，每个只能出现一次）：
    6.   5.1    Feedback-Type 本report的反馈类型，其可选的取值也已经在[IANA]注册，具体有：
    5.1.1    abuse 垃圾邮件。  
    5.1.2    fraud 伪造邮件，钓鱼邮件。  
    5.1.3    virus 病毒邮件。  
    5.1.4    not-spam 被误判为垃圾邮件的正常邮件。
    于2011年11月追加定义在一份建议性的RFC，见[ARF_追加]。 
    5.1.5    other 任何其他类型的邮件。  
      5.2    User-Agent 生成本report的程序名称和版本号，主要用于统计或debug，格式要求遵循[HTTP] section 14.43（形如User-Agent: CERN-LineMode/2.15 libwww/2.17b3）。 
      5.3    Version 本report的格式规范版本号（即[ARF]协议版本号），目前是1。 
     6.   可选字段1（Optional Fields，每个最多只能出现一次）：
           6.1    Original-Envelope-Id 原始邮件在[ SMTP]会话期间的ID信息，定义于[ DSN] section 2.2.1 。
6.2 Original-Mail-From 原始邮件在[ SMTP]会话期间的MAIL FROM命令内容，格式定义于[ SMTP] section 4.1.2 。
           6.3 Arrival-Date 原始邮件到达MTA的日期时间，格式同[ MAIL] section 3.3 （形如Tue, 20 Mar 2012 15:05:36 +0800 (CST)）。也可以取名为 Received-Date（以前的旧用法），但不可两者同时出现。
           6.4 Reporting-MTA 产生这份report的MTA的名称，格式同[ DSN] section 2.2.2。
           6.5 Source-IP Sender的IP地址，格式同[ SMTP] section 4.1.3。
           6.6 Incidents 这份report所代表的事件个数，一个32位无符号整数， 尚未搞明白这个字段的含义。
     7.   可选字段2（Optional Fields，每个可出现多次）：
7.1 Authentication-Results 记录原始邮件的身份验证结果，格式定义于[ AUTH-RESULTS] 。
7.2 Original-Rcpt-To 原始邮件在[ SMTP]会话期间的RCPT TO命令内容，格式定义于[ SMTP] section 4.1.2 。
7.3 Reported-Domain 原始邮件中导致产生这份report的可疑域名，格式定义于[ DSN] section 2.3.1 。
7.4 Reported-URI 原始邮件中导致产生这份report的可疑URI，内容格式多种多样，格式定义于[ URI]。

【ARF相关】
  1. 当report接收方发现某份report的格式不符合本规范，可以丢弃或直接在[SMTP]会话阶段就reject。
  2. 当report接收方发现某份report的格式中出现的字段不在本规范中，应忽略。（应注意Version字段的版本号，新版本号的协议可能会增删字段）
  3. 和[DSN]类似，当使用[SMTP]方式发送report时，可以使用空的[SMTP] envelope sender，当然也可以使用非空的sender，看report产生方的选择。
  4. 本协议仅做了report的内容规范工作，至于report的发送方式（[SMTP]，[HTTP](s) POST等），接收方的地址发布等其他工作不在本规范的讨论范畴。
  5. 不可避免地，会有一些闲得蛋疼的人故意制造出格式合法但其实是伪造的report，report接收方应小心这种情况，至少要做必要的身份验证（如[DKIM]，[SPF]，[SENDERID]，[SMIME]等），这方面的东东也不在规范的讨论范畴。
  6. [ARF] 的RFC文案最后的附录B里有几个report samples 。


【相关RFC和wiki】
欢迎转载！请转载时加上本博文的原始地址： http://blog.163.com/pandalove@126/blog/static/98003245201222062920800/


网易云新用户大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者陈俊平授权发布。


推荐博客