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