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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 11 May 2012 23:35:45 +0000

This is a call for adoption of draft-ordogh-spam-reporting-using-imap, an IMAP extension being developed in conjunction with the OMA EVVM working group.

This document was discussed in two previous APPSAWG meetings as we tried to find a home for it (appsawg, another working group, AD-sponsored, independent submission).  The decision was made in Paris to process it through APPSAWG.  I would like to approve the document into appsawg in about a week, but I'm making this call because I would still like to give people a chance to voice opinions on-list if there are any.

Thus, please state any opinions by the end of Friday, May 18th.  Also, if you are inclined to contribute to working on it, please say so on the list or contact the authors.

-MSK, APPSAWG co-chair

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 May 2012 17:05:48 -0700 (PDT)

> This is a call for adoption of draft-ordogh-spam-reporting-using-imap, an
> IMAP extension being developed in conjunction with the OMA EVVM working group.

> This document was discussed in two previous APPSAWG meetings as we tried to
> find a home for it (appsawg, another working group, AD-sponsored, independent
> submission).  The decision was made in Paris to process it through APPSAWG.  I
> would like to approve the document into appsawg in about a week, but I'm making
> this call because I would still like to give people a chance to voice opinions
> on-list if there are any.

> Thus, please state any opinions by the end of Friday, May 18th.  Also, if you
> are inclined to contribute to working on it, please say so on the list or
> contact the authors.

The basic idea - use an IMAP command to report a message as spam instead of
having to submit a report as a separate message - seems reasonable. That said,
given that we have an entire WG working on abuse reporting formats (MARF), the
big concern that immediately comes to mind is that this needs to be tightly
aligned with MARF reporting, because an obvious implementation strategy is to
have the back end generate a MARF report.

For example, this draft creates a "SREP abuse type registry", I see no reason
why RFC 5965's report type registry can't be used for this purpose. But if you
do that, it changes the entire architecture of SREP - SREP currently has SET
and CLEAR operations, but MARF subsumes this into the report type: not-spam is
defined in RFC 6430.

I'm much less concerned with what the overall reporting architecture is than I
am with there only being one of them. The *absolute* *last* thing we need is 
for different reporting paths to require gatewaying. Surely we've learned by
now that gateways are a bad idea? (This from the person who's probably written
more of them than anyone except Nick Shelness.)

I note in passing that BURL can be used to avoid most of the overhead involved
in building and sending a MARF report. The advantage of SREP, of course, is
that it would allow alternative reporting strategies, e.g., as a non-message
notification. But I'd rather lose that advantage than have two different
reporting architectures.

I also note in passing that the architecture of having the actual report
generated on the back end has a number of advantages, e.g., site policy
regarding things like redaction remains on the back end and doesn't have to be
distributed to clients.

Finally, an added fillip will be handling interactions where something other
than the user said "spam" but the user is now saying "not spam". SREP as
presently constitutes doesn't seem to consider this case, because CLEAR seems
to be designed to undo a previous SET. I see no similar limitation on MARF's
not-spam report type, however.

				Ned

---

From: SM <[email-masked]>
Date: Fri, 11 May 2012 17:53:59 -0700

At 16:35 11-05-2012, Murray S. Kucherawy wrote:
>This is a call for adoption of 
>draft-ordogh-spam-reporting-using-imap, an IMAP extension being 
>developed in conjunction with the OMA EVVM working group.
>
>This document was discussed in two previous APPSAWG meetings as we 
>tried to find a home for it (appsawg, another working group, 
>AD-sponsored, independent submission).  The decision was made in 
>Paris to process it through APPSAWG.  I would like to approve the 
>document into appsawg in about a week, but I'm making this call 
>because I would still like to give people a chance to voice opinions 

During the discussions about the formation of this working group, it 
was mentioned that it should not be the dumping ground for everything 
Apps-related.  As the final decision rests with the Apps ADs, I'll 
stay out of this.

I would like to thank the author of 
draft-ordogh-spam-reporting-using-imap-02 for resolving a previous a 
IPR matter.

The work on this draft would be a substantial effort.  As there is an 
IPR disclosure on draft, I am not inclined to put in any 
effort.  There is a restrictive copyright notice.  I gather that this 
draft is based on previous IETF work.  I don't see any credit being 
given in the Acknowledgements Section.

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 May 2012 18:36:52 -0700 (PDT)

I should also have noted that the example flow material goes a little further
than I'd like to see in a standard. If it is published it really should be
in a separate document.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 May 2012 22:29:37 -0400

--On Friday, May 11, 2012 23:35 +0000 "Murray S. Kucherawy"
<[email-masked]> wrote:

