Subject: [marf] Comments on draft-ietf-marf-base-00

From: SM <[email-masked]>
Date: Sun, 07 Feb 2010 10:58:28 -0800

Hello,

I read draft-ietf-marf-base-00.  The comments below could be 
categorized as stylistic.

In Section 1:

   "This memo seeks to define a standard extensible format by
    creating the "message/feedback-report" [MIME] type for
    these reports."

The Abstract Section says that the "document defines an extensible 
format and MIME type".  I suggest changing the "seeks to define" to "defines".

    "While there has been previous work in this area (e.g.
    [STRADS-BCP] and [ASRG-ABUSE]), none of them have yet been
    successful."

The intended status of this document is Standards Track.  There is an 
informative reference to "Crissman, G., "Proposed Spam Reporting BCP 
Document", May 2005."  draft-shafranovich-feedback-report-05 had a 
URL for the document.  It's a 404 now.  There is an informative 
reference to "Anti-Spam Research Group (ASRG) of the Internet 
Research Task Force (IRTF), "Abuse Reporting Standards Subgroup oof 
the ASRG", May 2005." (oof is a typo).  If this is to acknowledge the 
work, it could be moved to the appropriate section if this document 
has a better fate.

In Section 1.2, there is a requirement that:

      "A copy of the original email message (both body and header) or the
       message header must be enclosed in order to allow the receiver to
       handle the report properly;"

Is a copy of the original required for the receiver to handle the 
report properly?  That sentence could be rephrased if this WG wants 
to allow redaction.

In Section 1.3.2:

   "See [EMAIL-ARCH] for further discussion on e-mail system
    architecture."

What does defining a format for abuse reporting have to do with this 
subsection?

In Section 2:

   "The Subject header field of the feedback report SHOULD be the
    same as the included email message about which the report is
    being generated and MAY include only a typical forwarding prefix
    used by MUAs such as "FW:".  (Many smaller operators using MUAs
    for abuse handling rely on the subject lines for processing.)"

There is already a SHOULD.  The "MAY include only" does not fit in 
well as a RFC 2119 requirement.  The sentence could be split into two 
and explain that the subject can have a "FW:" prefix.

In Section 3:

   "Although these fields have a syntax similar to those
    of mail message header fields, they are semantically distinct; hence
    they SHOULD NOT be repeated in the header area of the message
    containing the report."

"Header area" is ill-defined.  Can the fields be used in message headers?

In Section 3.1:

   "The format of this field MUST follow section 14.43 of [HTTP]."

I suggest having that reference as normative.

In Section 3.2, there are references to DSN and SMTP.  These are 
informative references in this document.

In Section 4:

   "Any new required fields REQUIRE a new version of this specification
    to be published."

It would be better to allow it be done through Standards Track documents.

In Section 5.2:

   "The expert should be appointed by the Area Director for the
    Applications Area."

Please let the IESG decide on the appointment.

In Section 6.2, what is the "purported sender"?

In Section 6.3:

   "Whenever an SMTP transaction is used to send an ARF
    message, the MAIL FROM command must use a NULL return address, i.e.
    "MAIL FROM:<>"."

Is that a requirement?

In Section 6.4:

   "It follows that any attack against the authentication methods
    supported by this document (and later amendments to it) is
    also a security consideration here."

Please remove later amendments as a security consideration as it is 
not possible to tell what that will be.

Regards,
-sm

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 7 Feb 2010 18:11:00 -0500

On Sun, Feb 7, 2010 at 1:58 PM, SM <[email-masked]> wrote:
> Document", May 2005."  draft-shafranovich-feedback-report-05 had a URL for
> the document.  It's a 404 now.  There is an informative reference to
> "Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF),
> "Abuse Reporting Standards Subgroup oof the ASRG", May 2005." (oof is a
> typo).  If this is to acknowledge the work, it could be moved to the
> appropriate section if this document has a better fate.
>

I believe that the first document can be found here:

http://mb.preciseic.net/shr/spam/bcp.html

The second is here:

http://asrg.sp.am/subgroups/abuse_reports.shtml

> Is a copy of the original required for the receiver to handle the report
> properly?  That sentence could be rephrased if this WG wants to allow
> redaction.
>

Another issue is that RFC 3462 defines part 3 as optional. I am not
sure if we can redefine it as required here.

> What does defining a format for abuse reporting have to do with this

I believe that the reference is for terms used in email architecture.
This will need to be more explicit.

> "Header area" is ill-defined.  Can the fields be used in message headers?

No they cannot be used as email headers.

> In Section 6.2, what is the "purported sender"?

It is a term used with email authentication drafts. We need a
reference to some document defining it.

>   message, the MAIL FROM command must use a NULL return address, i.e.

