Subject: [marf] I-D Action: draft-ietf-marf-as-02.txt

From: [email-masked]
Date: Wed, 28 Dec 2011 20:25:59 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

	Title           : Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
	Author(s)       : J.D. Falk
                          M. Kucherawy
	Filename        : draft-ietf-marf-as-02.txt
	Pages           : 7
	Date            : 2011-12-28

   RFC 5965 defines an extensible, machine-readable format intended for
   mail operators to report feedback about received email to other
   parties.  This document describes common methods for utilizing this
   format for abuse reporting.  Mailbox Providers of any size, mail
   sending entities, and end users can use these methods as a basis to
   create procedures that best suit them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-as-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-02.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 28 Dec 2011 20:30:39 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, December 28, 2011 8:26 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [marf] I-D Action: draft-ietf-marf-as-02.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Messaging Abuse Reporting
> Format Working Group of the IETF.
> 
> 	Title           : Creation and Use of Email Feedback Reports: An
> Applicability Statement for the Abuse Reporting Format (ARF)
> 	Author(s)       : J.D. Falk
>                           M. Kucherawy

This version contains feedback from John and Alessandro that seemed to jive with recent conversations on the list and also among some private reviewers.  Please review it and provide feedback, even if it's just of the "I've read this and I agree with what it says" variety.

I believe Alessandro has some suggestions to make in addition to what's there if the Working Group concurs.  I'll let him get that rolling.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 29 Dec 2011 13:38:13 +0100

On 29/Dec/11 05:30, Murray S. Kucherawy wrote:
> 
> I believe Alessandro has some suggestions to make in addition to
> what's there if the Working Group concurs.  I'll let him get that
> rolling.

Yes, and also some comments on what is already in the draft, or
missing pieces that have been discussed and agreed already but didn't
find their place in the draft.

Sections 6 and 7 are dedicated to solicited feedback.  However, there
is a number of points that should be valid also for unsolicited
reports.  If the order is not important, the common points could be
put in a common section.  Specifically, for the sending part, Section
6, here's the points I think should be common and why:

  1.  End-users report to mailbox providers, they shouldn't go
      searching whois databases and similar stuff.  This point is
      partially repeated already in Section 8, where it says that
      sending criteria "might include direct complaint submissions
      from MUAs".  Using ARF for MUA-to-MP is not discussed.
  2.  Reports can be used to instruct filters.
  4.  "Feedback-Type: abuse" is fine for unsolicited reports too.
  5.  Ditto for other optional fields.

By contrast, points (3) and (6) cover solicited-specific stuff.

For the receiving part, Section 7, the points are:

  2.  ARF over SMTP is fine for unsolicited feedback too.
  5.  Optional fields may vary in unsolicited feedback too.

Note that for point (6), the actions, only Section 4.3.1 of RFC 6449
is useful as-is for unsolicited feedback.  The rest of Section 4.3 of
that RFC contains (also) solicited-specific advice.  Three notes:

* Neither the RFC nor the draft mention degrading the offending IP's
  profile at the firewall.

* The RFC says replying to feedback is useless.  For unsolicited
  feedback, especially the first times it's being sent, some sort of
  acknowledge may be meaningful.

* Both senders and receivers should keep a database of contacts and
  annotate it regularly.  The draft only mentions such operations for
  the solicited case, referring to Section 4.4 of the RFC --point (3).

For Section 8, unsolicited complaints, the second paragraph needs to
clarify that "Senders" means "mailbox providers who are forwarding
their users' complaints".  We are not stopping end-users from
reporting to whoever they like, e.g. SpamCop, are we?

This WG already agreed that ARF messages are automated and the
human-readable part is boilerplate.  Conversely, technical data for an
abuse team has to be sent in non-ARF messages unless it can fit into
the provided ARF fields.  This concept needs to be stated, though.
The beginning of the third paragraph of Section 8 can be changed so as
to read like so:

 Recipients of unsolicited ARF reports SHOULD, in general, handle them
 the same way as any other abuse reports.  However, they can take
 advantage of the ARF format to automate processing.  Lacking [etc.]

