Received: from smtp104.mail.sc5.yahoo.com (smtp104.mail.sc5.yahoo.com [66.163.169.223]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j8TLRXfv023529 for ; Thu, 29 Sep 2005 14:27:33 -0700 Received: (qmail 13704 invoked from network); 29 Sep 2005 21:26:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=Received:Message-ID:Date:From:Organization:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qg/JCMZIxrEknbD2i0AFd91Dv3gUuTh1KyaBtk7hBgcw9p3iKsjj7ht7ciR/iPDF ; Received: from unknown (HELO ?66.228.167.95?) (jdfalk@66.228.167.95 with plain) by smtp104.mail.sc5.yahoo.com with SMTP; 29 Sep 2005 21:26:47 -0000 Message-ID: <433C5BFD.5090302@yahoo-inc.com> Date: Thu, 29 Sep 2005 14:26:21 -0700 From: "J.D. Falk" Organization: Yahoo! User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] RE: abuse-feedback-report Digest, Vol 6, Issue 7 References: <200509292042.j8TKgB7G018723@sb7.songbird.com> In-Reply-To: <200509292042.j8TKgB7G018723@sb7.songbird.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: jdfalk@yahoo-inc.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 21:27:37 -0000 On 2005-09-29 13:41, Justin Rietz wrote: > All legitimate points. Let me try to answer them one by one and ask for > clarification on others. > > My main point is exactly as has been pointed out by others: report > generators and/or report receivers WILL customize ARF for their own needs. Are you sure? I was working on the requirements for Yahoo!'s upcoming complaint feedback loop system at the same time that we were discussing what turned into ARF, and I don't have anything else to add to it. Neither did any of the other current or potential high-volume Report Generators who participated. We did have a long conversation about this, though, and concluded that with "other" and a standard process for adding more types in the future, there was no need to get more specific now. Do you have any examples of individual types that should be added? > 1. To Steve's point that ignoring a field would drastically alter the > meaning of the report, I think I am missing something. If I parse an ARF > report, and tell my parsing application: "ignore all x-feedback-type > fields" or "ignore all x-feedback-type fields that don't contain complaint > type x,y,z" everything else would still be parsed normally, saved to a > database, etc. Why would a Report Generator choose to generate reports that the Report Recipient will most likely ignore? > To J.D.'s point about dealing with multiple feedback types in my > aforementioned scenario, one solution off the top of my head is that there > could be a x-feedback-type that is "don't unsubscribe." A user would select > "abuse" and also select "don't unsubscribe" (all dependent on the report > generators GUI, etc.). How do you explain this option (or anything similar) to an end user, in words small enough to fit inside a mouseover/tooltip? > 3. Yes, there currently is a way to add new feedback-type fields. And I'm > not suggesting ARF should nix standard types. But if report generators and > receivers have to go through this approval process anytime they want to > standardize a new type, they will just do their own one-off customization, > with all the issues I laid out in #2. ...which is exactly what they SHOULD do, to test out any new ideas before going through the process for adding new standard types. Remember, standards aren't (or shouldn't be) where fresh new ideas are proposed for the first time. They're to turn existing small-scale practices into standard behavior, and sometimes (as in this case) improve upon those practices along the way. -- J.D. Falk, Anti-Spam Product Manager Yahoo! Communications Platform Team Received: from mx1.goodmailsystems.com (mx3.goodmailsystems.com [67.110.227.4]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8TKgB7G018723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Sep 2005 13:42:11 -0700 Message-Id: <200509292042.j8TKgB7G018723@sb7.songbird.com> Received: (qmail 18616 invoked from network); 29 Sep 2005 20:41:25 -0000 Received: from unknown (HELO justint41) (authenticated:justin@[10.34.3.4]) (envelope-sender ) by mx1.goodmailsystems.com (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 29 Sep 2005 20:41:25 -0000 From: "Justin Rietz" To: Date: Thu, 29 Sep 2005 13:41:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXFJ/aBPW5GOxeRS/KmbXobEFHPaQAAL1Qg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200509291900.j8TJ01tm008613@sb7.songbird.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: justin@goodmailsystems.com Subject: [feedback-report] RE: abuse-feedback-report Digest, Vol 6, Issue 7 X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 20:42:26 -0000 -----Original Message----- From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse-feedback-report-bounces@mipassoc.org] On Behalf Of abuse-feedback-report-request@mipassoc.org Sent: Thursday, September 29, 2005 12:00 PM To: abuse-feedback-report@mipassoc.org Subject: abuse-feedback-report Digest, Vol 6, Issue 7 Send abuse-feedback-report mailing list submissions to abuse-feedback-report@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@mipassoc.org You can reach the person managing the list at abuse-feedback-report-owner@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. Extensible Feedback Type Proposal (Justin Rietz) 2. Re: Extensible Feedback Type Proposal (Steve Atkins) 3. Re: Extensible Feedback Type Proposal (J.D. Falk) ---------------------------------------------------------------------- Message: 1 Date: Thu, 29 Sep 2005 11:26:14 -0700 From: "Justin Rietz" Subject: [feedback-report] Extensible Feedback Type Proposal To: Message-ID: <200509291827.j8TIR1Ek005594@sb7.songbird.com> Content-Type: text/plain; charset="us-ascii" I would like to "officially" propose that ARF allow for custom feedback types in addition to the standard Feedback- Type field as an X-Feedback-Type. Reasons / Comments: 1. Report senders may want to offer their users the ability to select from complaint types not already established in ARF 2. Report recipients may request additional feedback data from report senders 3. Standard feedback types would be unchanged, thus retaining all the original elements of the current version of ARF 4. Report senders could publish definitions of their X-Feedback-Type fields for report recipients who wish to use the custom feedback data 5. Report recipients could choose to accept all, some, or none of any X-Feedback-Type fields in an ARF report 6. Custom feedback types that are used frequently could be "promoted" to a standard type through a defined process Given the current feedback types, an email recipient cannot register multiple complaints/requests i.e. "opt-out" and "abuse." While it could reasonably be assumed that someone who submits an "abuse" complaint also wants also to opt-out of the email, this may not be always the case. There is real-world example of an online retailer (who shall go unamed) who sent too many purchase confirmations and irritated customers; however, those customers surely still wanted to receive original purchase confirmation. To the comments that custom feedback types defy the idea of a standard, I would argue that a standard should define the format of the data, estalish boundaries for what is and isn't allowed, and contain common elements (i.e. standard Feedback-Type fields ) that everyone agrees to use. However, I believe the standard should also retain enough flexibility for users to be able do some customization but still conform to the standard. Given the rapidly changing environment of phishing and spamming, I believe ARF needs to allow for this type of flexibility in order to remain up-to-date with what is occuring in the real world. Justin Rietz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mipassoc.org/pipermail/abuse-feedback-report/attachments/20050929/c18 e8eab/attachment-0001.html ------------------------------ Message: 2 Date: Thu, 29 Sep 2005 11:39:32 -0700 From: Steve Atkins Subject: Re: [feedback-report] Extensible Feedback Type Proposal To: abuse-feedback-report@mipassoc.org Message-ID: <20050929183932.GA24698@gp.word-to-the-wise.com> Content-Type: text/plain; charset=us-ascii On Thu, Sep 29, 2005 at 11:26:14AM -0700, Justin Rietz wrote: > I would like to "officially" propose that ARF allow for custom > feedback types in addition to the standard Feedback- Type field as an > X-Feedback-Type. > > Reasons / Comments: > 1. Report senders may want to offer their users the ability to select > from complaint types not already established in ARF 2. Report > recipients may request additional feedback data from report senders 3. > Standard feedback types would be unchanged, thus retaining all the > original elements of the current version of ARF 4. Report senders > could publish definitions of their X-Feedback-Type fields for report > recipients who wish to use the custom feedback data 5. Report > recipients could choose to accept all, some, or none of any > X-Feedback-Type fields in an ARF report 6. Custom feedback types that > are used frequently could be "promoted" to a standard type through a > defined process > > Given the current feedback types, an email recipient cannot register > multiple complaints/requests i.e. "opt-out" and "abuse." While it > could reasonably be assumed that someone who submits an "abuse" > complaint also wants also to opt-out of the email, this may not be > always the case. There is real-world example of an online retailer > (who shall go unamed) who sent too many purchase confirmations and > irritated customers; however, those customers surely still wanted to receive original purchase confirmation. This can be fairly easily remedied by extending the standard fields as needed. That also means that recipients will be able to support it. > To the comments that custom feedback types defy the idea of a > standard, I would argue that a standard should define the format of > the data, estalish boundaries for what is and isn't allowed, and contain common elements (i.e. > standard Feedback-Type fields ) that everyone agrees to use. However, > I believe the standard should also retain enough flexibility for users > to be able do some customization but still conform to the standard. > Given the rapidly changing environment of phishing and spamming, I > believe ARF needs to allow for this type of flexibility in order to > remain up-to-date with what is occuring in the real world. Ignoring any field on a report changes the semantics of that report. Therefore, recipients only have two choices when they see a report with non-standard fields. 1) Discard unrecognised types, parsing the remainder of the report. This may change the meaning of the report drastically, meaning that the report will be mishandled, because the recipient sees a report that may be totally different to the report that the sender sent. 2) Discard or reject the report entirely. If you see other options I'd appreciate it if you could explain what action my software should take when it sees non-standard headers in a report. Simply escalating any unrecognised field to a human is not viable. Cheers, Steve ------------------------------ Message: 3 Date: Thu, 29 Sep 2005 11:53:10 -0700 From: "J.D. Falk" Subject: Re: [feedback-report] Extensible Feedback Type Proposal To: abuse-feedback-report@mipassoc.org Message-ID: <433C3816.5040901@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 2005-09-29 11:26, Justin Rietz wrote: > I would like to "officially" propose that ARF allow for custom > feedback types in addition to the standard Feedback- Type field as an > X-Feedback-Type. > > Reasons / Comments: > 1. Report senders may want to offer their users the ability to select > from complaint types not already established in ARF 2. Report > recipients may request additional feedback data from report senders 3. > Standard feedback types would be unchanged, thus retaining all the > original elements of the current version of ARF 4. Report senders > could publish definitions of their X-Feedback-Type fields for report > recipients who wish to use the custom feedback data 5. Report > recipients could choose to accept all, some, or none of any > X-Feedback-Type fields in an ARF report So if the report sender uses a feedback type that the report recipient doesn't know about yet...what should happen? > Given the current feedback types, an email recipient cannot register > multiple complaints/requests i.e. "opt-out" and "abuse." While it > could reasonably be assumed that someone who submits an "abuse" > complaint also wants also to opt-out of the email, this may not be always the case. > There is real-world example of an online retailer (who shall go > unamed) who sent too many purchase confirmations and irritated > customers; however, those customers surely still wanted to receive > original purchase confirmation. If I were a report recipient, how would I know that a report with multiple feedback types actually means "don't send so many confirmations, but keep sending me other stuff?" > To the comments that custom feedback types defy the idea of a > standard, I would argue that a standard should define the format of > the data, estalish boundaries for what is and isn't allowed, and > contain common elements (i.e. standard Feedback-Type fields ) that > everyone agrees to use. However, I believe the standard should also > retain enough flexibility for users to be able do some customization > but still conform to the standard. Given the rapidly changing > environment of phishing and spamming, I believe ARF needs to allow for > this type of flexibility in order to remain up-to-date with what is occuring in the real world. The spec doesn't say "these are the only feedback types that there shall ever be no matter what" -- it includes a method for adding new types, which is compatible with existing standard methods. And, as others have said, if a report generator & report recipient want to set up a new type just between themselves, there's nothing stopping them from doing so. It's just text, after all. -- J.D. Falk, Anti-Spam Product Manager Yahoo! Communications Platform Team ------------------------------ All legitimate points. Let me try to answer them one by one and ask for clarification on others. My main point is exactly as has been pointed out by others: report generators and/or report receivers WILL customize ARF for their own needs. If ARF can encapsulate these customizations, it becomes a much more robust standard. It defeats the point of a standard if many users are going to customize it anyway (more in #2 below). 1. To Steve's point that ignoring a field would drastically alter the meaning of the report, I think I am missing something. If I parse an ARF report, and tell my parsing application: "ignore all x-feedback-type fields" or "ignore all x-feedback-type fields that don't contain complaint type x,y,z" everything else would still be parsed normally, saved to a database, etc. I could also have additional logic that says "ignore all new x-feedback-type fields except from generators A, B, and C; else send an email alert." To J.D.'s point about dealing with multiple feedback types in my aforementioned scenario, one solution off the top of my head is that there could be a x-feedback-type that is "don't unsubscribe." A user would select "abuse" and also select "don't unsubscribe" (all dependent on the report generators GUI, etc.). 2. Yes, report generators can (and will) extend the standard on their own - this is EXACTLY why ARF should support it. Instead of each report generator having to communicate with each of its report receivers in a proprietary manner, if a standard extensible x-feedback-type is allowed, and definitions for these custom types are published publicly in a standard format, the whole process becomes much easier for both the generator and receivers. Generators don't have to communicate directly with each of their receivers, and receivers don't have to support multiple custom fields in different formats with different update mechanisms for each report generator. Yes, assuming a receiver decides to accept new custom complaint types from some report generator, some human intervention would be need. But this will occur with ANY customization, whether it is built into ARF or not. 3. Yes, there currently is a way to add new feedback-type fields. And I'm not suggesting ARF should nix standard types. But if report generators and receivers have to go through this approval process anytime they want to standardize a new type, they will just do their own one-off customization, with all the issues I laid out in #2. Received: from smtp106.mail.sc5.yahoo.com (smtp106.mail.sc5.yahoo.com [66.163.169.226]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j8TIsKKZ007976 for ; Thu, 29 Sep 2005 11:54:20 -0700 Received: (qmail 35493 invoked from network); 29 Sep 2005 18:53:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=Received:Message-ID:Date:From:Organization:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hAyD9WQrki7M8MQ2yM8virEPImJGDhAJ3VW14VEI9GiwziHExoW9DFTGw6+r0mJH ; Received: from unknown (HELO ?66.228.167.95?) (jdfalk@66.228.167.95 with plain) by smtp106.mail.sc5.yahoo.com with SMTP; 29 Sep 2005 18:53:34 -0000 Message-ID: <433C3816.5040901@yahoo-inc.com> Date: Thu, 29 Sep 2005 11:53:10 -0700 From: "J.D. Falk" Organization: Yahoo! User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Extensible Feedback Type Proposal References: <200509291827.j8TIR1Ek005594@sb7.songbird.com> In-Reply-To: <200509291827.j8TIR1Ek005594@sb7.songbird.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: jdfalk@yahoo-inc.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:54:22 -0000 On 2005-09-29 11:26, Justin Rietz wrote: > I would like to "officially" propose that ARF allow for custom feedback > types in addition to the standard Feedback- > Type field as an X-Feedback-Type. > > Reasons / Comments: > 1. Report senders may want to offer their users the ability to select > from complaint types not already established in ARF > 2. Report recipients may request additional feedback data from report > senders > 3. Standard feedback types would be unchanged, thus retaining all the > original elements of the current version of ARF > 4. Report senders could publish definitions of their X-Feedback-Type > fields for report recipients who wish to use the custom feedback data > 5. Report recipients could choose to accept all, some, or none of > any X-Feedback-Type fields in an ARF report So if the report sender uses a feedback type that the report recipient doesn't know about yet...what should happen? > Given the current feedback types, an email recipient cannot register > multiple complaints/requests i.e. "opt-out" and "abuse." While it could > reasonably be assumed that someone who submits an "abuse" complaint also > wants also to opt-out of the email, this may not be always the case. > There is real-world example of an online retailer (who shall go unamed) > who sent too many purchase confirmations and irritated customers; > however, those customers surely still wanted to receive original > purchase confirmation. If I were a report recipient, how would I know that a report with multiple feedback types actually means "don't send so many confirmations, but keep sending me other stuff?" > To the comments that custom feedback types defy the idea of a standard, > I would argue that a standard should define the format of the data, > estalish boundaries for what is and isn't allowed, and contain common > elements (i.e. standard Feedback-Type fields ) that everyone agrees to > use. However, I believe the standard should also retain enough > flexibility for users to be able do some customization but still conform > to the standard. Given the rapidly changing environment of phishing and > spamming, I believe ARF needs to allow for this type of flexibility in > order to remain up-to-date with what is occuring in the real world. The spec doesn't say "these are the only feedback types that there shall ever be no matter what" -- it includes a method for adding new types, which is compatible with existing standard methods. And, as others have said, if a report generator & report recipient want to set up a new type just between themselves, there's nothing stopping them from doing so. It's just text, after all. -- J.D. Falk, Anti-Spam Product Manager Yahoo! Communications Platform Team Received: from gp.word-to-the-wise.com (gp.word-to-the-wise.com [64.71.176.18]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8TIggvi006962 for ; Thu, 29 Sep 2005 11:42:42 -0700 Received: by gp.word-to-the-wise.com (Postfix, from userid 500) id 131F88FC07F; Thu, 29 Sep 2005 11:39:32 -0700 (PDT) Date: Thu, 29 Sep 2005 11:39:32 -0700 From: Steve Atkins To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Extensible Feedback Type Proposal Message-ID: <20050929183932.GA24698@gp.word-to-the-wise.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: steve@word-to-the-wise.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:43:00 -0000 On Thu, Sep 29, 2005 at 11:26:14AM -0700, Justin Rietz wrote: > I would like to "officially" propose that ARF allow for custom feedback > types in addition to the standard Feedback- > Type field as an X-Feedback-Type. > > Reasons / Comments: > 1. Report senders may want to offer their users the ability to select from > complaint types not already established in ARF > 2. Report recipients may request additional feedback data from report > senders > 3. Standard feedback types would be unchanged, thus retaining all the > original elements of the current version of ARF > 4. Report senders could publish definitions of their X-Feedback-Type fields > for report recipients who wish to use the custom feedback data > 5. Report recipients could choose to accept all, some, or none of any > X-Feedback-Type fields in an ARF report > 6. Custom feedback types that are used frequently could be "promoted" to a > standard type through a defined process > > Given the current feedback types, an email recipient cannot register > multiple complaints/requests i.e. "opt-out" and "abuse." While it could > reasonably be assumed that someone who submits an "abuse" complaint also > wants also to opt-out of the email, this may not be always the case. There > is real-world example of an online retailer (who shall go unamed) who sent > too many purchase confirmations and irritated customers; however, those > customers surely still wanted to receive original purchase confirmation. This can be fairly easily remedied by extending the standard fields as needed. That also means that recipients will be able to support it. > To the comments that custom feedback types defy the idea of a standard, I > would argue that a standard should define the format of the data, estalish > boundaries for what is and isn't allowed, and contain common elements (i.e. > standard Feedback-Type fields ) that everyone agrees to use. However, I > believe the standard should also retain enough flexibility for users to be > able do some customization but still conform to the standard. Given the > rapidly changing environment of phishing and spamming, I believe ARF needs > to allow for this type of flexibility in order to remain up-to-date with > what is occuring in the real world. Ignoring any field on a report changes the semantics of that report. Therefore, recipients only have two choices when they see a report with non-standard fields. 1) Discard unrecognised types, parsing the remainder of the report. This may change the meaning of the report drastically, meaning that the report will be mishandled, because the recipient sees a report that may be totally different to the report that the sender sent. 2) Discard or reject the report entirely. If you see other options I'd appreciate it if you could explain what action my software should take when it sees non-standard headers in a report. Simply escalating any unrecognised field to a human is not viable. Cheers, Steve Received: from mx1.goodmailsystems.com (mx3.goodmailsystems.com [67.110.227.4]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8TIR1Ek005594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Sep 2005 11:27:01 -0700 Message-Id: <200509291827.j8TIR1Ek005594@sb7.songbird.com> Received: (qmail 8538 invoked from network); 29 Sep 2005 18:26:15 -0000 Received: from unknown (HELO justint41) (authenticated:justin@[10.34.3.4]) (envelope-sender ) by mx1.goodmailsystems.com (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 29 Sep 2005 18:26:15 -0000 From: "Justin Rietz" To: Date: Thu, 29 Sep 2005 11:26:14 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C5C4E8.9A4F6B40" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXFI0ZmrGjlL3vkSHWmOqo2LwV0EA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: justin@goodmailsystems.com Subject: [feedback-report] Extensible Feedback Type Proposal X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 18:27:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C5C4E8.9A4F6B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would like to "officially" propose that ARF allow for custom feedback types in addition to the standard Feedback- Type field as an X-Feedback-Type. Reasons / Comments: 1. Report senders may want to offer their users the ability to select from complaint types not already established in ARF 2. Report recipients may request additional feedback data from report senders 3. Standard feedback types would be unchanged, thus retaining all the original elements of the current version of ARF 4. Report senders could publish definitions of their X-Feedback-Type fields for report recipients who wish to use the custom feedback data 5. Report recipients could choose to accept all, some, or none of any X-Feedback-Type fields in an ARF report 6. Custom feedback types that are used frequently could be "promoted" to a standard type through a defined process Given the current feedback types, an email recipient cannot register multiple complaints/requests i.e. "opt-out" and "abuse." While it could reasonably be assumed that someone who submits an "abuse" complaint also wants also to opt-out of the email, this may not be always the case. There is real-world example of an online retailer (who shall go unamed) who sent too many purchase confirmations and irritated customers; however, those customers surely still wanted to receive original purchase confirmation. To the comments that custom feedback types defy the idea of a standard, I would argue that a standard should define the format of the data, estalish boundaries for what is and isn't allowed, and contain common elements (i.e. standard Feedback-Type fields ) that everyone agrees to use. However, I believe the standard should also retain enough flexibility for users to be able do some customization but still conform to the standard. Given the rapidly changing environment of phishing and spamming, I believe ARF needs to allow for this type of flexibility in order to remain up-to-date with what is occuring in the real world. Justin Rietz ------=_NextPart_000_003C_01C5C4E8.9A4F6B40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I = would like to=20 "officially" propose that ARF allow for custom feedback types = in=20 addition to the standard Feedback-
Type field as=20 an X-Feedback-Type.
 