This follows a similar approach used in DSNs / RFC 3464, section 2:

"   The envelope sender address of the DSN SHOULD be chosen to ensure
   that no delivery status reports will be issued in response to the DSN
   itself, and MUST be chosen so that DSNs will not generate mail loops.
   Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
   command MUST use a NULL return address, i.e., "MAIL FROM:<>".
"

However, I am not sure if this is necessary here. It actually might be
a good idea to allow something in MAIL FROM so we can tell if an ARF
report bounces.

Yakov

---

From: SM <[email-masked]>
Date: Mon, 08 Feb 2010 01:59:42 -0800

Hi Yakov,
>http://mb.preciseic.net/shr/spam/bcp.html

The first paragraph of the document says that it is an 
Internet-Draft.  As I couldn't find any record of the I-D submission, 
I would not consider it as a valid reference.  The STRADS-BCP 
reference disappeared once before.  It isn't a stable reference.

>http://asrg.sp.am/subgroups/abuse_reports.shtml

The reference is not meaningful in my opinion unless you want to 
explain that such efforts are not successful.  You could have a 
variant of the last two sentences of that paragraph under Acknowledgements.

>sure if we can redefine it as required here.

Quoting RFC 3462:

   "Return of content may be wasteful of network bandwidth and a variety
    of implementation strategies can be used.  Generally the sender
    should choose the appropriate strategy and inform the recipient of
    the required level of returned content required."

The above text explains why the body part (part 3) is optional.  In 
the case of delivery status reports, the body part isn't a 
requirement as the delivery status notification is sent to the email 
address specified in the return path.  The difference between DSN and 
ARF is that the operator does not have a copy of the original message.

For comparison, in Section 1.2:

Quoting from Section 1.2 of RFC 3464:

     "It must provide enough information to allow message senders (or
      the user agents) to unambiguously associate a DSN with the
      message that was sent and the original recipient address for
      which the DSN is issued (if such information is available), even
      if the message was forwarded to another recipient address."

The requirement (in this I-D) could be rephrased to include "enough 
information" so that the receiver can handle the report 
properly.  You can then expand on when the message header (only) or 
both the header and body is useful.  The discussion does not have to 
be in the Requirements Section.

