Subject: Re: [feedback-report] ARF spec question
From: Steve Atkins <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cc: [email-masked]
Date: Wed, 8 Mar 2006 11:20:47 -0800
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

On Mar 8, 2006, at 11:14 AM, Yakov Shafranovich wrote:

> Steve Atkins wrote:
> ...
>> The spec says that the body of this content type consists of
>> multiple fields formatted according to the ABNF of RFC822
>> header fields. While you could take that to mean that each
>> individual field is formatted that way (which they are here) it
>> seems to me that the whole body should be formatted that
>> way, meaning that it terminates at the first blank line.
>> That leads to a couple of questions.
>> First, am I right to say that the snippet above isn't valid,
>> and the blank lines should go away?
>
> It is an interesting question. When I wrote the spec originally, I  
> looked at the other three "multipart/report" standards: DSNs, MDNs  
> and message tracking.
>
> For example, RFC 3464 which is a "child" of the "multipart/report"  
> MIME type has specific conventions in regards to blank lines.  
> Section 2.1 states that:
>
>    "per-message fields appear first, followed by a
>    blank line.  Following the per-message fields are one or more  
> groups
>    of per-recipient fields.  Each group of per-recipient fields is
>    preceded by a blank line."
>
> RFC 3886 is a bit more explicit in section 3.1:
>
>    "The per-message fields appear first, followed by a blank line.
>    Following the per-message fields are one or more groups of per-
>    recipient fields.  Each group of per-recipient fields is  
> preceded by
>    a blank line.  Note that there will be a blank line between the  
> final
>    per-recipient field and the MIME boundary, since one CRLF is
>    necessary to terminate the field, and a second is necessary to
>    introduce the MIME boundary."
>
> RFC 3798 (another "multipart/report" child) does not mention  
> anything about blank lines but it is clear from examples that blank  
> lines should not be allowed.
>
> All of this seems to imply that in absence of specific  
> instructions, your interpretation is correct.
>
>> Second, if so, do we need to clarify the wording in the
>> spec?
>
> It is a good idea to clarify the spec in any case. The question is  
> whether to allow blank lines?

Definitely not, IMO.

They add no value in this case and they mean that people won't be
able to reuse time-tested header parsing code.

RFC822 headers are an ugly format to parse and the only real
advantages of using them as a format are code reuse, documentation
reuse and familiarity of email people with the format. If we tweak
the format just a little by allowing embedded blank lines then
we inherit all the problems and avoid any chance to reuse
production tested code.

It also breaks all the existing parsers I'm aware of. :)

Cheers,
   Steve

Date: Wed, 08 Mar 2006 14:14:20 -0500
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: Steve Atkins <[email-masked]>
Subject: Re: [feedback-report] ARF spec question
Cc: [email-masked]

Steve Atkins wrote:
...
> The spec says that the body of this content type consists of
> multiple fields formatted according to the ABNF of RFC822
> header fields. While you could take that to mean that each
> individual field is formatted that way (which they are here) it
> seems to me that the whole body should be formatted that
> way, meaning that it terminates at the first blank line.
> 
> That leads to a couple of questions.
> 
> First, am I right to say that the snippet above isn't valid,
> and the blank lines should go away?
> 

It is an interesting question. When I wrote the spec originally, I 
looked at the other three "multipart/report" standards: DSNs, MDNs and 
message tracking.

For example, RFC 3464 which is a "child" of the "multipart/report" MIME 
type has specific conventions in regards to blank lines. Section 2.1 
states that:

    "per-message fields appear first, followed by a
    blank line.  Following the per-message fields are one or more groups
    of per-recipient fields.  Each group of per-recipient fields is
    preceded by a blank line."

RFC 3886 is a bit more explicit in section 3.1:

    "The per-message fields appear first, followed by a blank line.
    Following the per-message fields are one or more groups of per-
    recipient fields.  Each group of per-recipient fields is preceded by
    a blank line.  Note that there will be a blank line between the final
    per-recipient field and the MIME boundary, since one CRLF is
    necessary to terminate the field, and a second is necessary to
    introduce the MIME boundary."