Reasons /=20 Comments:
1.  Report=20 senders may want to offer their users the ability to select from = complaint types=20 not already established in ARF
2.  Report=20 recipients may request additional feedback data from report=20 senders
3.  Standard=20 feedback types would be unchanged, thus retaining all the original = elements of=20 the current version of ARF
4.  Report=20 senders could publish definitions of their X-Feedback-Type = fields for=20 report recipients who wish to use the custom feedback = data
5.  Report recipients could choose to accept = all, some,=20 or none of any X-Feedback-Type fields in an ARF = report
6.  Custom=20 feedback types that are used frequently could be "promoted" to a = standard type=20 through a defined process
 
Given = the current=20 feedback types, an email recipient cannot register multiple = complaints/requests=20 i.e. "opt-out" and "abuse."  While it could reasonably be assumed = that=20 someone who submits an "abuse" complaint also wants also to opt-out of = the=20 email, this may not be always the case.  There is = real-world example=20 of an online retailer (who shall go unamed) who sent too many purchase=20 confirmations and irritated customers; however, those customers surely = still=20 wanted to receive original purchase confirmation.
 
To the = comments that=20 custom feedback types defy the idea of a standard, I would argue that a = standard=20 should define the format of the data, estalish boundaries for = what is=20 and isn't allowed, and contain common elements (i.e. standard = Feedback-Type=20 fields ) that everyone agrees to use.  However, I believe the = standard=20 should also retain enough flexibility for users to be able do some = customization=20 but still conform to the standard. Given the rapidly changing = environment of=20 phishing and spamming, I believe ARF needs to allow for this type of = flexibility=20 in order to remain up-to-date with what is occuring in the real=20 world.
 