It can be argued that part 3 should be included (it is not optional 
in the usual sense but it isn't a requirement) or possibly be a 
requirement.  It all depends on whether the report would be useful 
without the message headers and/or body.

>This will need to be more explicit.

The document only has one term from RFC 5598.  By the way, that term 
(ADMD) should be expanded in the I-D on first use.  If the reference 
is part of the definitions, the reference would have to be normative.

In Section 3:

Some implementers can be quite liberal in their interpretation of the 
specification.  It is better to have "should not be used" then.  I do 
not have a clear definition yet to suggest alternative text.

>reference to some document defining it.

The I-D mentions that reports can be crafted to generate undesirable 
actions in Section 6.2.  The I-D only has to recommend techniques 
which might help the receiver make a determination about the validity 
of the report.

>a good idea to allow something in MAIL FROM so we can tell if an ARF

If the report is automated, Section 4.5.5 of RFC 5321 is 
applicable.  If the format is used for direct feedback by end users, 
the null reverse-path is not required.  The approach used in RFC 3464 
is probably due to how email works;  there is a notification if the 
message cannot be delivered.  If ARF will cause mail loops, the null 
reverse-path should be considered as a requirement.

I am unsure about whether the DSN approach would be best here as it 
might be useful to know whether the report is being delivered.  The 
ARF message would cause a DSN to be generated in case of delivery failure.

Regards,
-sm

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 08 Feb 2010 08:20:57 -0500

In <[email-masked]>, on
02/07/2010
   at 06:11 PM, Yakov Shafranovich <[email-masked]> said:

>Another issue is that RFC 3462 defines part 3 as optional. I am not sure
>if we can redefine it as required here.

It's done all of the time. A SHOULD or MUST in the draft refers to the
MARF specifications in the draft, not to the Multipart/Report
specifications in RFC 3462. This is similar to the relation between RFC
5536 and RFC 5321.

>However, I am not sure if this is necessary here. It actually might be a
>good idea to allow something in MAIL FROM so we can tell if an ARF
>report bounces.

What about a MUST for the null reverse path if the report is automatically
generated and a MAY if it is manually generated?

-- 
     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: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 08 Feb 2010 08:23:40 -0500

In <[email-masked]>, on 02/07/2010

>properly?  That sentence could be rephrased if this WG wants  to allow

I believe that it would be a mistake to allow redaction unless there is a
flag indicating that the contents are redacted.

---

From: "John R Levine" <[email-masked]>
Date: 8 Feb 2010 08:47:10 -0500

> flag indicating that the contents are redacted.

That horse left the barn years ago.  Remember that we don't "allow" people 
to do anything, we write specs that we hope that parties hoping to 
interoperate will find it worth their while to implement.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Feb 2010 17:29:03 +0100

On 08/Feb/10 00:11, Yakov Shafranovich wrote:
> On Sun, Feb 7, 2010 at 1:58 PM, SM<[email-masked]>  wrote:
>>  In Section 6.3:
>>

+1. A loop-avoidance specification just needs to ensure that ARF 
reports are never reported as spam.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Feb 2010 11:00:39 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alessandro Vesely
> Sent: Monday, February 08, 2010 8:29 AM
> To: [email-masked]
> Subject: Re: [marf] Bounces (was: Comments on draft-ietf-marf-base-00
> 

What suggestions do you have for such a specification?

I'm a little worried that a rule like "Never generate an ARF report for a message that contains a MIME part of type message/feedback-report" will become a spam vector.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 8 Feb 2010 11:09:02 -0800

>> a good idea to allow something in MAIL FROM so we can tell if an ARF

Yup. If I'm running a feedback loop I'd really like to know if the consumer
of it has vanished or broken.

DSNs are quite different, as they're sent automatically to the return
path, rather than manually to somewhere else.

> 
> +1. A loop-avoidance specification just needs to ensure that ARF reports are never reported as spam.

It's an even lower bar - it just needs to ensure that inbound ARF reports are
never automatically trigger outbound ones. (If an ARF consumer hits
the TiS button and sends a spam report about an ARF formatted mail
manually it won't break anything).

I don't see a need for anything ARF-specific to break loops here.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Feb 2010 12:45:00 -0800

> SM
> Sent: Sunday, February 07, 2010 10:58 AM
> To: [email-masked]
> Subject: [marf] Comments on draft-ietf-marf-base-00
> 
> Hello,

Hi!

> format and MIME type".  I suggest changing the "seeks to define" to

Upon publication, it will be defining something, so I believe it's fine as-is.

> work, it could be moved to the appropriate section if this document

I'll fix the typo and it looks like a current URL has already been provided in a different reply.  But what would the appropriate section be if not the Informative References?

> report properly?  That sentence could be rephrased if this WG wants

Elsewhere in the text we already discourage but accept the redaction practice.  I don't think the introduction is a good place to start making normative assertions, but rather to give general intent.

> What does defining a format for abuse reporting have to do with this

Section 1.3 is all definitions.  EMAIL-ARCH discusses things like ADMDs which are mentioned in the ARF draft later on, so it seems to me that reference is appropriate.

> and explain that the subject can have a "FW:" prefix.

Actually I think it's sufficient just to change "MAY" to "may"; the "SHOULD" semantics seem to allow for that anyway.

> "Header area" is ill-defined.  Can the fields be used in message

Would changing "header area" to just "header" be sufficient?

The intent is to discourage the use of ARF fields, normally found in the second MIME part, in the actual message header.  They could be used there, of course, but a parser implementing ARF would probably not look there for them.

> I suggest having that reference as normative.

Yes, good point.

> informative references in this document.

Also correct.

> It would be better to allow it be done through Standards Track

Are those different things?

> Please let the IESG decide on the appointment.

Section 3.2 of RFC5226 says:

  Designated experts are appointed by the IESG (normally upon
   recommendation by the relevant Area Director).

So you're right, but basically I think we're saying the same thing.

> In Section 6.2, what is the "purported sender"?

It's intentionally not defined here.  An agent processing an ARF report, or indeed any message, makes some conclusion about who/what sent it based on header field heuristics.  I don't think we should presume to define such heuristics here.

>     message, the MAIL FROM command must use a NULL return address, i.e.

As has been pointed out, DSN does the same thing.  However, you're right that we don't specify this anywhere else in the document.  It sounds like this is under discussion now in another thread, but if this is something we want to assert then it needs to be done so normatively elsewhere.  We'll have to see where that other thread leads us.

> not possible to tell what that will be.

Yep, you're right.  How about this?

"It follows that any attack against an authentication method that might be used to protect the authenticity of an abuse report is also a security consideration here."

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 08 Feb 2010 12:59:39 -0800

On 2/8/2010 5:47 AM, John R Levine wrote:
> That horse left the barn years ago. Remember that we don't "allow"
> people to do anything, we write specs that we hope that parties hoping
> to interoperate will find it worth their while to implement.

A standard cannot /enforce/ anything, but it can /mandate/ particulars.  In 
fact, a standard that does not mandate anything isn't a meaningful standard.

The distinction between an entire message vs. a redacted message is significant, 
so that having the specify and (possibly also) mandate a means for flagging 
redaction is quite reasonable.

Unfortunately it naturally leads to the question of an inline notation for 
marking where redaction has been perfored...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Feb 2010 13:03:53 -0800

> Yakov Shafranovich
> Sent: Sunday, February 07, 2010 3:11 PM
> To: SM
> Cc: [email-masked]
> Subject: Re: [marf] Comments on draft-ietf-marf-base-00
> 

Thanks; I've updated that reference.  Hopefully that URL is reasonably permanent...

> report

I agree that we might meet some static by making that assertion.

Consider a message that purports to be ARF, but is missing the third part.  Then a parser can legitimately conclude that the message conforms to multipart/report, but does not conform to ARF.  I think that's acceptable based on the specifications, and would then be a matter for local policy to decide how to handle it.
 
> This will need to be more explicit.

How about:

"[EMAIL-ARCH] introduces several terms and concepts that are used in this memo, and thus readers are advised to become familiar with it as well."

> No they cannot be used as email headers.

So should that be a MUST NOT?  I'm not sure we can safely do that, as that would suggest they are not allowed in the general message header field registry.

> reference to some document defining it.

Actually I'd prefer we didn't.  What one parsing agent considers to be the purported sender may differ from the next.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Feb 2010 13:10:04 -0800

> Shmuel Metz
> Sent: Monday, February 08, 2010 5:24 AM
> To: [email-masked]

Given that we're tending toward making this format most useful by machines, how would they use that flag if it were set?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Feb 2010 13:26:12 -0800

> Sent: Monday, February 08, 2010 2:00 AM
> To: Yakov Shafranovich
> Cc: [email-masked]
> [...]

I like this approach, but it needs more thought to be included in a normative part of a specification such as Section 2d of this I-D.  In particular, I don't think we can use normative language where the decision is actually subjective; that is, I don't think one can write "You MUST do X unless you don't think the recipient will actually need it" because the sender doesn't know what software or internal processes may exist at the receiver.

I think we'd be much safer to say the third part MUST always be there.

> is part of the definitions, the reference would have to be normative.

ADMD is only used for discussion, so expanding it on first use is fine but I don't think it needs to be normative.  (Can an informational draft be normative anyway?)

> not have a clear definition yet to suggest alternative text.

I don't have a problem with that small change, except that it might fly in the face of later registrations of those names in the IANA header field registry.

> ARF message would cause a DSN to be generated in case of delivery

I can conceive of an automatically-generated ARF report where for example a spam filter is programmed to generate ARFs for suspect messages right at the MTA.  (We might even want to mention that as a possible DoS vector.)

If an ARF is generated without a NULL envelope sender but aimed at an address that doesn't work, then the generating address can also get bombed by DSNs.  But the tradeoff is that with the NULL sender, legitimate ARFs that don't get delivered are never detected.

Perhaps softening the language in 6.3 is appropriate; discuss both scenarios and the ramifications of each, and let the ADMD make its own decision.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 08 Feb 2010 13:29:49 -0800

On 2/8/2010 1:03 PM, Murray S. Kucherawy wrote:
> Consider a message that purports to be ARF, but is missing the third part.
> Then a parser can legitimately conclude that the message conforms to
> multipart/report, but does not conform to ARF.  I think that's acceptable
> based on the specifications, and would then be a matter for local policy to
> decide how to handle it.

+1

>> I believe that the reference is for terms used in email architecture. This
>> will need to be more explicit.
>
> How about:
>
> "[EMAIL-ARCH] introduces several terms and concepts that are used in this
> memo, and thus readers are advised to become familiar with it as well."

+1

>>> In Section 3:
>>>
>>> "Although these fields have a syntax similar to those of mail message
>>> header fields, they are semantically distinct;
>> hence
>>> they SHOULD NOT be repeated in the header area of the message containing
>>> the report."
>>>

Officially the structured bit at the beginning of a 5322 message is 'header 
fields'  The ABNF aggregate name is 'fields'.  The aggregate used to be called 
the 'header' but people used the word ambiguously, so the word by itself was 
dropped.

Given that the existing text first does say "header fields", it's saying "header 
area" in the same sentence (after the semi-colon) is likely to be clear to the 
reader.  However, yeah, it's probably less pristine, in a formal sense, than one 
might demand.

So perhaps,

    distinct; hence they SHOULD NOT be repeated as as header fields of the 
message containing the report."

>> It is a term used with email authentication drafts. We need a reference to
>> some document defining it.
>
> Actually I'd prefer we didn't.  What one parsing agent considers to be the
> purported sender may differ from the next.

I see the word 'purported' used only that one time and it isn't defined.  And 
I've registered my concern with ambiguity of the term 'sender' many times. 
Since this is a specification and the agent being called 'purported sender' has 
fundamental semantic and security implications, I do believe the relevant 
terminology needs to be defined and used carefully.

That said, this is a format spec, not a protocol spec.  So the obligations about 
identifying agents of action is limited.

However I also note that that section of 5.2 calls on using DKIM for validating 
content and, technically, DKIM doesn't do that...

So I'm going to suggest hacking the paragraph a bit, from:

>    It is recommended that ARF reports be vetted using common message
>    authentication schemes such as [DKIM], [SPF] or [SENDERID] to confirm
>    that they represent a valid message from the purported sender of the
>    report prior to the undertaking of any kind of automated action in
>    response to receipt of the report.

    It is recommended that the ownership of an ARF report be vetted, such as by 
  using common message accountability schemes such as [DKIM], [SPF] or 
[SENDERID], prior to the undertaking of any kind of automated action in response 
to receipt of the report.  The details of the required validation, to achieve 
this, are outside the scope of this specification.

d/
-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 8 Feb 2010 16:47:21 -0500

> I think we'd be much safer to say the third part MUST always be there.

multipart/report requires it, but it also says you can send just the
headers rather than the entire message.

Unless someone thinks there are a) ARF consumers who'd save
significant effort if they just got the headers or b) ARF producers
who would send feedback if it could just include the headers but not
if it had the whole (possibly redacted) message, this strikes me as an
option that adds complication without making anything work better.

>> not have a clear definition yet to suggest alternative text.

SHOULD NOT is right, don't do it unless you have a really good reason
to do so.

> If an ARF is generated without a NULL envelope sender but aimed at
   an address that doesn't work, then the generating address can also
   get bombed by DSNs.  But the tradeoff is that with the NULL sender,
   legitimate ARFs that don't get delivered are never detected.

Mailbombing and bounce storms due to junk mail is hardly a new
problem.  If we say anything, I'd just make it generic like don't
send reports if the recipients can't handle them.

R's,
John

---

From: SM <[email-masked]>
Date: Mon, 08 Feb 2010 15:39:07 -0800

Hi Murray,
>Upon publication, it will be defining something, so I believe it's fine as-is.

You can do that in an I-D without having to wait for 
publication.  It's fine with me if you want to wait.

>I'll fix the typo and it looks like a current URL has already been 
>provided in a different reply.  But what would the appropriate 
>section be if not the Informative References?

Yes but it is not a stable (long-lived) reference.  I suggest moving 
them to the appropriate section if you want to acknowledge the work.

I do not consider a reference to a document that has part of the 
boilerplate and which has not been submitted as an I-D as an 
appropriate reference.

>Actually I think it's sufficient just to change "MAY" to "may"; the 
>"SHOULD" semantics seem to allow for that anyway.

Yes but keep them in separate sentences.  I'll get back to this again 
after re-reading the text.

>Would changing "header area" to just "header" be sufficient?

I need to go through some RFCs before I answer.

>Are those different things?

Yes.

>So you're right, but basically I think we're saying the same thing.

It's the same.  But we generally leave it to the relevant RFC unless 
we require a different procedure.

>It's intentionally not defined here.  An agent processing an ARF 
>report, or indeed any message, makes some conclusion about who/what 
>sent it based on header field heuristics.  I don't think we should 
>presume to define such heuristics here.

Dave commented on this.

>As has been pointed out, DSN does the same thing.  However, you're 
>right that we don't specify this anywhere else in the document.  It 
>sounds like this is under discussion now in another thread, but if 
>this is something we want to assert then it needs to be done so 
>normatively elsewhere.  We'll have to see where that other thread leads us.

Okay.

>"It follows that any attack against an authentication method that 
>might be used to protect the authenticity of an abuse report is also 
>a security consideration here."

That's fine with me.  It might raise a nit during the security review.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 08 Feb 2010 15:44:24 -0800

Hi Murray,
At 13:03 08-02-10, Murray S. Kucherawy wrote:
>Consider a message that purports to be ARF, but is missing the third 
>part.  Then a parser can legitimately conclude that the message 
>conforms to multipart/report, but does not conform to ARF.  I think 
>that's acceptable based on the specifications, and would then be a 
>matter for local policy to decide how to handle it.

That sounds doable.

>How about:
>
>"[EMAIL-ARCH] introduces several terms and concepts that are used in 
>this memo, and thus readers are advised to become familiar with it as well."

That's fine.

>So should that be a MUST NOT?  I'm not sure we can safely do that, 
>as that would suggest they are not allowed in the general message 
>header field registry.

That's one of the questions I was thinking about as the I-D creates a 
"Feedback Report Header Fields" registry.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 08 Feb 2010 15:51:50 -0800

Hi Dave,
At 13:29 08-02-10, Dave CROCKER wrote:
>I see the word 'purported' used only that one time and it isn't 
>defined.  And I've registered my concern with ambiguity of the term 
>'sender' many times. Since this is a specification and the agent 
>being called 'purported sender' has fundamental semantic and 
>security implications, I do believe the relevant terminology needs 
>to be defined and used carefully.

Sender would be ambiguous as there is a reference to DKIM and SPF in 
that sentence.  It would be easier to drop "purported sender".

>That said, this is a format spec, not a protocol spec.  So the 
>obligations about identifying agents of action is limited.

Yes.

>However I also note that that section of 5.2 calls on using DKIM for 
>validating content and, technically, DKIM doesn't do that...
>
>    It is recommended that the ownership of an ARF report be vetted, 
> such as by  using common message accountability schemes such as 
> [DKIM], [SPF] or [SENDERID], prior to the undertaking of any kind 
> of automated action in response to receipt of the report.  The 
> details of the required validation, to achieve this, are outside 
> the scope of this specification.

That sounds better.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Feb 2010 16:00:29 -0800

> From: SM [mailto:[email-masked]]
> Sent: Monday, February 08, 2010 3:39 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: RE: [marf] Comments on draft-ietf-marf-base-00
> 

I'm at a loss as to how you're suggesting we proceed here.  There are only two references sections, and I don't believe this warrants being classified as normative.

What are you suggesting is "the appropriate section"?

> >Are those different things?

I'm confused here too.  Please elaborate.

> That's fine with me.  It might raise a nit during the security review.

What nit are you foreseeing?  This text was fine for RFC5451, for example.

---

From: SM <[email-masked]>
Date: Tue, 09 Feb 2010 01:41:43 -0800

Hi Murray,
At 13:26 08-02-10, Murray S. Kucherawy wrote:
>I like this approach, but it needs more thought to be included in a 
>normative part of a specification such as Section 2d of this 
>I-D.  In particular, I don't think we can use normative language 
>where the decision is actually subjective; that is, I don't think 
>one can write "You MUST do X unless you don't think the recipient 
>will actually need it" because the sender doesn't know what software 
>or internal processes may exist at the receiver.

Yes, it could go in Section 2.  The "MUST" excludes the "a very good 
reason not to do so".

>I think we'd be much safer to say the third part MUST always be there.

Is the information in the third part important for the feedback 
report to be meaningful?  If so, it has to  be included.

Dave mentioned protocol and format in another message.  As the I-D 
defines a format, there are some points that could be discussed in 
other documents.

>ADMD is only used for discussion, so expanding it on first use is 
>fine but I don't think it needs to be normative.  (Can an 
>informational draft be normative anyway?)