> draft-ordogh-spam-reporting-using-imap, an IMAP extension
> being developed in conjunction with the OMA EVVM working group.
>...
> Thus, please state any opinions by the end of Friday, May
> 18th.  Also, if you are inclined to contribute to working on
> it, please say so on the list or contact the authors.

Procedural comments only; I'll leave substantive ones to others
or for another time.

* I am strongly opposed to AppAWG taking this on unless it is
absolutely clear that the IETF has/will have change control and
that the WG is free to make changes in either the document or
the underlying specification as seems appropriate.  The history
of this document combined with the use of the "go negotiate with
the authors" copyright language (which does not appear to be
justified by prior work _in the IETF_) leaves me somewhat
uncertain on that point.

* I agree with Ned that we do not want to standardize or
propagate a number of different reporting mechanisms and
formats.  This work should not, IMO, be initiated unless
minimizing those differences is an explicit high-priority goal.

    john

---

From: "John Levine" <[email-masked]>
Date: 12 May 2012 02:54:41 -0000

The idea is fine.  When we discussed this before, once we got past the
wheel reinvention phase, there seemed to be general agreement that
this particular draft is much too complex.

I'd think that all we really need is a way for an IMAP client to set
or unset a flag or status bit on a message saying that the user
considers it to be spam, and the usual IMAP stuff to tell clients that
the flag is available.  Once the flag is set, the advice would be to
do whatever they do when they get a spam report from a user.  Maybe
they move it to another folder, maybe they send an ARF report, but I
don't think that needs to be (or even should be) normative.

I also got general expressions of interest from some large providers
that offer both webmail and IMAP.  For them, I assume that they'd do
exactly what they do when a user hits the spam button in the webmail.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 May 2012 04:02:18 +0000

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]]
> Sent: Friday, May 11, 2012 7:30 PM
> To: Murray S. Kucherawy; [email-masked]
> Subject: Re: [apps-discuss] Call for Adoption: draft-ordogh-spam-reporting-using-imap
> 
> absolutely clear that the IETF has/will have change control and that
> the WG is free to make changes in either the document or the underlying
> specification as seems appropriate.  The history of this document
> combined with the use of the "go negotiate with the authors" copyright
> language (which does not appear to be justified by prior work _in the
> IETF_) leaves me somewhat uncertain on that point.

I believe some conversation with the authors prior to today revealed that the current boilerplate was chosen in part because of the IPR claim made about the draft and in part because it plans to say "updates RFC3501", and thus he thought the current boilerplate was the correct selection.  If in fact no text was copied from RFC3501, and the IPR claim filed about the draft is sufficiently IETF-friendly, then I believe the selected boilerplate is in fact not appropriate and something more amenable to IETF handling should be chosen and the document resubmitted.

> * I agree with Ned that we do not want to standardize or propagate a
> number of different reporting mechanisms and formats.  This work should
> not, IMO, be initiated unless minimizing those differences is an
> explicit high-priority goal.

Ned's remarks about MARF hadn't occurred to me before.  I'll discuss this suggestion with our ADs, though MARF has basically already completed its chartered work list and is just waiting for its three documents in the RFC Editor queue to publish before formally shutting down.  

-MSK

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 12 May 2012 07:17:01 +0200

> don't think that needs to be (or even should be) normative.

+1

"Just" agree on a flag being "spam" and let clients and servers innovate and be clever.

   Patrik

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 May 2012 22:12:20 -0700 (PDT)

> don't think that needs to be (or even should be) normative.

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.

But it's not as flexible as a general reporting mechanism. For example,
I could easily see using this to report things like signature validation
failures.

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

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 May 2012 05:29:19 -0400

--On Saturday, May 12, 2012 04:02 +0000 "Murray S. Kucherawy"
<[email-masked]> wrote:

> Ned's remarks about MARF hadn't occurred to me before.  I'll
> discuss this suggestion with our ADs, though MARF has
> basically already completed its chartered work list and is
> just waiting for its three documents in the RFC Editor queue
> to publish before formally shutting down.

I wasn't particularly arguing for assigning this to MARF or any
place particular.  Only that the net result should not be to
increase the number of different ways of doing something more
than absolutely necessary or the number of different report
format models to more than one ... at least without really
persuasive and explicit reasons that would overcome the
considerable cost.

   john

---

From: "John R Levine" <[email-masked]>
Date: 12 May 2012 06:29:55 -0400

> to communicate both not-spam->spam and spam->not-spam, but sure, a simpler

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?

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

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 12 May 2012 09:25:47 -0400

On Fri, May 11, 2012 at 8:53 PM, SM <[email-masked]> wrote:
> During the discussions about the formation of this working group, it was
> mentioned that it should not be the dumping ground for everything
> Apps-related.  As the final decision rests with the Apps ADs, I'll stay out
> of this.

