[feedback-report] Defintion of "Received-Date:" WAS abuse-feedback-report Digest, Vol 16, Issue 6

Wed May 23 12:25:10 PDT 2007

Sorry for the late comment.

I have been working both with internal and external engineers on
implementing various systems using ARF.  Inevitably there is confusion over
the defintion of the "Received-Date:" field.

"Received-Date:" - indicates the date the original message was received by
the report generator.  This field MUST BE formatted as per section 3.3 of
RFC 2822 [RFC2822].

The confusion comes from the words "Report Generator".  Some take this to
mean the recipient of the original email (i.e. the end user) and some take
this to mean the application / process at the ISP that generates the ARF
message after a user clicks a "spam" button..  Obviously the field values
would differ based upon which definitions is followed

Perhaps a better definition would be "..received in the final destination
inbox" or something along these lines?

Justin

Justin Rietz
Goodmail Systems

-----Original Message-----
From: abuse-feedback-report-bounces at mipassoc.org
[mailto:abuse-feedback-report-bounces at mipassoc.org] On Behalf Of
abuse-feedback-report-request at mipassoc.org
Sent: Wednesday, May 23, 2007 12:00 PM
To: abuse-feedback-report at mipassoc.org
Subject: abuse-feedback-report Digest, Vol 16, Issue 6

Send abuse-feedback-report mailing list submissions to
	abuse-feedback-report at mipassoc.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://mipassoc.org/mailman/listinfo/abuse-feedback-report
or, via email, send a message with subject or body 'help' to
	abuse-feedback-report-request at mipassoc.org

You can reach the person managing the list at
	abuse-feedback-report-owner at mipassoc.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of abuse-feedback-report digest..."

Today's Topics:

   1. New version of the ARF draft (John R Levine)

----------------------------------------------------------------------

Message: 1
Date: Tue, 22 May 2007 19:44:17 -0400 (EDT)
From: John R Levine <johnl at taugh.com>
Subject: [feedback-report] New version of the ARF draft
To: ARF mailing list <abuse-feedback-report at mipassoc.org>
Message-ID: <20070522194403.X5548 at simone.iecc.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

I put it here, in xml and html: http://www.taugh.com/arf/.  It would be nice
to have a new draft sent in to I-D in time for MAAWG.

Paul and I went through and fixed a bunch of stuff that made xml2rfc
complain (if it complains, the RFC editor will complain), along with what
are intended to be minor edits for style and consistency.

We added these two feedback types.  If people hate them, we can take them
back
out:

  * miscategorized - indicates that the content categorization applied in
    connection with a certification or reputation system was incorrect

  * not-spam - indicates that a message that was tagged or categorized as
    spam (such as by an ISP) is not spam

The former is intended to send back to a certifier or reputation provider,
the second to your own ISP or mail host to tune their filters. Like every
other content type, these are just assertions by whoever's sending the
report, which the receiving system is free to interpret or not interpret any
way it wants.

Near the end, there's a list of questions added in previous versions.  If we
can agree on the answers to some or all of them we can update the draft and
take out the questions.

1.  Whether encoding of the machine readable part should be limited
     to 7-bit

2.  Whether there is a need for both "opt-out" and "opt-out-list",
     and whether this format should be used for opt-outs at all.

3.   Whether the "from" address should be required to be a human just
     like other RFCs in the "message/report" family.

4.  Whether there is a need for a new header to indicate munging of
     the included email message.

5.  Whether different type of convention should be allowed for
     subject lines.

6.  Whether there should be different types defined for
     "Reported-Uri" to better indicate to the report receiver how they are
     related to the email message in question.