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

[Alessandro Vesely <[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.)

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

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