The short answer is that an information RFC can be normative.  If an 
informational I-D is normative, the I-D referencing it will be on 
hold (wait for publication).

>I can conceive of an automatically-generated ARF report where for 
>example a spam filter is programmed to generate ARFs for suspect 
>messages right at the MTA.  (We might even want to mention that as a 
>possible DoS vector.)

The potential for a denial of service is worthy of a discussion in 
the I-D.  BTW, Section 3 mentions automated use and Section 6.3 
mentions avoiding amplification "attacks".

>legitimate ARFs that don't get delivered are never detected.

The above or some text along those lines could be discussed in the 
I-D.  You then get around specifying NULL envelope sender 
(reverse-path) as a requirement.

I did not bring up the question of ARF messages generating ARF 
reports as it doesn't make sense to do that.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Tue, 09 Feb 2010 01:49:57 -0800

Hi Murray,
At 16:00 08-02-10, Murray S. Kucherawy wrote:
>I'm at a loss as to how you're suggesting we proceed here.  There 
>are only two references sections, and I don't believe this warrants 
>being classified as normative.
>

This is a nit.  You can ignore it.  It could be in the 
Acknowledgements Section.

>I'm confused here too.  Please elaborate.

Dave provided an explanation.  I'll elaborate if you still consider 
this as confusing.

