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

Philip Miller <[email protected]> Wed, 28 Apr 2004 13:29:58 -0400
Newsgroups gmane.ietf.asrg.filtering
Message-ID <[email protected]>
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'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.

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.

> (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.

Sincerely,
Philip Miller