RFC 3798 (another "multipart/report" child) does not mention anything 
about blank lines but it is clear from examples that blank lines should 
not be allowed.

All of this seems to imply that in absence of specific instructions, 
your interpretation is correct.

> Second, if so, do we need to clarify the wording in the
> spec?
> 

It is a good idea to clarify the spec in any case. The question is 
whether to allow blank lines?

Yakov

Date: Wed, 08 Mar 2006 10:35:04 -0800
From: "Carl S. Gutekunst" <[email-masked]>
Organization: Habeas, Inc.
To: Steve Atkins <[email-masked]>
Subject: Re: [feedback-report] ARF spec question
Cc: [email-masked]

Steve Atkins wrote:

> First, am I right to say that the snippet above isn't valid,
> and the blank lines should go away? 

Well, it certainly breaks my parser, which stops on the first blank line.

I'm wondering about the cause, though: Are you sure the CR/LF/Newline 
mapping is proper all along the path?

<csg>

Date: Wed, 08 Mar 2006 10:25:45 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Steve Atkins <[email-masked]>
Subject: Re: [feedback-report] ARF spec question
Cc: [email-masked]
Reply-To: [email-masked]

> The spec says that the body of this content type consists of
> multiple fields formatted according to the ABNF of RFC822
> header fields. While you could take that to mean that each
> individual field is formatted that way (which they are here) it
> seems to me that the whole body should be formatted that
> way, meaning that it terminates at the first blank line.

On the theory that the benefit of blindly citing conformance to rfc822 header 
syntax is that it permits re-using well-established code for processing such a 
header, then the extra blank lines must be an absolute no-no.

 From any other perspective, I suspect the blank lines are merely a nuisance, 
since the MIME dividers take care of finding the ending boundary.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

To: [email-masked]
From: Steve Atkins <[email-masked]>
Date: Wed, 8 Mar 2006 10:03:32 -0800
Subject: [feedback-report] ARF spec question

I have a snippet of ARF report here (with some of the data masked a  
little
to protect the guilty).

--_----------=_114183695220154735
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Type: message/feedback-report

Feedback-Type: abuse

Version: 1

Source-IP: 208.187.80.130

Feedback-Agent: HatStand/1.0

Received-Date: Wed, 8 Mar 2006 05:10:12 -0500

--_----------=_114183695220154735

There's one obvious problem - we're at version 0.1 right now,
not version 1 - but the spacing of the lines also seems wrong.

The spec says that the body of this content type consists of
multiple fields formatted according to the ABNF of RFC822
header fields. While you could take that to mean that each
individual field is formatted that way (which they are here) it
seems to me that the whole body should be formatted that
way, meaning that it terminates at the first blank line.

That leads to a couple of questions.

First, am I right to say that the snippet above isn't valid,
and the blank lines should go away?

Second, if so, do we need to clarify the wording in the
spec?

Cheers,
   Steve

Date: Sun, 05 Mar 2006 08:49:45 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: [feedback-report] ARF deployment status page
Reply-To: [email-masked]

Folks,

The ARF page <http://mipassoc.org/arf> now includes a pointer to the development 
and use page maintained by Steve Atkins.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

From: Steve Atkins <[email-masked]>
Subject: Re: [feedback-report] MIME::ARF
Date: Sat, 4 Mar 2006 17:23:38 -0800
To: [email-masked]

On Mar 4, 2006, at 4:23 PM, Vipul Ved Prakash wrote:

> Thanks.  Would be great to have these on CPAN as well.
>

Yes. They need docs and testcases and licenses[1] and other such
things before that, though.

Once I have Mail::ARF released I'll be looking at those,
and probably a better namespace than the current one too.

(Any perlish people who want to give me namespace advice
offlist would be very welcome).