On "I'll stay out of this," I'll note that you already haven't.
http://dictionary.reference.com/browse/paralipsis

This AD thinks there's a difference between a "dumping ground for
everything Apps-related" and a "home for otherwise homeless
Apps-related work."  The former implies that everything ends up here
without real thought or filtering.

I think AppsAWG is a good way to get attention paid to work that the
Apps community has thought about and decided is worth doing.  Thought
and filtering are critical to that, and that's what's happening in
this thread.

Carry on.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 12 May 2012 09:30:50 -0400

Hi Patrik,

> "Just" agree on a flag being "spam" and let clients and servers innovate

We already have $Junk and $NotJunk keywords registered: 
<http://www.iana.org/assignments/imap-keywords/imap-keywords.xml>. Perhaps 
a more formal definition of those would help.

-- 
Cyrus Daboo

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 May 2012 10:44:46 -0400

--On Saturday, May 12, 2012 09:25 -0400 Barry Leiba
<[email-masked]> wrote:

>...
> I think AppsAWG is a good way to get attention paid to work
> that the Apps community has thought about and decided is worth
> doing.  Thought and filtering are critical to that, and that's
> what's happening in this thread.

Barry,

I agree, with one qualification.  

In managing "normal" WGs, we usually try to keep the number of
individual "life" issues and documents limited in order to
improve workflow management and raise the likelihood that each
issue really gets adequately careful attention.  Sometimes we do
that by charter, sometimes by document and workflow management,
but I suggest that, in most cases, WGs who are successful in
developing consensus documents and being confident that
consensus do so.

Looking at this from a personal perspective, the number of
active documents in AppsAWG, whether in discussion for adoption,
adopted and presumably under development, or in WG or IETF Last
Call, is getting hard for me to stay on top of, especially when
my other IETF commitments (including to a few WGs I try to
follow) and limited time are swamping my ability to keep up,
even with documents for which I have direct responsibility.  I
hope I'm atypical and that others are doing much better, but I
do hope that the question of "Given existing commitments, do we
have the collective bandwidth among the active people in the
applications area to do this well?" is considered along with
whether the work is worthwhile, whether we have the expertise,
etc.

   john

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 May 2012 08:10:05 -0700

On 5/12/2012 6:30 AM, Cyrus Daboo wrote:
> Hi Patrik,
>
> --On May 12, 2012 7:17:01 AM +0200 Patrik Fältström <[email-masked]> wrote:
>
>>> the flag is available.
...
> <http://www.iana.org/assignments/imap-keywords/imap-keywords.xml>.
> Perhaps a more formal definition of those would help.

In IETF work-management terms, I think this pattern of postings 
translates into:

1. The topic is worthy of a specification effort

2. The current draft probably will need substantial change.

+1.  FWIW, I agree with both points.

A user-level "this is spam" button is quite common in the industry. 
Having IMAP support an equivalent capability seems only reasonable.

As always, I prefer a minimum increment to the existing service, as long 
as the increment can do the required job well enough.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Sat, 12 May 2012 08:20:16 -0700 (PDT)

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

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

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 May 2012 08:38:54 -0700

> You cannot represent all of those in a single bit.

Correct, and I think we should /not/ try to represent all those cases.

Rather, I think we need one bit, which is a "current" classification of 
the message as spam or not.  How that bit gets set should be kept a 
separate matter.  Might be set by the system.  Might be set by the user.

My understanding of research on user-level spam control is that one bit 
is sufficient and more than one bit is confusing, even given the fact 
that user's often invoke the spam button to mean "unsubscribe".

d/

---

From: "John R Levine" <[email-masked]>
Date: 12 May 2012 12:13:07 -0400

> Correct, and I think we should /not/ try to represent all those cases.

I suppose this could be two bits, one the spam state to display, the other 
a less visible flag the user can toggle, but that's not what IMAP does 
with its other flags.

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

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 May 2012 10:42:57 -0700

On 5/12/2012 9:13 AM, John R Levine wrote:
> I suppose this could be two bits, one the spam state to display, the
> other a less visible flag the user can toggle, but that's not what IMAP
> does with its other flags.

1.  What is the purpose of the two flags?

2.  What is the "need" for each of them?

3.  What is the basis for believing the need is substantial?

d/

---

From: Ned Freed <[email-masked]>
Date: Sat, 12 May 2012 11:46:02 -0700 (PDT)

> Correct, and I think we should /not/ try to represent all those cases.

Unfortunately, failure to allow for all of these cases will prevent the
interface from being effective in all cases.

> separate matter.  Might be set by the system.  Might be set by the user.

Then unless you report transitions of this state, this fails to support
the functionality current UIs provide.

> that user's often invoke the spam button to mean "unsubscribe".

