Subject: [marf] WGLC starting for draft-ietf-marf-base-01

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Apr 2010 12:11:27 -0700

Sorry for the delay starting this, but let's get it underway!

I've just posted draft-ietf-marf-base-02, containing minor changes since -01 having to do with Reported-Domain and Reported-URI as discussed on the list.

Working Group Last Call for draft-ietf-marf-base-02 is now in effect, lasting for two weeks and thus ending on April 20th.  Please review it and submit comments by then.  A new revision will be produced (if needed) and then we will submit it to the IESG for IETF-wide last call and evaluation.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 09 Apr 2010 20:01:49 +0200

"Reported-Domain" is unspecified by design. Fine :-( However, it is 
not clear whether it may appear multiple times even if the report 
covers a single incident.

As for using "Reported-URI" for the spamvertized mailbox, I just note 
that IODEF's draft-cain-post-inch-phishingextns (now in LC) calls that 
"Collection Site". The phrase "a URI to which the report recipient can 
go for further details", instead, suggests something like

  http://example.com/arf-generators/XYZ-v1.04b/meaning-of-fields.html

I propose to replace that phrase with just "See next Section 3.4". 
(Will there be an applicability statement to clarify how meanings may 
be negotiated, eventually?)

Section 7.3 still says "MAIL FROM:<>". See the end of 
http://www.ietf.org/mail-archive/web/marf/current/msg00641.html

Should the security section mention that automatically forwarding an 
abuse report to the wrong party may leak sensible information, 
especially if the report had been inadvertently generated by a user? 
(The intro says something about supporting mail clients.)

Should "http://www.mipassoc.org/arf/" in the examples be replaced with 
something with like the first http link above? (Should the spec 
RECOMMEND that the meaning of fields is stated that way?)

In appendix B2, the Authentication-Results looks bogus. In addition, 
the caption says "Example 3" rather than 2.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 12 Apr 2010 13:28:21 -0600

On Apr 9, 2010, at 12:01 PM, Alessandro Vesely wrote:

> As for using "Reported-URI" for the spamvertized mailbox, I just note that IODEF's draft-cain-post-inch-phishingextns (now in LC) calls that "Collection Site". The phrase "a URI to which the report recipient can go for further details", instead, suggests something like
> 

Reported-URI should be a URI copied from (or perhaps derived from) the message being reported.  It's not intended for documentation about the report itself.

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 12 Apr 2010 21:38:59 -0400

(Thanks to all for shepherding this along)

Here are my comments:

In section 1.1:
Do we need to add something about end-user clients and their ISPs
communicating about spam as mentioned in the introduction? Kind of
like the "Report Spam" button in the MUA

In section 1.2:
Are we using "must" in its [KEYWORDS] context?

In section 3.1:
"The following report header fields MUST appear exactly once:"

should we add

"...exactly once in no particular order" or "...exactly once with no
particular order dictated by this specifiction"

Same for sections 3.2 and 3.3

Section 3.1, "Version":
Should we change to "1" or "1.0" like MIME?

Section 3.2, "Incidents":
The spec mentions several times before that multiple or aggregate
reports are not covered. Yet this field covers that. We need to insert
some text addressing that

Section 3.2, "Received-Date":
Provisions needs to be made in the IANA registry that fields can be
marked as historic.

Section 3.3, "Reported-Domain":
Should Reported-URI be encouraged instead, as per RFC 4501 and
"Reported-Domain" be historic

Section 3.3, "Reported-URI":
Same text for the "Reported-Domain" field should apply to "URI"

Section 3.5:
Are we mandating an specific order for fields?

Section 5:
Isn't calling for experimental codes to be rejected a bit harsh? Also,
by "experimental result codes" - do you mean feedback types or
experimental fields?

Sections 6-7:
Should we add some sort of status field that indicates whether a given
field or feedback type is historic, obsolete or in current use as per
above regarding "Received-Date"?

Section 7:
This conflicts with what we wrote above regarding leaving <> usage to
the operator discretion

Section 7.5: - I would even add that people may attach viruses or
malware to ARF reports, but at the same time, since ARF messages may
be used to report viruses, they may contain them by design. We might
want to say that viruses and malware may be carried in ARF reports, so
people should exercise caution. On the other hand, they should not
reject reports containing viruses since they may be legit.

Thanks

---

From: SM <[email-masked]>
Date: Tue, 13 Apr 2010 01:08:24 -0700

At 12:11 06-04-10, Murray S. Kucherawy wrote:
>Working Group Last Call for draft-ietf-marf-base-02 is now in 
>effect, lasting for two

There is a typo for "original" in Section 2, Item d.

In Section 5:

    Result codes not beginning with "x-" MUST be registered as
    described above and appropriately published.

Is that for feedback report types?  What is the meaning of 
"appropriately published"?

The example in B.1 has the "From:" before the "Received:" header field.

>covers a single incident.

According to Section 3.3, it may appear more than once.

>(The intro says something about supporting mail clients.)

The above seems to relate to information disclosure to third-parties.

>Should "http://www.mipassoc.org/arf/" in the examples be replaced 
>with something with like the first http link above? (Should the spec 

It could be replaced with the RFC number.

>the caption says "Example 3" rather than 2.

The text about the example could precede the example to stand out.

>like the "Report Spam" button in the MUA

I don't think so.

>Are we using "must" in its [KEYWORDS] context?

No.  The requirements are as from Section 2.

>Should we change to "1" or "1.0" like MIME?

It's not a good idea for this specification to take the same road as 
the MIME version. :-)

According to the text, the version follows the specification, i.e. 
the integer is incremented.

>some text addressing that

Item e in Section 2 defines that as out of scope.

>Same text for the "Reported-Domain" field should apply to "URI"

"Reported-Domain" could be dropped and "Reported-URI" used instead.

>Are we mandating an specific order for fields?

I don't see any mention of ordering in the draft.  Would implementers 
assume that on reading the draft?

>by "experimental result codes" - do you mean feedback types or

If extension types can only be used between consenting parties, I 
assume that the receiver of the ARF got an invalid or misdirected report.

The sentence could be rewritten as:

   Extension report types beginning with "x-" MUST only be used
   between ADMDs that have explicitly consented to use them.
>above regarding "Received-Date"?

The type would be marked as Obsolete.

>This conflicts with what we wrote above regarding leaving <> usage to

Yes.  The "must" may be misinterpreted.

>reject reports containing viruses since they may be legit.

It may fit under a new sub-section that discusses about payload.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 13 Apr 2010 11:49:07 +0200

> It could be replaced with the RFC number.

However, for some field it "is unspecified how the report generator 
determines this information, and thus the report receiver cannot be 
certain how it was chosen." It may be helpful if each implementation 
gives full details on fields that the RFC describes as 
implementation-defined behavior.

> assume that on reading the draft?

Section 3.5 says

  A set of fields satisfying this ABNF may appear in the transmitted
  message in any order.

I agree the spec would be more readable if a similar sentence appeared 
also near the beginning of section 3.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Apr 2010 10:19:29 -0700

[as participant]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alessandro Vesely
> Sent: Friday, April 09, 2010 11:02 AM
> To: [email-masked]
> Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01
> 

I disagree.  It's clearly in the "Optional Fields Appearing Multiple Times" section.

>   http://example.com/arf-generators/XYZ-v1.04b/meaning-of-fields.html

I think I agree that this is somewhat ambiguous.  To those who are using ARF now: How do you use this field?  Is it a URI found in the offending message, or is it a reference URI for further action by the ARF recipient?  If the latter, it is probably mis-named.  If it could be either, I suspect the text should indicate that the provided URI might and might not be taken from the message.

> be negotiated, eventually?)

