Subject: [marf] Require body?

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 13 Apr 2010 08:21:53 -0400

If MARF is used to report a drop box, then the receiver will probably need
to see the body of the original message before taking action. Should there
be something like "MUST use message/rfc822 when reporting drop boxes."?

-- 
     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: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Apr 2010 12:02:41 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shmuel Metz
> Sent: Tuesday, April 13, 2010 5:22 AM
> To: Message Abuse Report Format working group
> Subject: [marf] Require body?
> 

I'm unclear on how this would fit into the current ARF specification.  Isn't drop box reporting out of scope for the base draft?

---

From: John Levine <[email-masked]>
Date: 13 Apr 2010 19:35:38 -0000

>I'm unclear on how this would fit into the current ARF specification.
>Isn't drop box reporting out of scope for the base draft?

You could send an ARF report with the reported URL being mailto:drop@box.

But a MUST puts us back into King Canute land.  ISPs will redact what
they want to redact, and there's nothing we can do about it.  This
suggests that no changes are needed to handle drop boxes.

R's,
John

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 Apr 2010 17:49:36 -0400

I would add that this may be something more suitable for a followup
RFC discussing best practices.

On Tue, Apr 13, 2010 at 3:35 PM, John Levine <[email-masked]> wrote:
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf
>

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 13 Apr 2010 16:04:04 -0600

> be something like "MUST use message/rfc822 when reporting drop boxes."?

This is getting awfully close to dictating how the report recipient manages their network.  The format -- which is all we're defining here -- doesn't care if they want to disable an account based on flimsy evidence.

I wouldn't argue too vociferously against a SHOULD, but I think it's unnecessary.

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 14 Apr 2010 05:46:02 -0400

In <[email-masked]>, on 04/13/2010
   at 04:04 PM, "J.D. Falk" <[email-masked]> said:

>This is getting awfully close to dictating how the report recipient
>manages their network. 

It would be a requirement on the sender, not on the recipient.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 14 Apr 2010 05:32:21 -0400

In <[email-masked]>, on 04/13/2010

>You could send an ARF report with the reported URL being mailto:drop@box.

Yes, but would an ISP pay attention to it if it did not contain the
message body with that URL?

>But a MUST puts us back into King Canute land. 

Doesn't that describe sending a complaint without supporting evidence?

>ISPs will redact what they want to redact,

Sure, but an RFC can describe what is compliant with that RFC.

Would an ISP be willing to act on a drop-box complaint if it were unable
to see the drop box in the context of the message purportedly containing
it?

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 14 Apr 2010 05:26:44 -0400

In
<[email-masked]>,
on 04/13/2010

>Isn't drop box reporting out of scope for the base draft?

1.1.  Purpose includes the text "or related to"; that would appear to
apply to drop boxes. If drop boxes are out of scope then 1.1 should be
reworded to make the scope clearer.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Apr 2010 10:56:33 -0700

> Sent: Wednesday, April 14, 2010 2:27 AM
> To: [email-masked]
> Subject: Re: [marf] Require body?
> 
> In

Actually I don't like the current format of 1.1, now that you mention it.

How's this?

                        <t> The reports defined in this document are intended
                            to inform operators about:

                            <list style="symbols">
                                <t> email abuse originating from their
                                    networks; </t>

                                <t> potential issues with the perceived
                                    quality of outbound mail, such as email
                                    service providers sending mail in a format
                                    that causes automated abuse detection
                                    systems to consider it suspect. </t>
                            </list> </t>

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Fri, 16 Apr 2010 05:43:07 -0400

In
<[email-masked]>,
on 04/15/2010

>How's this?

Unambiguous. If it really reflects the intent of MARF then I'd say go for
it.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 Apr 2010 12:53:27 +0200

>                              to inform operators about:

Since the previous section is fairly generic, IMHO this should be more 
specific, e.g. "mail operators", or "mailbox providers and email 
service providers".

>                                      networks;</t>
>                                      systems to consider it suspect.</t>

IMHO this may be less specific, so as to broaden the class of 
exemplified uses; e.g. "such as email service providers sending mail 
that causes problems with abuse detection systems."

>                              </list>  </t>

Do you mean to drop the last paragraph ("Please note [...] and SHOULD 
NOT be used for other reports.")?

It is still unclear whether this section is meant to also cover future 
extensions. I don't think we want to limit possible uses of ARF. 
However, we may inform about alternative formats for reporting email 
messages: rfc3462 for end users, and the upcoming 
draft-cain-post-inch-phishingextns for network providers. Adding such 
information may identify by exclusion our niche of treatable abuses 
that are neither delivery errors nor manifest attacks.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 16 Apr 2010 10:33:57 -0700

> Alessandro Vesely
> Sent: Friday, April 16, 2010 3:53 AM
> To: [email-masked]
> Subject: [marf] Section 1.1 (was: Require body?
> 

+1

> that causes problems with abuse detection systems."

How about:

                                <t> potential issues with the perceived
                                    quality of outbound mail, such as email
                                    service providers sending mail that
                                    attracts the attention of automated abus
                                    detection systems. </t>

> NOT be used for other reports.")?

Nope, that hasn't been removed.  I just didn't cite it.

> that are neither delivery errors nor manifest attacks.

The abstract says that the format is extensible, and I think that's obvious once one looks down at the IANA stuff.  And ARF is based on RFC3462 (it's a normative reference), so I'm a little confused as to your intent here.  Can you propose some text?

I think the focus is clearly on reporting about objectionable mail and not generic questionable network activity.  That said, we might want to make a reference to the INCH work early on and explain why all the sites that have gone with ARF did so instead of using INCH.  Some text about that (from such an operator on this list) would be really helpful, even if it's a statement that INCH was found to be too hard, or ARF was ready before INCH was, or such.