daily response Wednesday 17 mar

As a work-flow decision I am going to try to make at most one post to 
this WG per day. Is
the list available in digest? that would ease the daily response 
workflow model.

    1: Investigate the requirements for a common header to be 
    produced by filters (something like "Filtered-By"), so MUAs do 
    not have to look for different types of headers

A requirement is something like "Has a universally recognized name"
not what the name is.   One type of header currently matters in
ordering and is always added at the beginning: the Received: header.
IMO, filter report headers make sense immediately following Received:
headers.

I prefer one header with all the data crammed into it in a series
of well-defined key=value pairs rather than many headers each with
its own extension of the header name.

   NOT PREFERRED BY DN:
   Filtered-By: foobarbazfilter
   Filtered-By-Version: 1.2devel20070317build2
   Filtered-By-Heuristic-Probability-Is-Ham: 93
   Filtered-By-Heuristic-Probability-Is-Spam: 12

   PREFERRED BY DN:
   Filtered-By: foobarbazfilter version=1.2devel20070317build2
     spamp=12 spamq=93

The SMTP extension mechanisms to date have all taken the first approach,
except for Received:.  Adding a spamp and a spamq to Received: might be
a good thing for a heuristic analysis system to do instead of something else.
Configuring a MUA prefiler to look inside a particular header will be
tricky.

Which brings another requirement.  We must decide what MUA we want to
support.  Reccomending munging the Subject line seems to be a good practice
for things like list servers.


Laird Breyer does not trust people to edit the subject lines.
I know from personal amusement and validation of such that a
lot of people are amused by cascading subject tags; they are not
a problem.  Subject line munging seems best for resending services
that are not intended as primary mailboxes. 

Prefixing a spam tag to the subject line (rather than postfixing it)
is superior because you can sort-by-subject and sweep all tagged
messages into the same dust-pan.  I think a spam tag put in by
a listserv that tags the subject line (like ASRG does) should put
the spam tag after the mailing list name.  

Maybe we can agree on and produce a BCP on subject line alterations.

* subject line alterations need to be at the beginning so alpha
  sorting will group them

* do not automatically duplicate a tag if your tag appears

...

That would be a good thing to put in a page on the wiki.  A wiki is
a better thing than a mailing list for collaborating on documents
because it is a collaborative channel; but all references to it
should include the full url.  (I want to incorporate the CGI ACL system
I have developed into a wiki, but this is OT for this forum)


Laird Breyer wrote:

>On Mar 16 2004, Philip Miller wrote:
>
>>> there's no reason one 
>>> person's tags should be visible to any other person.

Philip seems to be talking about in-MUA filtering, and this is
true, when I forward you something I have kept in my jokes folder
there's no reason to have logged in the headers of the message
that it was automatically filed in a file labeled "Kathy" on delivery.

But keeping them out of the message headers is a reason to come up
with a completely new channel for filtering and permissions and so on
that would be refered to by a unique ID in the header (message-ID and
POP3 UIDL would both work) and would be the proper channel for
standard communication of "end-user marked this as spam" back to a
centralized bayesian scanner, after extenstions to IMAP and POP3 are
implemented.  In the "bayesian community" scenario.  

We need a list of filtering scenarios.

>But in this case, subject tags are inserted as a hack by certain
>filters, to create functionality in a MUA which doesn't exist, and for
>which the MUA wasn't built. OE doesn't filter on arbitrary X- headers,
>but it does filter on subject contents. So that's why the tag is put
>there. 

Evolution can filter on arbitrary headers, so can Communicator. So
can Thunderbird (but you have to restart the filter definition widget
after adding the header. Someone submit a bug report?)  Following
the current practice in MUA interface, if we, this WG, could agree on
a name of a filter, it is reasonable to expect that it might appear
in the standard header lists in MUA delivery filter rule editing tools.

>... the filter hacks the MUA, ...

I do not understand this point.  There appears to be confusion
between MTA filtering and MUA filtering.

>>> If spammers hijack a relay trusted by any number of people in an arbitrary 
>>> role, we have bigger worries than the spammer scanning tags coming through 
>>> and spoofing them.
>
>
>Fair enough. There are lots more things that can be done by spammers
>at that point. We can probably ignore that angle.

a BCP on responding to misconfiguration would be an endless discussion too

> > keep [discussion] synchronized > between the list here and the Wiki. 
> Do I now have to write the same > things both here and the Wiki? What 
> if a new participant doesn't know > about the Wiki, or doesn't know 
> about the list? The Wiki was simply a place to put some of the 
> thoughts into. If anyone wants to make it into a document instead, 
> please go ahead. I just used the Wiki as a shortcut for document 
> writing. Yakov 


ignorant wishlist on wiki use:

* have ability to create new pages and link to 'em as well as editing
  the pages that are there

* have ability to trivially create self-linking anchors and link to 'em
   ( things like <a name="PARA7"></a><a href="#PARA7">(*)</a> 
     could automatically appear every few lines, or could just do this
     to any asterisk that is not inside a link already

* whenever you materialyl alter something on the wiki -- anything
more substantial than corecting speling -- post a link to what
you changed, to the list, or at least send the link to whoever else
is working on that little bit to discuss it.

* add paragraph anchors to list archive presentation system so
you can link to a paragraph in the list archive instead of just
linking to whole messages (or threads)

____________

"just throw it in the DNS" is no more efficient than extending
SMTP/IMAP/POP and requires agreement of even more players

_____________


> I just had a thought: Is there any reason that respondents should want 
> the tags to appear in outgoing response messages? Is there any reason 
> that a message originator should see how his recipient(s) tagged it? I 
> think these 2 cases provide a strong justification for 
> stripping/replacing tags at the recipient end, and stripping tags at 
> the sender side. Philip Miller


We desparately need named scenarios.  A list-server with an open post policy
could run a community bayesian filter and do subject-line-tagging. Making
this work more elegantly than writing an extension to EZMLM that handles
a [email protected] reporting address might be as simple
as defining for general use a "Spam-Report-To:" header that is an e-mail
address where you want things forwarded to (WITHOUT ANNOTATION) (also 
a Spam-Not-Report-To header -- I'm imagining the bayesian built into
Thunderbird working at a list-server and those are its controls)

As I understand it, the headers than spamassassin appends are mostly
informative and are in place for tuning.  There are a lot of articles
on BCPs in filtering, generally from the point of view of instructions
for how to best configure one product or another.


What was the link to the wiki again?  If I extend the wiki we are using
will my patches be accepted?  "Customized wiki used by ASRG filtering WG"
would be a nifty brag point.



-- 
[email protected].
cat and buttered toast