>What nit are you foreseeing?  This text was fine for RFC5451, for example.

It's the kind of nit that was raised during the RFC 5451 
discussion.  Dave mentioned "message accountability 
schemes".  Getting into "authentication" may not be necessary then.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Feb 2010 13:06:27 +0100

> manually it won't break anything).

However, an ARF consumer may (automatically) forward a report as part 
of its processing. IMHO, this deserves rewriting the first two parts, 
rather than encapsulating the whole message the way a TiS button 
would. It is quite likely that duplicates or possibly loops may 
result, one way or another.

> I don't see a need for anything ARF-specific to break loops here.

Yes, there was consensus about postponing this subject to a subsequent 
BCP. Will it be able to define any required field it may need? (E.g. a 
level, a.k.a. stratum or hop number, X-WillBeThere, CC, or any handy 
way of tracing which recipients have already been considered.) Then, 
we might just mention that possibility, e.g.

  When generating an ARF message, it is necessary to construct the
  message so as to avoid amplification or backscatter attacks,
  deliberate or otherwise.  In particular, per Section 2 of [DSN],
  when an SMTP transaction is used to send an ARF message, the MAIL
  FROM command MAY use a NULL return address, i.e. "MAIL FROM:<>".  In
  addition, if processing of ARF messages provides for generating
  further ARF messages based on the same original message, then the
  generator MUST ensure that no recipients have already received it.
  Algorithms for accomplishing such task, based on data contained in
  the header or the feedback-report fields, are beyond the scope of
  this specification.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 08 Feb 2010 12:16:30 -0500