Justin = Rietz
------=_NextPart_000_003C_01C5C4E8.9A4F6B40-- Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8K2mMcJ014901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Sep 2005 19:48:23 -0700 Received: from pool-70-22-16-88.balt.east.verizon.net ([70.22.16.88] helo=[192.168.1.47]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1EHYAS-0005GL-OI; Mon, 19 Sep 2005 22:47:37 -0400 Message-ID: <432F7840.6050608@solidmatrix.com> Date: Mon, 19 Sep 2005 22:47:28 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Carl S. Gutekunst" Subject: Re: [feedback-report] Feedback types References: <432B321D.7020505@solidmatrix.com> <200509191837.j8JIbWkU007232@sb7.songbird.com> <20050919190320.GA20415@gp.word-to-the-wise.com> <432F163B.7070701@habeas.com> In-Reply-To: <432F163B.7070701@habeas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-MailScanner-From: yakovs@solidmatrix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - mipassoc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com X-Source: X-Source-Args: X-Source-Dir: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Cc: abuse-feedback-report@mipassoc.org X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2005 02:48:39 -0000 Carl S. Gutekunst wrote: > Steve Atkins wrote: > >> Doug Otis wrote: >> >>> As this is relatively new, and there could be future requirements that >>> invite modification, then finding some type of convention for extending >>> the form seems useful. >>> >> >> The whole concept behind a standard reporting format is that it's, well, >> standard. It's well-defined and can be reliably parsed and the semantics >> of the report can be mechanically extracted and understood. >> >> If there are any elements of the report that my code does not >> understand then I have no way of knowing whether my partial parse of >> the incoming report is an accurate understanding of what the report is. >> > Is it reasonable to give the feedback type the same sort of rigid (and > restricted) definition as the MIME primary content types? That seems to > be what Steve is asking for; certainly the arguments are similar. > > (Note this argues against fine-grained feedback types.) > There is also a possibility of setting up a provision type registry and a permanent type registery, like the ones that exist for message headers. What I am trying to determine among other things is whether a 4-6 week waiting period for permanent registration is sufficient. Yakov Received: from greendrazi.com (63-207-218-133.ded.pacbell.net [63.207.218.133]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8JJo5m7015664 for ; Mon, 19 Sep 2005 12:50:06 -0700 Received: from [10.9.8.20] (63-207-218-130.ded.pacbell.net [63.207.218.130]) by greendrazi.com (Postfix) with ESMTP id B206818D; Mon, 19 Sep 2005 12:49:15 -0700 (PDT) Message-ID: <432F163B.7070701@habeas.com> Date: Mon, 19 Sep 2005 12:49:15 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Atkins Subject: Re: [feedback-report] Feedback types References: <432B321D.7020505@solidmatrix.com> <200509191837.j8JIbWkU007232@sb7.songbird.com> <20050919190320.GA20415@gp.word-to-the-wise.com> In-Reply-To: <20050919190320.GA20415@gp.word-to-the-wise.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: csg@habeas.com Cc: abuse-feedback-report@mipassoc.org X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 19:50:19 -0000 Steve Atkins wrote: > Doug Otis wrote: > >>As this is relatively new, and there could be future requirements that >>invite modification, then finding some type of convention for extending >>the form seems useful. >> >> >The whole concept behind a standard reporting format is that it's, well, >standard. It's well-defined and can be reliably parsed and the semantics >of the report can be mechanically extracted and understood. > >If there are any elements of the report that my code does not >understand then I have no way of knowing whether my partial parse of >the incoming report is an accurate understanding of what the report is. > Is it reasonable to give the feedback type the same sort of rigid (and restricted) definition as the MIME primary content types? That seems to be what Steve is asking for; certainly the arguments are similar. (Note this argues against fine-grained feedback types.) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8JJPbPb012491 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 19 Sep 2005 12:25:37 -0700 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8JJOoel031295 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 19 Sep 2005 12:24:50 -0700 In-Reply-To: <200509191837.j8JIbWkU007232@sb7.songbird.com> References: <200509191837.j8JIbWkU007232@sb7.songbird.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BC78E9F-22D3-4221-A17E-0BFBF1B7FBB6@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [feedback-report] Feedback types Date: Mon, 19 Sep 2005 12:24:52 -0700 To: Justin Rietz X-Mailer: Apple Mail (2.734) X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dotis@mail-abuse.org Cc: abuse-feedback-report@mipassoc.org X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 19:25:46 -0000 On Sep 19, 2005, at 11:36 AM, Justin Rietz wrote: > > This was my thought. I would like to see reporters be able to use > custom > types without breaking the ARF standard, but allow recipients or > the reports > to choose whether or not they want to accept the non-standard > types. Until > there is significant use of ARF, it is difficult to say what > feedback types > will be the most usefull. With the risk of making things more > complex, their > could be a central repository where reporters could post > definitions of > their custom feedback types. Just a though. > > Is there a next step to take in order to make an official proposal > and get a > "yea" or "nay"? While the use of the "x-" convention would allow private bi-lateral extensions, there should a standards (IANA) registry that indicates names for defined fields in the specifications. This registry may also indicate which version of the document first defined the field. Perhaps the "x-" format could be "x-#" where this would serve as a place holder. Perhaps maawg would have a series of proposed names, where this organization defines the use of these names. Eventually, a proposed name could be accepted within the specification. For computer peripherals, it was common for companies to be assigned their own codes to prevent extensions from being confused. Company or organization name space collision should be a minor concern and could be assisted by simply have an informal name registry that logs the organization name space use. -Doug Received: from gp.word-to-the-wise.com (gp.word-to-the-wise.com [64.71.176.18]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8JJ6FHt010241 for ; Mon, 19 Sep 2005 12:06:15 -0700 Received: by gp.word-to-the-wise.com (Postfix, from userid 500) id BA8D88FC07E; Mon, 19 Sep 2005 12:03:20 -0700 (PDT) Date: Mon, 19 Sep 2005 12:03:20 -0700 From: Steve Atkins To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types Message-ID: <20050919190320.GA20415@gp.word-to-the-wise.com> References: <432B321D.7020505@solidmatrix.com> <200509191837.j8JIbWkU007232@sb7.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509191837.j8JIbWkU007232@sb7.songbird.com> User-Agent: Mutt/1.4.1i X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: steve@word-to-the-wise.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 19:06:16 -0000 On Mon, Sep 19, 2005 at 11:36:44AM -0700, Justin Rietz wrote: > > As this is relatively new, and there could be future requirements that > invite modification, then finding some type of convention for extending the > form seems useful. > > > -Doug > > This was my thought. I would like to see reporters be able to use custom > types without breaking the ARF standard, but allow recipients or the reports > to choose whether or not they want to accept the non-standard types. Until > there is significant use of ARF, it is difficult to say what feedback types > will be the most usefull. With the risk of making things more complex, their > could be a central repository where reporters could post definitions of > their custom feedback types. Just a though. The whole concept behind a standard reporting format is that it's, well, standard. It's well-defined and can be reliably parsed and the semantics of the report can be mechanically extracted and understood. If there are any elements of the report that my code does not understand then I have no way of knowing whether my partial parse of the incoming report is an accurate understanding of what the report is. If a particular sender of reports and a particular receiver agree bilaterally to an extension then that's solely between those two parties, and there's absolutely nothing to stop them using that extension. But that's a very different case to crafting a report that has your own custom extensions, sending it to someone who accepts ARF reports and expecting their code to understand what the report means and to handle it correctly. Cheers, Steve > Is there a next step to take in order to make an official proposal and get a > "yea" or "nay"? > > -Justin > > > -----Original Message----- > From: Yakov Shafranovich [mailto:YakovS@solidmatrix.com] > Sent: Friday, September 16, 2005 1:59 PM > To: Justin Rietz > Cc: abuse-feedback-report@mipassoc.org > Subject: Re: [feedback-report] Feedback types > > Justin Rietz wrote: > > I apologize in advance if this has been discussed previously - I am > > new to this list and wasn't able to find anything in the archives. > > > > Regarding feedback types, the spec says that these are extensible, but > > that new types need to be approved. Two questions: > > > > **Was there consideration given to allowing custom feedback types as > > long as they followed the specified format? There could still be > > required types that everyone would have to support. This would allow > > for customization based upon the scenario in which the standard is > > being used, and an entity receiving ARF reports could chose to accept > > or reject custom types. > > > > At this time there is no provision for custom types. However, I have been > thinking to either allow "x-*" types like other IETF standards AND/OR > mentioning in the draft that unknown types should be ignored. > > > **I am unclear on how the proposal/acceptance process works for new > > feedback types? If someone had a type they would like to propose now, > > what would they need to do? > > > > It would follow the standard IANA procedures for where a designated expert > is used (see RFC 2434). In practice, the IESG, IANA and its appointed expert > would decide on the proper procedure. It would probably be something like a > public post to mailing list and a four week review, although IANA or IESG > might decide otherwise. > > To propose a new type now, the best way is to post a message here and > describe what you have in mind. Since the specification has not been > submitted yet to the IETF for approval, it is a bit fluid. > > Yakov > > _______________________________________________ > abuse-feedback-report mailing list > abuse-feedback-report@mipassoc.org > http://mipassoc.org/mailman/listinfo/abuse-feedback-report Received: from mx1.goodmailsystems.com (mx3.goodmailsystems.com [67.110.227.4]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8JIbWkU007232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Sep 2005 11:37:32 -0700 Message-Id: <200509191837.j8JIbWkU007232@sb7.songbird.com> Received: (qmail 11833 invoked from network); 19 Sep 2005 18:36:46 -0000 Received: from unknown (HELO justint41) (authenticated:justin@[10.34.3.4]) (envelope-sender ) by mx1.goodmailsystems.com (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 19 Sep 2005 18:36:46 -0000 From: "Justin Rietz" To: Subject: RE: [feedback-report] Feedback types Date: Mon, 19 Sep 2005 11:36:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW7AYFiesmf4nN1SmS6WwBv8OGGOQCRotAQ In-Reply-To: <432B321D.7020505@solidmatrix.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: justin@goodmailsystems.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 18:37:35 -0000 > As this is relatively new, and there could be future requirements that invite modification, then finding some type of convention for extending the form seems useful. > -Doug This was my thought. I would like to see reporters be able to use custom types without breaking the ARF standard, but allow recipients or the reports to choose whether or not they want to accept the non-standard types. Until there is significant use of ARF, it is difficult to say what feedback types will be the most usefull. With the risk of making things more complex, their could be a central repository where reporters could post definitions of their custom feedback types. Just a though. Is there a next step to take in order to make an official proposal and get a "yea" or "nay"? -Justin -----Original Message----- From: Yakov Shafranovich [mailto:YakovS@solidmatrix.com] Sent: Friday, September 16, 2005 1:59 PM To: Justin Rietz Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types Justin Rietz wrote: > I apologize in advance if this has been discussed previously - I am > new to this list and wasn't able to find anything in the archives. > > Regarding feedback types, the spec says that these are extensible, but > that new types need to be approved. Two questions: > > **Was there consideration given to allowing custom feedback types as > long as they followed the specified format? There could still be > required types that everyone would have to support. This would allow > for customization based upon the scenario in which the standard is > being used, and an entity receiving ARF reports could chose to accept > or reject custom types. > At this time there is no provision for custom types. However, I have been thinking to either allow "x-*" types like other IETF standards AND/OR mentioning in the draft that unknown types should be ignored. > **I am unclear on how the proposal/acceptance process works for new > feedback types? If someone had a type they would like to propose now, > what would they need to do? > It would follow the standard IANA procedures for where a designated expert is used (see RFC 2434). In practice, the IESG, IANA and its appointed expert would decide on the proper procedure. It would probably be something like a public post to mailing list and a four week review, although IANA or IESG might decide otherwise. To propose a new type now, the best way is to post a message here and describe what you have in mind. Since the specification has not been submitted yet to the IETF for approval, it is a bit fluid. Yakov Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8GLwZm6020956 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 16 Sep 2005 14:58:35 -0700 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8GLvnSA031620 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 16 Sep 2005 14:57:49 -0700 In-Reply-To: <20050916212643.GB23637@gp.word-to-the-wise.com> References: <20050916212643.GB23637@gp.word-to-the-wise.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01B9D63F-75BF-4084-BA96-8FC9F716C89B@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [feedback-report] Feedback types Date: Fri, 16 Sep 2005 14:57:47 -0700 To: Steve Atkins X-Mailer: Apple Mail (2.734) X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dotis@mail-abuse.org Cc: abuse-feedback-report@mipassoc.org X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 21:58:43 -0000 On Sep 16, 2005, at 2:26 PM, Steve Atkins wrote: > On Fri, Sep 16, 2005 at 04:59:09PM -0400, Yakov Shafranovich wrote: > >> >> At this time there is no provision for custom types. However, I have >> been thinking to either allow "x-*" types like other IETF standards >> AND/OR mentioning in the draft that unknown types should be ignored. >> > > I think that ignoring unknown types is a bad idea. The whole idea > behind having standardised types is so that reports can be handled > automatically all of the time, with no confusion. > > Encouraging non-standard types (by doing anything other than rejecting > any report that uses them) will reduce the chance of successful > interoperation. > > One redeeming feature of supporting non-standard types would be that > it's one step better than overloading a free text field, which is what > some people would do otherwise. I still think that the ideal situation > is where any up-to-date ARF receiver can receive and parse with 100% > accuracy a report sent by any ARF sender. > > There's a version field in the spec. If the version of the report is > later than the highest version that the receiver can handle it has > several options. At _that_ point ignoring unknown types seems like > a better thing to do than throwing up its hands and giving up. > > Additionally, if the sender and the receipient of a report have > agreed on an extension then there's nothing that prevents them > from using it. But the report is then not strictly an ARF format > report, and shouldn't be sent to any recipient who hasn't agreed > to that extension (and would hopefully be rejected if it were). > > Adding an explicit namespace for non-standard types seems reasonable > on the surface, but I suspect it would cause people to avoid actually > standardising something that should be standardised (look at how > widespread use of multipart/x-www-form-url-encoded, for instance). > Making standardisation of new types reasonably quick and easy is > another requirement for avoiding that problem, of course. As this is relatively new, and there could be future requirements that invite modification, then finding some type of convention for extending the form seems useful. -Doug Received: from gp.word-to-the-wise.com (gp.word-to-the-wise.com [64.71.176.18]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8GLTYrs018628 for ; Fri, 16 Sep 2005 14:29:34 -0700 Received: by gp.word-to-the-wise.com (Postfix, from userid 500) id CFD988FC07D; Fri, 16 Sep 2005 14:26:43 -0700 (PDT) Date: Fri, 16 Sep 2005 14:26:43 -0700 From: Steve Atkins To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types Message-ID: <20050916212643.GB23637@gp.word-to-the-wise.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432B321D.7020505@solidmatrix.com> User-Agent: Mutt/1.4.1i X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: steve@word-to-the-wise.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 21:29:38 -0000 On Fri, Sep 16, 2005 at 04:59:09PM -0400, Yakov Shafranovich wrote: > Justin Rietz wrote: > >I apologize in advance if this has been discussed previously - I am new > >to this list and wasn't able to find anything in the archives. > > > >Regarding feedback types, the spec says that these are extensible, but > >that new types need to be approved. Two questions: > > > >**Was there consideration given to allowing custom feedback types as > >long as they followed the specified format? There could still be > >required types that everyone would have to support. This would allow for > >customization based upon the scenario in which the standard is being > >used, and an entity receiving ARF reports could chose to accept or > >reject custom types. > > > > At this time there is no provision for custom types. However, I have > been thinking to either allow "x-*" types like other IETF standards > AND/OR mentioning in the draft that unknown types should be ignored. I think that ignoring unknown types is a bad idea. The whole idea behind having standardised types is so that reports can be handled automatically all of the time, with no confusion. Encouraging non-standard types (by doing anything other than rejecting any report that uses them) will reduce the chance of successful interoperation. One redeeming feature of supporting non-standard types would be that it's one step better than overloading a free text field, which is what some people would do otherwise. I still think that the ideal situation is where any up-to-date ARF receiver can receive and parse with 100% accuracy a report sent by any ARF sender. There's a version field in the spec. If the version of the report is later than the highest version that the receiver can handle it has several options. At _that_ point ignoring unknown types seems like a better thing to do than throwing up its hands and giving up. Additionally, if the sender and the receipient of a report have agreed on an extension then there's nothing that prevents them from using it. But the report is then not strictly an ARF format report, and shouldn't be sent to any recipient who hasn't agreed to that extension (and would hopefully be rejected if it were). Adding an explicit namespace for non-standard types seems reasonable on the surface, but I suspect it would cause people to avoid actually standardising something that should be standardised (look at how widespread use of multipart/x-www-form-url-encoded, for instance). Making standardisation of new types reasonably quick and easy is another requirement for avoiding that problem, of course. > >**I am unclear on how the proposal/acceptance process works for new > >feedback types? If someone had a type they would like to propose now, > >what would they need to do? > > > > It would follow the standard IANA procedures for where a designated > expert is used (see RFC 2434). In practice, the IESG, IANA and its > appointed expert would decide on the proper procedure. It would probably > be something like a public post to mailing list and a four week review, > although IANA or IESG might decide otherwise. > > To propose a new type now, the best way is to post a message here and > describe what you have in mind. Since the specification has not been > submitted yet to the IETF for approval, it is a bit fluid. Cheers, Steve Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8GL04LK016114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Sep 2005 14:00:05 -0700 Received: from pool-70-17-235-55.balt.east.verizon.net ([70.17.235.55] helo=[192.168.1.42]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1EGNIl-0006Mo-C7; Fri, 16 Sep 2005 16:59:19 -0400 Message-ID: <432B321D.7020505@solidmatrix.com> Date: Fri, 16 Sep 2005 16:59:09 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Rietz Subject: Re: [feedback-report] Feedback types References: <200509161924.j8GJOsKn007977@sb7.songbird.com> In-Reply-To: <200509161924.j8GJOsKn007977@sb7.songbird.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-MailScanner-From: yakovs@solidmatrix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - mipassoc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com X-Source: X-Source-Args: X-Source-Dir: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Cc: abuse-feedback-report@mipassoc.org X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 21:00:09 -0000 Justin Rietz wrote: > I apologize in advance if this has been discussed previously - I am new > to this list and wasn't able to find anything in the archives. > > Regarding feedback types, the spec says that these are extensible, but > that new types need to be approved. Two questions: > > **Was there consideration given to allowing custom feedback types as > long as they followed the specified format? There could still be > required types that everyone would have to support. This would allow for > customization based upon the scenario in which the standard is being > used, and an entity receiving ARF reports could chose to accept or > reject custom types. > At this time there is no provision for custom types. However, I have been thinking to either allow "x-*" types like other IETF standards AND/OR mentioning in the draft that unknown types should be ignored. > **I am unclear on how the proposal/acceptance process works for new > feedback types? If someone had a type they would like to propose now, > what would they need to do? > It would follow the standard IANA procedures for where a designated expert is used (see RFC 2434). In practice, the IESG, IANA and its appointed expert would decide on the proper procedure. It would probably be something like a public post to mailing list and a four week review, although IANA or IESG might decide otherwise. To propose a new type now, the best way is to post a message here and describe what you have in mind. Since the specification has not been submitted yet to the IETF for approval, it is a bit fluid. Yakov Received: from mx1.goodmailsystems.com (mx3.goodmailsystems.com [67.110.227.4]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8GJOsKn007977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Sep 2005 12:24:55 -0700 Message-Id: <200509161924.j8GJOsKn007977@sb7.songbird.com> Received: (qmail 19203 invoked from network); 16 Sep 2005 19:24:08 -0000 Received: from unknown (HELO justint41) (authenticated:justin@[10.34.3.4]) (envelope-sender ) by mx1.goodmailsystems.com (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 16 Sep 2005 19:24:08 -0000 From: "Justin Rietz" To: Date: Fri, 16 Sep 2005 12:24:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C5BAB9.89571970" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW69DWLYD5kZyA9S/KULDlLmnydhw== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: justin@goodmailsystems.com Subject: [feedback-report] Feedback types X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 19:25:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C5BAB9.89571970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I apologize in advance if this has been discussed previously - I am new to this list and wasn't able to find anything in the archives. Regarding feedback types, the spec says that these are extensible, but that new types need to be approved. Two questions: **Was there consideration given to allowing custom feedback types as long as they followed the specified format? There could still be required types that everyone would have to support. This would allow for customization based upon the scenario in which the standard is being used, and an entity receiving ARF reports could chose to accept or reject custom types. **I am unclear on how the proposal/acceptance process works for new feedback types? If someone had a type they would like to propose now, what would they need to do? Thanks, Justin Rietz Goodmail Systems, Inc. ------=_NextPart_000_001A_01C5BAB9.89571970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I apologize in = advance=20 if this has been discussed previously - I am new to this list and = wasn't=20 able to find anything in the archives.

Regarding feedback types, the spec says that these are = extensible, but that new types need to be approved. Two = questions:

**Was there consideration given to allowing custom = feedback=20 types as long as they followed the specified format? There could still = be=20 required types that everyone would have to support. This would allow for = customization based upon the scenario in which the standard is being = used, and=20 an entity receiving ARF reports could chose to accept or reject custom=20 types.

**I am unclear on how the proposal/acceptance process = works for=20 new feedback types? If someone had a=20 type they would like to = propose now,=20 what would they need to=20 do?

Thanks,

Justin = Rietz
Goodmail Systems,=20 Inc.

------=_NextPart_000_001A_01C5BAB9.89571970-- Received: from mta.skylist.com (mta.skylist.com [69.56.16.2]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8FJVtrh026846 for ; Thu, 15 Sep 2005 12:31:55 -0700 Received: from mail.skylist.net (mail.skylist.net [66.219.61.94]) by mta.skylist.com (8.11.6/8.11.6) with ESMTP id j8FJV8M04928 for ; Thu, 15 Sep 2005 14:31:08 -0500 Received: from 66.25.153.39 by mail.skylist.net for ; Thu, 15 Sep 2005 14:31:00 -0500 Message-ID: <4329CBF6.8000106@skylist.com> Date: Thu, 15 Sep 2005 14:31:02 -0500 From: Joshua Baer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Testing tools References: <4321E768.4000004@solidmatrix.com> <4323D92D.6090100@skylist.com> In-Reply-To: <4323D92D.6090100@skylist.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: josh@skylist.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 19:31:57 -0000 > > Yakov Shafranovich wrote: > >> Is anyone interested in setting up some testing tools for ARF >> reports? I was thinking along the lines of: > We're working on some implementation libraries. For now, here are 2 testing email addresses. To have an abuse report sent to you, send an email message to arf-sample@skylist.com To validate an abuse report syntax, send the abuse report to arf-validate@skylist.com Please let me know if you have any problems, requests, or "feedback" (har har). ~Josh Received: from mta.skylist.com (mta.skylist.com [69.56.16.2]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8B7EgUA020692 for ; Sun, 11 Sep 2005 00:14:43 -0700 Received: from mail.skylist.net (mail.skylist.net [66.219.61.94]) by mta.skylist.com (8.11.6/8.11.6) with ESMTP id j8B7DuM24882 for ; Sun, 11 Sep 2005 02:13:56 -0500 Received: from 66.25.153.39 by mail.skylist.net for ; Sun, 11 Sep 2005 02:13:46 -0500 Message-ID: <4323D92D.6090100@skylist.com> Date: Sun, 11 Sep 2005 02:13:49 -0500 From: Joshua Baer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Testing tools References: <4321E768.4000004@solidmatrix.com> In-Reply-To: <4321E768.4000004@solidmatrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: josh@skylist.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 07:14:49 -0000 Yakov Shafranovich wrote: > Is anyone interested in setting up some testing tools for ARF reports? > I was thinking along the lines of: > > o email address that will bounce back with an ARF report encapsulating > the email sent to it > > o reference library We'll produce these two. ~Josh Received: from gp.word-to-the-wise.com (gp.word-to-the-wise.com [64.71.176.18]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j89JvKAk011457 for ; Fri, 9 Sep 2005 12:57:20 -0700 Received: by gp.word-to-the-wise.com (Postfix, from userid 500) id BDE248FC084; Fri, 9 Sep 2005 12:54:40 -0700 (PDT) Date: Fri, 9 Sep 2005 12:54:40 -0700 From: Steve Atkins To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Testing tools Message-ID: <20050909195440.GB17753@gp.word-to-the-wise.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: steve@word-to-the-wise.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 19:57:25 -0000 On Fri, Sep 09, 2005 at 03:50:00PM -0400, Yakov Shafranovich wrote: > Is anyone interested in setting up some testing tools for ARF reports? I > was thinking along the lines of: > > o email address that will bounce back with an ARF report encapsulating > the email sent to it > o web page that an ARF report can be uploaded to and checked for validity > o email service that can check ARF reports sent to it for validity > o reference library I'm working on 2 and 3 (in my copious spare time, so I don't have a release scheduled). Cheers, Steve Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j89Jos11010837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Sep 2005 12:50:55 -0700 Received: from pool-70-22-72-60.balt.east.verizon.net ([70.22.72.60] helo=[192.168.1.47]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1EDosv-00068o-FD for abuse-feedback-report@mipassoc.org; Fri, 09 Sep 2005 15:50:05 -0400 Message-ID: <4321E768.4000004@solidmatrix.com> Date: Fri, 09 Sep 2005 15:50:00 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-MailScanner-From: yakovs@solidmatrix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - mipassoc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com X-Source: X-Source-Args: X-Source-Dir: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Subject: [feedback-report] Testing tools X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 19:51:02 -0000 Is anyone interested in setting up some testing tools for ARF reports? I was thinking along the lines of: o email address that will bounce back with an ARF report encapsulating the email sent to it o web page that an ARF report can be uploaded to and checked for validity o email service that can check ARF reports sent to it for validity o reference library Yakov