--On 27 January 2010 17:22:00 +0000 John Levine <johnl(_at_)taugh(_dot_)com>
wrote:
All they need to do is somehow send the message, or a pointer to a stored
copy of the message, back to the user's own mail system. The tricky bit
is that MUAs have separate configs for inbound and outbound mail, so you
can't just send the message via the outbound channel or you may be sending
it to someone who's never seen it before. For IMAP you could either
have a special folder (what AOL does with its IMAP interface) or a new
flag, for POP you'd have to invent a crock of some sort.
POP isn't really susceptible to simple solutions, as you say, so let's
focus on IMAP.
There seem to be four options, to me:
(a) define a new flag per message,
(b) define an ANNOTATE annotation per message,
<http://tools.ietf.org/html/rfc5257#section-3.1>
(c) define an METADATA annotation on a mailbox,
<http://tools.ietf.org/html/rfc5464>
(d) do something adhoc with mailboxes as is done for "spam" , "sent
messages", "trash" and the like.
Are there any other possibilities?
(d) is the closest example that we have. It's used by the service provider
to communication information about spam status to the user. Of course, that
suggests a fifth option - rewriting the subject header (but I almost wish I
hadn't thought of that!). I can't think of examples where flags or
annotations are set IN ORDER to facilitate communication between user and
provider.
My preferred option would be (b) because (i) it's more flexible than a flag
(eg, it *could* be used to distinguish between 'block' and 'report'
requests if both the user and the admin desire) (ii) it preserves the
information about location of the message, which makes "undo" easier than
moving the message into a different mailbox, (iii) ANNOTATE has
experimental RFC status, whereas ANNOTATEMORE is
The drawback of (b) is that it creates a client side user interface
problem. Presumably the user doesn't want the inbox full of messages that
have been reported. There needs to be a way for the message to be preserved
for inspection by the admin, but hidden from (yet findable by) the user.
If defining new annotations, it might be useful to define them for other
special maiboxes, too.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg