Re: [apps-discuss] Call for Adoption: draft-ordogh-spam-reporting-using-imap

[Ned Freed <[e-mail]>]

> > It needs to be a little more complex than a single flag because you need
> > to communicate both not-spam->spam and spam->not-spam, but sure, a simpler
> > approach can be used.

> If it's a flag, you can set it or clear it like you set or clear other
> message flags.  What more do you need?

I thought I explained that, but I guess not. I'll try again.

There are actually four states:

    (1) The message was classified as spam and the user has not said anything.
    (2) The message was classified as spam but the user says it isn't.
    (3) The message was not classified as spam and the user has not said
        anything.
    (4) The message was not classified as spam but the user says it is.

You cannot represent all of those in a single bit.

> > The question is whether there's a need for something in between the client
> > generating a MARF report versus changing a flag or annotation.

> The general goal here has been to add a spam button to MUAs equivalent to
> the ones that webmail systems have.

And such a button actually allows you to present four or even more states, not
two. In many MUAs the button appearance changes depending on what the system
thought of the message.

> I have yet to see persuasive
> arguments in favor of anything more complex.  User generated MARF reports
> are a can of worms, both because they require that MUAs learn how to parse
> Received headers, including knowing which ones are local so they should
> ignore them, and that MUAs or users figure out where to send the reports.
> We already know how to do this on the server side, we have no clue on the
> user side.

That's exactly what I pointed out in my original response and what a SREP
mechanism lets you avoid.

				Ned