In <[email-masked]>, on 02/08/2010

>to  interoperate will find it worth their while to implement.

Part of that is specifying what is and is not compliant. There's nothing
wrong dith definig a flag and specifying that the third MIME part MUST NOT
be redacted unless the flag is set.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 9 Feb 2010 13:44:00 -0700

+1

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

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 09 Feb 2010 11:56:15 -0500

In
<[email-masked]>,
on 02/08/2010
   at 01:26 PM, "Murray S. Kucherawy" <[email-masked]> said:

>I don't have a problem with that small change, except that it might fly
>in the face of later registrations of those names in the IANA header
>field registry.

"This in no way restricts the use of message header fields that are
registered in the IANA header field registry with the same field names."

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 09 Feb 2010 11:39:09 -0500

In
<[email-masked]>,
on 02/08/2010
   at 01:10 PM, "Murray S. Kucherawy" <[email-masked]> said:

>Given that we're tending toward making this format most useful by
>machines, how would they use that flag if it were set?

If we allow redaction in report-type=feedback-report, then the flag would
be useful for automated processing. If we don't, then it would be useful
only for human readers.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 09 Feb 2010 11:39:09 -0500

In

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 10:26:28 -0800

> Sent: Tuesday, February 09, 2010 1:42 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

How does an ARF generator make that decision?  I don't think that logic can be left unspecified.