Do you have text to propose? :-)

> http://www.ietf.org/mail-archive/web/marf/current/msg00641.html

Ah right.  I'll remove 7.3.

> (The intro says something about supporting mail clients.)

Isn't that true of any email?

> RECOMMEND that the meaning of fields is stated that way?)

As it's just an example, I don't think this is a critical change.  What might be useful would be something in an earlier section RECOMMENDing the leading text/plain section include a reference to a document decoding ARF messages, at least during a rollout period.

> the caption says "Example 3" rather than 2.

Fixed.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Apr 2010 10:21:49 -0700

> J.D. Falk
> Sent: Monday, April 12, 2010 12:28 PM
> To: Message Abuse Report Format working group
> Reported-URI should be a URI copied from (or perhaps derived from) the
> message being reported.  It's not intended for documentation about the
> report itself.

How about this (pardon the XML and indenting)?

                                <t> "Reported-URI" indicates a URI that the
                                    report generator believes to be relevant
                                    to the report, e.g. a suspect URI that was
                                    found in the message that caused the report
                                    to be generated.  URI format is defined
                                    in <xref target="URI"/>. </t>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Apr 2010 10:50:24 -0700

> Yakov Shafranovich
> Sent: Monday, April 12, 2010 6:39 PM
> To: [email-masked]