The converse can be put in the beginning of the last paragraph of
Section 8, e.g. like so:

 Published abuse-mailbox addresses SHOULD NOT reject non-ARF
 messages, because producing ARF messages may occasionally be
 unavailable or not-applicable.  Nevertheless some large messaging
 service providers specifically request that [etc.]

Finally, I propose to add the following paragraphs to the Security
Considerations section:

 Mailbox Providers SHOULD perform any possible checks to ascertain
 that the messages reported by their users, that they are about to
 report in turn, really originated at the domain they intend to
 forward it to.  This includes checking that the reporting user did
 not inadvertently or maliciously alter the reported message.  Mailbox
 Providers MAY digitally sign received messages on delivery in order
 to perform this check.

 Mailbox Providers SHOULD manually inspect the messages reported by
 their users if their spam score is noticeably low --which might
 indicate that the user hit the spam-button by mistake.

 Mailbox Providers should evaluate the trustworthiness of the target
 abuse team, possibly using external reputation providers.  It is not
 worth to send any information to domains that exist for the sole
 purpose of spamming.  Mailbox Providers MAY redact the reported
 message, according to its policy and to the reputation of the
 destination.  Redacting techniques are discussed in [REDACT].

 The obvious correction for an acknowledged policy contravention is to
 remove the email address of the original recipient from whatever
 storage it was retrieved from for sending the reported message,
 including mailing lists.  An abuse team may need to investigate
 whether email addresses are stored legitimately on their customer's
 systems, or if any malware is running there.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 29 Dec 2011 14:05:35 -0500

In <[email-masked]>, on 12/29/2011

>* Neither the RFC nor the draft mention degrading the offending IP's

I assume that you mean RFC 6449 and not RFC 5965.

>* The RFC says replying to feedback is useless. 

I don't see that, although I do see "not necessary".

> The obvious correction for an acknowledged policy contravention
> is to remove the email address of the original recipient from
> whatever storage it was retrieved from for sending the reported
> message, including mailing lists. 

I would say that the obvious for an acknowledged policy contravention
is to remove all email address that contravene the policy, not just
the one in the ARF report. Failing to do so could lead to blocking of
the sending IP or IP block.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 31 Dec 2011 12:55:57 +0100

> I assume that you mean RFC 6449 and not RFC 5965.

Yes, RFC 6449 and draft-ietf-marf-as.

For example, I have a script that bans an IP for a year, at the firewall
level.  I call it for intractable spammers.  The script checks the IP, and if
it finds SMTP listening there, it sends an ARF message there, RCPT TO:
<postmaster>, telling them it is about to ban the IP.  It rarely works, but
sometimes sorts a visible effect.

Neither of those methods are mentioned in either the RFC or the draft.

> I don't see that, although I do see "not necessary".

Yes, the Third thing in Section 4.3 of the RFC.  For unsolicited feedback,
consider the first ARF messages that an MTA submits to a given consumer.
MTAs should keep a database of consumers that they send feedback to.  New
entries in the database need to be assessed, and a reply in such cases would
be useful.  For example, the feedback generator could add a Reply-To field to
the header of the ARF messages in case it wishes to receive an acknowledge.

> the sending IP or IP block.

Yes, you already said so on 4 Sep, in the last paragraph of
http://www.ietf.org/mail-archive/web/marf/current/msg01289.html
I amended that paragraph in my working copy, by adding the sentence that you
did not quote.  Then I proposed it for the Security Considerations of marf-as.

As there is no non-invasive established method to prove subscriptions (yet) I
don't think it could make much sense to suggest to carry out such kind of
check, e.g. by asking each user to reconfirm subscription.

---

From: "John Levine" <[email-masked]>
Date: 31 Dec 2011 15:25:09 -0000

This seems way, way, over-detailed for an Appliability Statement.

As I understand it, and AS is intented to answer basic questions about
"what do you use this for"?  In the case of ARF, the answer is that
mostly you use it in private FBLs, but we've found that you can also
use it for normal abuse reports.  That's it.

When we have more experience with using ARF in abuse reports, we might
put some of this stuff in a BCP, but since I don't know anyone other
than me who has much experience using them in abuse reprots, that
seems rather premature.

R's,
John