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

[Ned Freed <[e-mail]>]

> On Sun 13/May/2012 12:18:22 +0200 Ned Freed wrote:
> >
> >> In all of the webmails I can think of, a message has a displayed
> >> spam state, either with a visible flag or implicitly because it's
> >> in the spam folder. When you hit the junk/nojunk button, the
> >> state changes immediately.
> >
> > Exactly. And the problem with that is generating reports either
> > depends on reporting the transition or comparing the the presented
> > state with an internal state.
> >
> > I'm not overly fond of relying on notifications for this sort of
> > thing - it forces the issue on a number of design choices that have
> > serious impact on high end servers. That said, we certainly should
> > allow a notification-based approach to be used, but I see nothing
> > about having the server state available that prevents that from
> > happening. Indeed, it can be used to provide additional
> > information, such as when a user disagrees and then changes their
> > mind. (I doubt this is useful, but it's always hard to be sure
> > about this stuff.)

> Just to make sure on the terms (correct me if I'm wrong please):
> *notification* is the MUA telling the IMAP server about user activity,
> *reporting* is the server generating an ARF message and sending it to
> some heuristically determined external abuse team.  (Spam filter
> training is another server-side activity the client might want to know
> about.)

No, I'm not talking about either one of those things. I'm talking about
a notification about a flag change. I intentionally did not specify how
that notification would be sent or what it would be sent to.

> >> The server can certainly remember internally whether the state
> >> was generated automatically or set by the user, but no webmail I
> >> know displays that, so I don't see any need to build it into
> >> IMAP.
> >
> > Hidden server state is almost always a bad design choice,
> > especially when there's essentially no cost involved in exposing
> > it.

> A mail server that also keeps track of feedback loops is likely going
> to consume more than two bits per message.  But a server can set some
> flags upon acting on messages, e.g. "$reported", exclusively for MUAs
> usage.

A visible flag is more or less by definition not internal
to the server. But unless there's an accepted convention for the flag
to use, it might as well be hidden.

> > Additionally, you're assuming a separation of function across the
> > IMAP boundary that isn't always how things are implemented.
> >
> > And finally, what is or isn't *displayed* by current UIs is almost
> > always a poor thing to design around. Designs need to accommodate
> > the *functionality* provided by current UIs.

> MUA's behavior can be driven by the server, by the user, or anything
> in between, depending on configuration and server responses.

> IMHO it is possible to let SREP command and response vary from very
> basic to very data-intensive, almost independently on one another, so
> that both MUAs and servers can do as they like better.

That's exactly the argument in favor of using a new command rather than a flag.

				Ned