I think that's generally included in the second bullet point of 1.1, but I wouldn't mind being more explicit about it, especially the "Report Spam" button idea.  The ASRG recently had a huge thread about that specific topic.

> Are we using "must" in its [KEYWORDS] context?

Not at that point.  We're just describing the impetus for the work, not establishing normative compliance requirements.

> Same for sections 3.2 and 3.3

The absence of an order seems to say both of those things to me anyway, but if people feel it should be explicitly stated, we can add it.

> Should we change to "1" or "1.0" like MIME?

I don't think it's necessary.  DKIM and Authentication-Results use integer versions.  Do people have a preference?

> some text addressing that

...or remove the text that conflicts with this field.   I'd prefer to do the latter; there's some drive in industry to have this capability.

Section 2 point e says "Except as noted below...", which allows for Incidents as defined.  Are there other references to this issue that need to be "smoothed"?

> Provisions needs to be made in the IANA registry that fields can be

How about this in the IANA section describing the field registry?

                        <t> An update may make a notation on an existing
                            registration indicating that a registered field
                            is historic or deprecated if appropriate. </t>

> "Reported-Domain" be historic

I think both are still in use.  What's consensus here?

> Same text for the "Reported-Domain" field should apply to "URI"

Done.

I don't think so.

> by "experimental result codes" - do you mean feedback types or

The text that's there was required by the SECDIR review of RFC5451.  I'm just heading them off at the pass.

> reject reports containing viruses since they may be legit.

How's this?

                <section anchor="sc-viruses" title="Attached Malware">
                        <t> As this format is sometimes used to automatically
                            report malware, ARF processors (human or otherwise)
                            should be cautious about unpacking and executing
                            any attachments that are part of the message
                            being reported. </t>
                </section>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Apr 2010 11:05:59 -0700

> From: SM [mailto:[email-masked]]
> Sent: Tuesday, April 13, 2010 1:08 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy; Alessandro Vesely; Yakov Shafranovich

Fixed.

> "appropriately published"?

I've reworked that section a little now.  The new text is:

                <t> Like many other formats and protocols, this format may
                    need to be extended over time to fit the ever changing
                    landscape of the Internet.  Therefore, extensibility is
                    provided via two IANA registries: one for feedback types
                    and a second for report header fields.  The feedback type
                    registry is to be used in conjunction with the
                    "Feedback-Type" field above.  The header name registry is
                    intended for registration of new meta-data fields to be
                    used in the machine readable portion (part 2) of this
                    format.  Please note that version numbers do not
                    change with new field registrations unless a new
                    specification of this format is published.  Also note that
                    all new field registrations may only be registered as
                    optional fields.  Any new required fields REQUIRE a new
                    version of this specification to be published. </t>

                <t> In order to encourage extensibility and interoperability
                    of this format, implementors MUST ignore any fields or
                    report types they do not explicitly support. </t>

                <t> Additional report types (extension report types) or
                    report header fields might be defined in the future by
                    later revisions to this specification, or by
                    registrations as described above.  Extension report types
                    and report header field names beginning with "x-" will
                    never be defined as standard; such names are reserved for
                    experimental use.  Report types and report header field
                    names not beginning with "x-" MUST be registered as
                    described above and published in an RFC. </t>

                <t> Implementations using new report types or new report
                    header fields MUST use the "x-" prefix until such time as
                    the new name is registered by IANA. </t>

                <t> Extension report types and report header fields MUST only
                    be used between ADMDs that have explicitly consented to
                    use them.  These names and the parameters associated with
                    them are not documented in RFCs.  Therefore, they are
                    subject to change at any time and not suitable for general
                    use.  Any MTA, MUA or filter intended for production use
                    MUST ignore or reject any ARF report that uses an
                    extension name. </t>

