History & Overview J.D. Falk, Return Path Inc. Mail Abuse - - PowerPoint PPT Presentation

▶
history overview
SMART_READER_LITE
LIVE PREVIEW

History & Overview J.D. Falk, Return Path Inc. Mail Abuse - - PowerPoint PPT Presentation

Feb 03, 2024 488 likes •793 views

History & Overview J.D. Falk, Return Path Inc. Mail Abuse Reporting Format (MARF) Working Group IETF 77Anaheim, California, USA 1 Complaint Feedback Loops Rationale History ARF MARF History Installed Base

slide-1
SLIDE 1

History & Overview

J.D. Falk, Return Path Inc. Mail Abuse Reporting Format (MARF) Working Group IETF 77—Anaheim, California, USA

1
slide-2
SLIDE 2
  • Complaint Feedback Loops
  • Rationale
  • History
  • ARF ➠ MARF
  • History
  • Installed Base
  • Format Overview
2
slide-3
SLIDE 3

Complaint Feedback Loops

3
slide-4
SLIDE 4

end users receive spam

4
slide-5
SLIDE 5

they want to complain

5
slide-6
SLIDE 6

complaint mechanism

  • users click a “spam” button in

their mail client (MUA)

  • the message is returned to

their mailbox provider via an

  • ut-of-scope process
  • the mailbox provider collects

complaints, and processes them using their own out-of- scope logic

6 usually to improve their spam filters but spam filters don’t address the root cause, the source of the problem
slide-7
SLIDE 7

let’s share!

7 so a few mailbox providers started forwarding complaints to each other
slide-8
SLIDE 8 Report Spam USER Spam Filter Rules Complaint Processor FBL Processor FBL Subscriber Database SMTP ARF message subscriber FBL subscriber processes message, takes action SMTP 8
slide-9
SLIDE 9

Complaint Feedback Loop

  • generators
  • mailbox providers
  • a 3rd party working
  • n behalf of the

mailbox provider

  • consumers
  • hosting companies
  • ESPs
  • direct senders

(author or operator)

  • a 3rd party working
  • n behalf of the

author or operator

  • researchers
9
slide-10
SLIDE 10 subscriber abuse@example.com fbl@example.com 192.168.50.1 192.168.50.2 192.168.99.12 John Q. Example abuse@ Confirm FBL Subscriber Database ISP Approve 10 in nearly every case, the feedback flows from generator to consumer, or subscriber, by prior arrangement: the consumer requests feedback, and the generator decides whether to approve that request. in this example, the consumer’s abuse@ address is asked to confirm that this particular applicant is appropriately asking on behalf of that domain — a fairly common practice. however, the approval process is out of scope.
slide-11
SLIDE 11

What You Got

  • one new SMTP message per complaint

(just like forwarding)

  • headers & body dumped into body portion
  • f a new message (forwarding inline)
  • various encoding
  • various whitespace
  • sometimes explanatory text at the top
11 sometimes message/rfc822
slide-12
SLIDE 12

ARF

12
slide-13
SLIDE 13

ARF Timeline

  • “spam” button appeared around 1998
  • abuse reporting group formed in 2005
  • spinoff from MAAWG, plus a few experts
  • initially a closed discussion
  • feedback-report-00 — March 2005
13 general recollection is that AOL had the button first, and later it became standard in webmail clients; there was also Vipul’s Razor, a collaborative spam reporting system which became part of Cloudmark, who distribute a plugin for desktop MUAs
slide-14
SLIDE 14

ARF Timeline

  • larger, open discussion started
  • first implementations began to appear
  • feedback-report-02 — May 2007
  • already the de facto standard
14 we weren’t working very fast anymore, because a de facto standard was suffjcient
slide-15
SLIDE 15

ARF Timeline

  • feedback-report-04 — March 2008
  • added DKIM failure reporting
  • feedback-report-08 — October 2009
  • last non-IETF version
15
slide-16
SLIDE 16

MARF Timeline

  • draft-ietf-marf-base — January 2010
  • removed all report types not currently in

use (they can come back as extensions)

  • 1st MARF WG meeting
16
slide-17
SLIDE 17

Installed Base: ARF Generators

  • AOL
  • BlueTie
  • Comcast
  • Cox
  • Earthlink
  • Microsoft
  • RackSpace
  • Outblaze
  • Road Runner
  • Tucows
  • USA.net
  • Yahoo!
17 (12 biggest ARF generators by volume, in alphabetical order) just over half of these are operated by a 3rd party, and thus are on the same codebase I know of about a dozen more implementations in progress
slide-18
SLIDE 18

Known Outliers

  • ARF reports generated by an MUA
  • ARF reports sent to role accounts such as

abuse@ without prior arrangement (not recommended unless you are John Levine)

  • ARF reports generated from spamtrap

messages, rather than complaints

18 these aren’t necessarily out of scope, but they aren’t the primary use case
slide-19
SLIDE 19

MARF

19
slide-20
SLIDE 20

draft-ietf-marf-base

  • defines a new MIME type:

message/feedback-report

  • Determination of where these reports should

be sent, how trust among report generators and report recipients is established, and reports related to more than one message are outside the scope of this document.

20
slide-21
SLIDE 21

Stated Requirements

  • both human and machine readable
  • entire original email message enclosed
  • machine-readable meta-data
  • must be extensible
21
slide-22
SLIDE 22

Unstated Requirements

  • Must remain compatible with current

installed base of generators & consumers

  • Intended for software-to-software and

software-to-human communication, rather than human-to-software or human-to-human

  • Redaction (removing part of a message due

to privacy concerns) is going to happen

22 thus, while primarily machine-readable, it should also be at least as human-readable as standard email headers
slide-23
SLIDE 23

MIME parts

  • multipart/report

report-type: feedback-report

  • text/plain
  • message/feedback-report
  • message/rfc822 or

message/rfc822-headers

23
slide-24
SLIDE 24

text/plain portion

  • an entirely human-readable section,
  • ften containing canned boilerplate
24
slide-25
SLIDE 25

message/feedback-report

  • various header-like fields contain metadata
  • Note that these fields represent information

that the receiver report generator is asserting about the report in question, but are not necessarily verifiable. Report receivers MUST NOT assume that these assertions are always accurate.

25
slide-26
SLIDE 26

message/feedback-report required fields

  • Feedback-Type:
  • abuse
  • fraud
  • other
  • virus
  • User-Agent:
  • information only;

no registry

  • Version: 0.1
26 there used to be other feedback-types, but they weren’t used I believe the DKIM failure report type will be reintroduced as an extension, not aware of anyone intending to reintroduce the others
slide-27
SLIDE 27

message/feedback-report

  • ptional fields

appearing once

  • Original-Envelope-ID:
  • Original-Mail-From:
  • Arrival-Date:
  • Reporting-MTA:
  • Source-IP:
  • Incidents:

appearing multiply

  • Authentication-Results:
  • Original-Rcpt-To:
  • Reported-Domain:*
  • Reported-URI:
27
slide-28
SLIDE 28 28