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

Matthew Elvey wrote:
> 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.

OK.

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

Perhas I was unclear. I understand the scoring system that SIEVE uses, but I want this to be usable 
to state more than classification along the 'spamminess' axis. This is really somehwat geared toward 
the type of results POPFile generates, because most other classifiers' results are a subset of that.

'spam' will not have a defined meaning in this draft, nor will it be reserved in any way. If every 
spam filter and user decides to use that specific string of bytes to mean something generally 
synonymous, great.

The only classification I see real benefit in standardizing would be virus infected vs. clean.

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

Cool, thanks.

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

You do know that you can be a member with posting rights without having to receive the mail, right?

IIRC, you would send the following in the body of a message to majordomo AT asrg.sp.am:
> subscribe filtering
> set filtering nomail

Phil