> mentions avoiding amplification "attacks".

Here's a suggested subsection of Security Considerations to discuss this issue (pardon the XML and indentation):

                        <t> It is conceivable that a system may be implemented
                            that generates ARF reports automatically in
                            response to an event.  For example, software
                            monitoring a honeypot email address might generate
                            an ARF report immediately upon delivery of any
                            message to it.  An attacker that becomes aware
                            of such a configuration can exploit it to
                            attack an ARF recipient with automatically
                            generated ARF reports. </t>

> reports as it doesn't make sense to do that.

How about this?

        <section anchor="transport" title="Transport Considerations">
                <t> <xref target="DSN"/> requires that its reports
                    be sent with the empty <xref target="SMTP"/> envelope
                    sender to avoid bounce loops.  A similar requirement
                    was considered for this specification, but it seems
                    unlikely that an ARF report would be generated
                    in response to receipt of an ARF report, and furthermore
                    such a requirement would prevent an ARF generator from
                    ever determining that an ARF report was not actually
                    received. </t>

                <t> On the other hand, if an ARF report is generated without
                    the empty envelope sender and is sent to an address that
                    actually does not work, then the generating address
                    can also be overwhelmed by DSNs as a denial of service
                    attack (see <xref target="sc-autogen"/>). </t>

                <t> This specification therefore makes no requirement related
                    to the envelope sender of a generated report.  Operators
                    will have to consider what envelope sender to use
                    within the context of their own installations.  </t>
        </section>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 10:31:57 -0800

> Sent: Tuesday, February 09, 2010 8:56 AM
> To: [email-masked]

+1.  Added.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 10:34:42 -0800

> Sent: Monday, February 08, 2010 9:17 AM
> To: [email-masked]

It seems to me from the discussion that at least some people would use such a field if present, and I have some doubt that it would harm backward compatibility if we were to add it.  So a couple of questions are important as we consider actually making such an update:

How would ARF recipients actually use such a flag if it is observed to be set?

Would ARF generators object to setting that flag when redacting?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 10:36:32 -0800

> Sent: Tuesday, February 09, 2010 4:06 AM
> To: [email-masked]

Sorry, I proposed some other text before I saw this one.  Let me know if you think that text needs adjustment, or if we should chuck it and go with this one, etc.

---

From: "John R Levine" <[email-masked]>
Date: 10 Feb 2010 13:59:47 -0500

> Would ARF generators object to setting that flag when redacting?

I have my doubts about its utility, but AOL already sets it:

Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: AOL SComp
Version: 0.1
Received-Date: Wed, 13 Jan 2010 03:04:37 -0500 (EST)
Source-IP: 208.31.42.54
Reported-Domain: w4.iecc.com
Redacted-Address: redacted
Redacted-Address: redacted@

