[taugh.com-johnl] Re: [feedback-report] New version of the ARF draft

[John R Levine]

>>   * miscategorized - indicates that the content categorization applied in
>>     connection with a certification or reputation system was incorrect
>
> What'll this be used for?

I added it for VBR but it's intended to be more general.  We observe that 
certification or reputation systems will probably have different opinions 
about different kinds of mail, e.g., a bank regulator would vouch for the 
banks' transactions but not their ads.  Lacking A.I. to tell mechanically 
what category a message falls into, we expect senders to put assertions 
into a header (VBR, for example), that this is a transaction, this is an 
ad, etc.  This code means they lied, it claimed to be one thing but was 
really another.

>>   * 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.
>
> Doh, I should've thought of that.  *grin*

Yeah, the hope is to put together the pieces to enable add-ins to regular 
MUAs with a spam/not-spam button that actually works like the ones AOL and 
Yahoo have.  This is one piece, it also needs something in the mail to say 
"we delivered this to you and we thought it was/wasn't spam".  It occurs 
to me that this is only a small step beyond Murray's draft about 
authentication results.

>> 1.  Whether encoding of the machine readable part should be limited to 7-bit
> It should follow the same convention as email addresses and URIs, whatever 
> that is these days.

The scenario is that you have a spam in hand where some characters have 
the high bit set, probably because some piece of Korean spamware blatted 
it out that way.  Since SMTP is usually only 7 bit, how do you send back 
the copy of the spam.  The he-man approach is to use 8BITMIME, do content 
negotiation for each SMTP hop, and downcode if need be.  The wimpy 
approach is just to use base64 on the way out.  Since everyone in the 
world speaks base64, and downcoding on the way has all sorts of problems 
such as breaking any signature on the ARF message, I vote for the latter.

>> 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.
> I say change it to "unsubscribe"

Remember that we're supposed to reflect existing practice.  Has anyone 
ever seen an opt-out or opt-out-list in the wild?  If so, we gotta leave 
them in, if not, change is fine.

>> 3.   Whether the "from" address should be required to be a human just
>>      like other RFCs in the "message/report" family.
>
> No, but the address SHOULD accept messages (vs. bouncing 'em) --

Well, keeping in mind actual practice, the actual ARF messages I see 
mostly come from scomp at aol.net and fbl at abuse.earthlink.net.  I haven't 
tried writing to those addresses.  Anyone know who or what answers?

> If there were such an indicator, would the mungers in the room use it?

Good question.

> Now for the draft itself (I may have submitted the same comments on previous 
> drafts, not sure.)

I'll collect comments for another day or so and do another version.  I'd 
like to send it off to I-D on Monday to give it a week to get into the I-D 
archive.

Regards,
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.