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

From: SM <[email-masked]>
Date: Tue, 03 Jan 2012 12:11:23 -0800

Hi Alessandro,
At 04:38 29-12-2011, Alessandro Vesely wrote:
>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:

It's the beginning of the year.  I have some difficulty understanding 
what changes you suggested.

>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.]

I don't understand what change you are asking for as there is such 
text in Section 8.  Could you ask the editor of the document to 
generate a revision with your changes as it would be easier to read 
and comment?

BTW, as this draft is about an applicability statement, I would 
expect it to be clear about how the technical specifications it 
references should be used.  Text such as "Provider generating the 
reports SHOULD NOT assume that the operator receiving" is more of an 
assumption that the key word will "make things happen" than some 
requirement that will help in the deployment of the specifications.

In my opinion, the document needs much more work to be ready for a Last Call.

Thanks,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Jan 2012 13:48:23 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Tuesday, January 03, 2012 12:11 PM
> To: Alessandro Vesely
> Cc: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt
> 

Do you have specific changes to draft-ietf-marf-as-02 you would like to see?

---

From: SM <[email-masked]>
Date: Tue, 03 Jan 2012 14:43:16 -0800

Hi Murray,
>Do you have specific changes to draft-ietf-marf-as-02 you would like to see?

It's easier for me if I do not to suggest text at this stage as I 
would like to review the draft if there is a publication request.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 Jan 2012 14:28:43 +0100

On 03.01.2012 21:11, SM wrote:
>> put in a common section.
> It's the beginning of the year.  I have some difficulty understanding what
> changes you suggested.

Moving the paragraphs from those numbered lists would alter their numeration.
 Personally, I don't like them to be numbered, since the numbers bear no
special meaning.  The subcompact feature worsens their appearance by
suggesting some sort of indivisibility.  I tend to associate that style with
some (mis)conceptions about ASes, and IMHO is unnecessary.

If denumbered, some of those paragraphs could be moved in a new section to be
entitled, say, "Handling Common to Both Solicited and Unsolicited Reports".

>> [Manual vs automated processing] concept needs to be stated, though.
> I don't understand what change you are asking for as there is such text in
> Section 8.

Yup, I just inserted the second sentence.

> Could you ask the editor of the document to generate a revision with your
> changes as it would be easier to read and comment?

I would post a patch, but I cannot find the xml anymore.  So Murray has to
insert those two snippets of text, if he likes to, from my previous message
http://www.ietf.org/mail-archive/web/marf/current/msg01605.html

I'd guess that's possible, since the concept was discussed already here
http://www.ietf.org/mail-archive/web/marf/current/msg01223.html

And the converse concept was discussed after I asked whether MUAs should
allow users to edit the human readable part, about here
http://mipassoc.org/pipermail/abuse-feedback-report/2009q3/000411.html

> In my opinion, the document needs much more work to be ready for a Last Call. 

+1, for the "unsolicited" part in particular

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 22:06:39 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Thursday, December 29, 2011 4:38 AM
> To: [email-masked]
> 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:
> [...]

It doesn't seem to me the document is improved any by common factoring points out of those two sections into one that's common for both.

Your comment does point out, however, that Section 8 should include a set of numbered "rules" as Sections 6 and 7 are; there's no reason for them to be inconsistent.  So I'll do that.

>   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.

I think "direct complaint submissions" in this context means that an unsolicited report is triggered by MUA action, not that the MUA complains directly to something found in a WHOIS database.  I'll adjust the wording.

>   2.  Reports can be used to instruct filters.

Section 3.1 of RFC6449 makes a vague allusion to this idea.  I don't think this AS needs to re-state it, unless that's known to be a popular use of feedback reports.

>   4.  "Feedback-Type: abuse" is fine for unsolicited reports too.

Copied.

>   5.  Ditto for other optional fields.

Copied.

> 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.

It doesn't strike me as reasonable to talk about receiving syntax and protocol requirements for the case where the feedback is unsolicited.  We'd basically be forcing processing requirements on a non-participant.

>   5.  Optional fields may vary in unsolicited feedback too.

Same deal; if they're not participating, that advice falls on deaf ears.  For the unsolicited case, we really can only speak to the sender.

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

Does it need to?  As I said above, Section 3.1 of RFC6449 talks about filtering resulting from complaints but doesn't say what kind of filtering.

> * 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.

I think that's a reasonable suggestion.  I'll add something for -04.

> * 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).

I think that's a MAY at best, but I'll see if I can work that in to the previous point as well.

> 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?

I'll change it to "report generators".

> 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.

OK.

> 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.]

OK.

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

There's a common practice in IETF documents to avoid putting normative stuff in Security Considerations, which is supposed to be strictly informative.  Not all documents follow this practice, but I prefer it.

That said:

>  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.

That seems reasonable.

>  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.

Do users have spam scores?  I don't know that that's a known implementation.  We'd need to flesh this out quite a bit more for it to fly.

>  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].

I think this is best added to the section on unsolicited reports, actually.

> 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.

I think this is already covered in general in RFC6449, to which the applicability statement draft refers.

Thanks, I'll go through the replies to this and prepare a new version.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 22:08:52 -0800

> Sent: Wednesday, January 04, 2012 5:29 AM
> To: [email-masked]
>  Personally, I don't like them to be numbered, since the numbers bear
> no special meaning.  The subcompact feature worsens their appearance by
> suggesting some sort of indivisibility.  I tend to associate that style
> with some (mis)conceptions about ASes, and IMHO is unnecessary.

I think the numbered bullets help insofar as it makes them easier to reference; e.g. "Section X, bullet Y of RFC Z" versus "in Section X of RFC Z, the Yth bullet down".  It's a minor point, however.

-MSK

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 26 Jan 2012 10:20:14 -0500

In
<[email-masked]>,
on 01/25/2012

>I think "direct complaint submissions" in this context means that an
>unsolicited report is triggered by MUA action, not that the MUA
>complains directly to something found in a WHOIS database.  I'll
>adjust the wording.

I thought that the wording was clear[1], since the provider would
hardly be forwarding reports not sent to it. However, I don't agree
that the end users shouldn't send reports to addresses located in
whois, only that it needs to be done carefully.

[1] Which doesn't preclude rewording it if that helps
    other readers.

-- 
     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)