Regards,

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 11 Feb 2010 12:18:06 -0700

>                            generated ARF reports. </t>

Not merely conceivable -- these already exist.

In any case, +1 to this language & location in the draft.

>                    within the context of their own installations.  </t>

I'm tempted to go a bit further, and RECOMMEND that ARF generators use VERP, BATV, or similar methods to handle non-deliverable recipients, just like other mailing lists or transactional messages.  That matches many of the current deployments, and just generally seems like a good idea (though still not a MUST.)

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 11 Feb 2010 12:23:18 -0700

> I have my doubts about its utility, but AOL already sets it:

I've no objection, so long as it's optional.

Making it optional does create some complication, however.  Consider:

- redaction is optional
- stating whether or not redaction has occurred is optional
- therefore, an ARF consumer has no way of knowing whether a message without the redacted flag might be redacted, UNLESS they discuss it with the ARF generator beforehand

So we're back to recommending that both ends talk to each other about redaction -- which matches current practice perfectly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Feb 2010 11:32:47 -0800

> J.D. Falk
> Sent: Thursday, February 11, 2010 11:23 AM
> To: Message Abuse Report Format working group
> Subject: Re: [marf] "Redacted" flag (was RE: Comments on draft-ietf-
> marf-base-00)
> 

Does that mean it would be a burden to current implementations to make it mandatory?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Feb 2010 11:35:25 -0800

> Sent: Thursday, February 11, 2010 11:18 AM
> I'm tempted to go a bit further, and RECOMMEND that ARF generators use
> VERP, BATV, or similar methods to handle non-deliverable recipients,
> just like other mailing lists or transactional messages.  That matches
> many of the current deployments, and just generally seems like a good
> idea (though still not a MUST.)

That's not a bad idea though I don't know that we can cite those two specific ones since they're not RFCs or even current I-Ds (BATV expired a long time ago, and I don't think VERP ever got standardized).  Maybe just a generic remark about putting some thought into such methods would be sufficient?

---

From: Steve Atkins <[email-masked]>
Date: Thu, 11 Feb 2010 11:35:30 -0800

> I'm tempted to go a bit further, and RECOMMEND that ARF generators use VERP, BATV, or similar methods to handle non-deliverable recipients, just like other mailing lists or transactional messages.…

This is all SMTP level stuff, handled in a normal SMTP manner in the
case where the ARF formatted payload is sent via SMTP, isn't it?

It's all good solid best practices,  but it's two levels removed from what
we're talking about with ARF (SMTP -> MIME -> ARF). We're just a
subset of RFC3462, after all.

Or are we just being as broad as possible in the security section, to make
sure we're covered? (In which case, a +1 on the language).

Cheers,
  Steve

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 11 Feb 2010 12:37:38 -0700

> Does that mean it would be a burden to current implementations to make it mandatory?

It might, in the same way that anything entirely new might be a burden.  For our implementation, we'll ask our ISP partners (on whose behalf we operate complaint feedback loops) what they'd each prefer.

I'm also assuming that the same lawyers who say messages have to be redacted might also say the generator shouldn't use the flag.  Illogical to us techies, I know, but this is the political layer.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 11 Feb 2010 12:38:27 -0700

> That's not a bad idea though I don't know that we can cite those two specific ones since they're not RFCs or even current I-Ds (BATV expired a long time ago, and I don't think VERP ever got standar…

Works for me.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 11 Feb 2010 17:51:00 -0500

> sure we're covered? (In which case, a +1 on the language).

In RFC 3464, it gets into details about SMTP level transactions even
though the DSNs themselves are encoded on a higher level. We are just
following a similar approach.

Yakov

---

From: SM <[email-masked]>
Date: Sat, 13 Feb 2010 00:17:48 -0800

Hi Murray,
>logic can be left unspecified.

There are two types of reports:

  (i) by agreement (between the sender and the receiver)

  (ii) A report is sent to the receiver without any prior agreement 
between the two parties.

I'll leave the question of whether item (ii) should be directly 
addressed by the draft open.  As mentioned in the discussion about 
"Reported-Domain", the report will probably use the domain as a key 
to determine who should receive the report.  Some receivers may 
consider redacted information as still meaningful to identify the 
source of the abuse.  Some may not.  It is better for the two parties 
to work things out if they are going to exchange a significant number 
of reports.

>Here's a suggested subsection of Security Considerations to discuss 
>this issue (pardon the XML and indentation):
>

I suggest a minor change:

   A system might be generating reports automatically in response to an event.

I did not use a proper definition of "system" as there is an example 
in the second sentence.

>                     within the context of their own installations.  </t>

The text looks fine.

Regards,
-sm