> The example in B.1 has the "From:" before the "Received:" header field.

That's not technically illegal, is it?  But I'll swap them.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Apr 2010 11:08:23 -0700

> Sent: Tuesday, April 13, 2010 2:49 AM
> To: [email-masked]
> with

The field you're talking about here is the first MIME part, which is text/plain and free-form.  We can't mandate its content, but can make suggestions about it.

> also near the beginning of section 3.

The absence of a specification of order to me is an implicit statement that order is not important.  Do others feel that this needs to be explicit?

---

From: SM <[email-masked]>
Date: Tue, 13 Apr 2010 11:28:11 -0700

Hi Alessandro,
>  A set of fields satisfying this ABNF may appear in the transmitted

I missed that. :-)

>I agree the spec would be more readable if a similar sentence 
>appeared also near the beginning of section 3.

   "The body of this content type consists of multiple "fields" formatted
    according to the ABNF of [MAIL] header fields.  The header fields may
    appear in the transmitted message in any order."

The "A set of fields satisfying this ABNF may appear in the 
transmitted  message in any order." could be removed.

BTW, even without this, I would not presume that the fields should be 
in any order.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Tue, 13 Apr 2010 11:52:57 -0700

>I think both are still in use.  What's consensus here?

Choose one and avoid getting into historic as it's difficult to get rid of.

>                             any attachments that are part of the message

How about:

  Malware

  ARF processors (human or otherwise) should be cautious about executing
  any content when the original message is included in its entirety.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Tue, 13 Apr 2010 13:56:21 -0700

Hi Murray,
>                     version of this specification to be published. </t>

This is more of a comment to get a clearer view.  We have two types 
of Report Header Fields, those that are required and those that are 
optional.  The optional header fields can be used to extend ARF.  The 
Version number is incremented if we change the list of required 
header fields or if we define new feedback types.  This required a 
revision of this specification.

>                     report types they do not explicitly support. </t>

Ok.

>                     the new name is registered by IANA. </t>

You already reserved "x-" for experimental use.  I suggest dropping 
the requirement that implementations must use "x-".

You could change the end of the previous paragraph to:

   Extension report types  and report header field names beginning with
   "x-" will never be registered in the "Feedback Report Header Fields"
   registry or the "Feedback Report Type Values" registry; such
   names are reserved for experimental use.

   Report types and report header field names must be registered as
   described in this memo and published in an RFC.

This does not IETF review; it's only a "RFC Required".  This leaves 
it to implementors to extend ARF without setting the bar too high.

>                     MUST ignore or reject any ARF report that uses an

We are interpreting extensibility differently.  The above seems to 
refer to "x-".  That can be used between ADMDs that have explicitly 
consented to it.  I suggest dropping this paragraph as it has already 
been covered by other text.

>That's not technically illegal, is it?  But I'll swap them.

It is not compliant with the RFC 5321.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Apr 2010 14:54:09 -0700

> Sent: Tuesday, April 13, 2010 1:56 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: RE: [marf] WGLC starting for draft-ietf-marf-base-01
> 

SECDIR had a concern in the past that this text be required, even though elsewhere there's guidance that unknown fields should be ignored.  I'm hesitant to remove it as they might push to have it re-added anyway, and I don't think it's harmful to have it there.

I hear your point about making it a barrier to entry though.

What do others think?

---

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

>                                    in <xref target="URI"/>. </t>

Yup, works for me.  Good catch, Alessandro -- I hadn't considered that "relevant to the report" might be interpreted as a link to help text.

> Item e in Section 2 defines that as out of scope.

The intention, IIRC, was to avoid having to deal with multiple message/rfc822 attachments.

> I don't see any mention of ordering in the draft.  Would implementers assume that on reading the draft?

Some have, but they quickly discover their mistake.

> I hear your point about making it a barrier to entry though.

There's enough precedent for X- from other standards that I'd prefer to keep it, even if it isn't strictly necessary.

---

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

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

>It is not compliant with the RFC 5321.

Technically it is not a violation for a message to have a From: prior to
the first Received: line. As a practical matter, the message will almost
always have passed through at least one SMTP server, in which case 4.4 of
RFC 5321 would apply.

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