You're confusing what's presented to the user with what has to be stored behind
the scenes. These are not the same, and as I pointed out previously, all of
these states can be, and usually are, trivially presented as a single button -
essentially a "click if you disagree with the current state" control.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 12 May 2012 11:54:01 -0700 (PDT)

> 1.  What is the purpose of the two flags?

There are various ways to define the two flags, but you need at least two in
order to store both system and user determination information.

> 2.  What is the "need" for each of them?

To be able to both present the correct information to the user as well as being
able to get feedback about it.

> 3.  What is the basis for believing the need is substantial?

The fact that large numbers of present UIs work this way.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 12 May 2012 11:56:15 -0700 (PDT)

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

> The

Hidden server state is almost always a bad design choice, especially when
there's essentially no cost involved in exposing it.

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 accomodate the *functionality*
provided by current UIs. 

				Ned

---

From: SM <[email-masked]>
Date: Sat, 12 May 2012 23:13:34 -0700

>adopted and presumably under development, or in WG or IETF Last

I would like to know "how we decide".  I don't have a strong opinion 
about the matter though.  It's all fine for someone to say that some 
work is worth doing at a meeting.  I know that a number of people 
saying that will be absent when the actual work is being done.

I posted a few comments about one of the WG drafts on May 2.  There 
hasn't been any reply.  I am going to express my discontent during 
the Last Call.  I am not going to "send text" if I get to the 
discontent stage.  Should anyone remind me that it is IETF practice 
to send text, I will say that I am not the one requesting an RFC 
number.  There might be some leading questions as a means to resolve 
the issue(s).  I'll set the good faith level to the IETF median.

In case it is not clear, I am not taking a shot at the WG chairs or 
the ADs; I am not taking a shot at anyone who expressed interest in 
doing some work.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 May 2012 08:07:16 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Saturday, May 12, 2012 11:14 PM
> To: [email-masked]
> Subject: Re: [apps-discuss] How we decide (was: Re: Call for Adoption draft-ordogh-spam-reporting-using-imap)
> 
> >Looking at this from a personal perspective, the number of active
> >documents in AppsAWG, whether in discussion for adoption, adopted and
> >presumably under development, or in WG or IETF Last
> 

I haven't spoken to Alexey about this reply, so this is only me speaking.

My answer to the "how we decide" question in the context of AppsAWG is to ask effectively the same questions one would ask about a new working group: Is the problem statement clear, is there a non-trivial group of people who intend to work on this, do we have a good starting point for discussion in terms of at least one draft, etc.  To continue the analogy, the Call for Adoption is the BoF for the proposed work, except that the scale of the work in our context is much smaller and more narrow than would justify a dedicated working group.

In terms of the current influx of work, I believe we're simply clearing a backlog of stuff.  Some of it has been sitting around waiting for admission to AppsAWG for some time; some of it is already-adopted documents that just needed a good nudge to make their way to the IESG; some of it is merely a coincidence of timing.

Our current docket doesn't contain anything that's especially heavyweight as far as I can see.  I suspect the two currently in Call For Adoption will take more work than the current handful of drafts combined.  I'm thus hoping we can progress some of those smaller ones with appropriate diligence but also without any undue delay.

> hasn't been any reply.  I am going to express my discontent during the
> Last Call.

I think this is a different topic.  I certainly agree that if feedback goes unaddressed, it's up to the document shepherd and the author(s) to make sure that gets fixed, lest it face a DISCUSS later.

> I am not going to "send text" if I get to the discontent
> stage.  Should anyone remind me that it is IETF practice to send text,
> I will say that I am not the one requesting an RFC number.

That's certainly your prerogative, though in my case I would prefer to remain co-operative.  You might not concur with your stance, for example, if the roles one day are reversed.

-MSK

---

From: SM <[email-masked]>
Date: Sun, 13 May 2012 03:40:08 -0700

Hi Murray,
At 01:07 13-05-2012, Murray S. Kucherawy wrote:
>That's certainly your prerogative, though in my case I would prefer 
>to remain co-operative.  You might not concur with your stance, for 
>example, if the roles one day are

It is also up to the author(s) to be co-operative.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 13 May 2012 13:10:22 +0200

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 May 2012 16:28:05 +0000

> From: SM [mailto:[email-masked]]
> Sent: Sunday, May 13, 2012 3:40 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> >That's certainly your prerogative, though in my case I would prefer to
> >remain co-operative.  You might not concur with your stance, for

Certainly.  But I think in this case it was an accidental oversight of your message, not malice or negligence.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Sun, 13 May 2012 13:57:59 -0700 (PDT)

> training is another server-side activity the client might want to know

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.

> flags upon acting on messages, e.g. "$reported", exclusively for MUAs

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.

> 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