Cheers,
   Steve

[1] New BSD, if anyone cares.

> Cheers,
> vipul
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Steve
> Atkins
> Sent: Saturday, March 04, 2006 4:18 PM
> To: [email-masked]
> Subject: Fwd: [feedback-report] MIME::ARF
>
>
>
> Begin forwarded message:
>
>>
>> From: Steve Atkins <[email-masked]>
>> Date: March 4, 2006 4:12:53 PM PST
>> To: [email-masked]
>> Subject: Re: [feedback-report] MIME::ARF
>>
>>
>>
>> On Mar 4, 2006, at 3:46 PM, Vipul Ved Prakash wrote:
>>
>>> Hi,
>>>
>>> Is the MIME::ARF module publically available?
>>
>> Assuming you mean mine, it's publicly available, yes, linked  
>> somewhere
>
>> on arf.word-to-the-wise.com.
>>
>>> Is it intended to be open
>>> source?
>>
>> Certainly. Share and enjoy.
>>
>> I have another module for validating ARF I'll be dropping onto the
>> website in the next couple of days.
>>
>> Cheers,
>>   Steve
>>
>>
>>
>
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report

Content-class: urn:content-classes:message
Subject: RE: [feedback-report] MIME::ARF
Date: Sat, 4 Mar 2006 16:23:05 -0800
From: "Vipul Ved Prakash" <[email-masked]>
To: "Steve Atkins" <[email-masked]>, <[email-masked]>
Cc: 

Thanks.  Would be great to have these on CPAN as well. 

Cheers,
vipul 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Steve
Atkins
Sent: Saturday, March 04, 2006 4:18 PM
To: [email-masked]
Subject: Fwd: [feedback-report] MIME::ARF

Begin forwarded message:

>
> From: Steve Atkins <[email-masked]>
> Date: March 4, 2006 4:12:53 PM PST
> To: [email-masked]
> Subject: Re: [feedback-report] MIME::ARF
>
>
>
> On Mar 4, 2006, at 3:46 PM, Vipul Ved Prakash wrote:
>
>> Hi,
>>
>> Is the MIME::ARF module publically available?
>
> Assuming you mean mine, it's publicly available, yes, linked somewhere

> on arf.word-to-the-wise.com.
>
>> Is it intended to be open
>> source?
>
> Certainly. Share and enjoy.
>
> I have another module for validating ARF I'll be dropping onto the 
> website in the next couple of days.
>
> Cheers,
>   Steve
>
>
>

_______________________________________________
abuse-feedback-report mailing list
[email-masked]
http://mipassoc.org/mailman/listinfo/abuse-feedback-report

From: Steve Atkins <[email-masked]>
Subject: Fwd: [feedback-report] MIME::ARF
Date: Sat, 4 Mar 2006 16:17:47 -0800
To: [email-masked]

Begin forwarded message:

>
> From: Steve Atkins <[email-masked]>
> Date: March 4, 2006 4:12:53 PM PST
> To: [email-masked]
> Subject: Re: [feedback-report] MIME::ARF
>
>
>
> On Mar 4, 2006, at 3:46 PM, Vipul Ved Prakash wrote:
>
>> Hi,
>>
>> Is the MIME::ARF module publically available?
>
> Assuming you mean mine, it's publicly available, yes,
> linked somewhere on arf.word-to-the-wise.com.
>
>> Is it intended to be open
>> source?
>
> Certainly. Share and enjoy.
>
> I have another module for validating ARF I'll be dropping
> onto the website in the next couple of days.
>
> Cheers,
>   Steve
>
>
>

Content-class: urn:content-classes:message
Date: Sat, 4 Mar 2006 15:46:38 -0800
From: "Vipul Ved Prakash" <[email-masked]>
To: <[email-masked]>
Subject: [feedback-report] MIME::ARF

Hi, 

Is the MIME::ARF module publically available?  Is it intended to be open
source?

Cheers,
vipul