Re: [Asrg] NOT E-Postage - Filtering Header Draft Posted

On 4/28/2004 10:29 AM, Philip Miller sent forth electrons to convey:

> Matthew Elvey wrote:
>
>> On 4/26/04 1:02 PM, Philip Miller sent forth electrons to convey:
>>
>>> Sorry to divert you all from the critical debate over E-Postage. ;-)
>>>
>>> I'm posting updated versions of my Filtering Header draft at 
>>> <http://millenix.zemos.net/asrg-filtering/>. If anyone with any 
>>> interest in the operation of email filters could take a look at it 
>>> and post comments and/or suggestions here, I'd appreciate it.
>>
>>
>> Good start.  Have you looked at
>
>
> Thanks.
>
>> draft-daboo-sieve-spamtest-01.txt?
>> <http://www.rnp.br/ietf/internet-drafts/draft-daboo-sieve-spamtest-01.txt> 
>>
>> It has some relevant stuff to say. e.g.
>
>
> I'll take a look at it. If you see good places to integrate its 
> material into this draft, please send me patches. 

I'll leave it to those on the filtering@ list.

>
>> I'd suggest using the following (with credit):
>>
>>    The spamtest result is a string containing a numeric value in the
>>    range "0" (zero) through "10", with "0" meaning the message is
>>    definitely clear of spam, and "10" meaning the message is definitely
>>    spam.  The underlying SIEVE implementation will map whatever spam
>>    check is done into this numeric range, as appropriate.  If the
>>    message has not been categorised by any spam checking tools, then
>>    the spamtest result is "NIL".
>
>
> Although it's not clear in the text of the draft yet, I think it's 
> preferential to state a classification and a statistical confidence in 
> that classification. This header should be useful for more than just 
> spam+ or spam- determinations.

0=spam- ; 10=spam+ ; 1-9 could be statistical confidence, or could 
instead be like what Meng Wong recently described as classes of mail.

>
> I will definitely give that a read, and probably add it to the 
> references, although it being an I-D rather than RFC makes that 
> slightly problematic.

Good news!  It is an RFC (surprised me!) discovered it as I was looking 
into how it might progress.

http://www.faqs.org/rfcs/rfc3685.html

>
>> (Perhaps requiring no more than one Filtered: header, and munging of 
>> any extant ones to Filtered-old: would be easier than this timestamp 
>> stuff, but I'm guessing you already thought of this and like your 
>> idea better.)
>
>
> The design as stated means that any downstream tools and the end-user 
> have a complete historical perspective of the analysis done on the 
> message, while being able to easily authenticate what was added at or 
> after 'trusted' points in the message transport system.
>
>> Go ahead and post your reply to filtering@ if you think this email 
>> has merit.
>
>
> I appreciate the comments greatly. Thank you. 

Nice of you to author the draft. (I expect my email to the list will be 
rejected, as I'm not a subscriber, and just wanted to pass on this 
advice and get back to MARID stuff.)