MBOX-Line: From JohnD at cciu.org  Thu Jan 31 09:24:12 2008
To: imap-protocol@u.washington.edu
From: John DeMillion <JohnD@cciu.org>
Date: Fri Jun  8 12:34:41 2018
Subject: [Imap-protocol] Should IMAP APPEND create a sent or unsent
	message?
In-Reply-To: <alpine.OSX.1.00.0801302244470.10877@pangtzu.panda.com>
References: <fc.00802cf1026ac56600802cf1026ac566.26adfec@cciu.org>
	<alpine.OSX.1.00.0801302244470.10877@pangtzu.panda.com>
Message-ID: <fc.00802cf1026ae3b200802cf1026ac566.26b3de0@cciu.org>

Mark Crispin <mrc@Washington.EDU> on January 31, 2008 at 2:11 AM -0500
wrote:
>I don't know if this explanation makes sense to you or not.  Hopefully 
>some other people can chime in with perhaps different explanations
>that  
>may ultimately make things clear.

Your reply was sensible (not to mention entertaining); thanks for
taking the time to present that comprehensive explanation.

I realize that IMAP is not used to send messages, and in this case the
message has actually already been sent via SMTP by the mobile software
vendor.  Bear in mind that I'm talking about "sent" and "unsent" only
in the sense of how it *appears* to the user when they see the results
of the APPEND in their mailbox, not anything to do with IMAP sending or
not sending anything.  

The question that I'm dealing with is how the mobile vendor's
already-sent-by-SMTP message is represented in the user's groupware
system.  The mobile vendor wants to create the illusion of an
already-sent message via an IMAP APPEND, but the way that my groupware
vendor is implementing APPEND breaks the illusion.

It seems that the \Draft flag, or at least my understanding of it,
might have some relevance here.  The mobile software vendor is *not*
using the \Draft flag with the APPEND command, but it seems that the
groupware vendor is treating the APPENDed message as such:  the
resulting message in the groupware system is user-changeable and
appears essentially in "saved draft" form.  The user could modify any
part of it and then hit "Send" and it would go out via local SMTP
again.  In the words of the RFC, the appearance of the APPENDed message
to my groupware user is that the "message has not completed
composition".

(As an aside, the standard practice for this sort of function in the
mobile client arena is to just automatically BCC the user's groupware
account on all mobile sends, providing an unchangeable reference copy
of the mobile-sent message.  Unfortunately, my mobile vendor is not
doing that, preferring instead to use the IMAP APPEND to try to
accomplish the same thing.  They claim that other groupware/email
systems handle an APPEND differently, presenting the user with the
equivalent of a BCC'd message:  the appearance of "already sent"
message, not a "draft" that could be re-sent.)

Abhijit Menon-Sen <ams@oryx.com> on January 31, 2008 at 2:49 AM -0500
wrote:
>Clients may APPEND to different folders ("sent mail" vs. "drafts") or
>set flags on a message (e.g. \Draft) to indicate one or the other, but
>you're right, IMAP says nothing about this, and different clients do
>things differently.

There seems to be an inherent conflict there:  the very existence of
the \Draft flag defined by the IMAP protocol seems to differentiate
"sent mail" (no \Draft) from "drafts" (using \Draft)....the IMAP
protocol does indeed seem to say something on the topic.  Is it logical
that the lack of \Draft mean "not Draft", therefore meaning "completed
composition" and therefore not changeable?

With this in mind, would a reasonable/correct interpretation be:
     *   an "APPEND \Draft" creates a message that has the *appearance*
to the user of being an unsent, saved draft message, allowing user
changes (as my groupware vendor is doing with all APPENDs, regardless
of the flags)
     *   an unflagged "APPEND" creates a message with the *appearance*
to the user as having already been sent, just as if they sent it using
their groupware client, totally unchangeable (as my mobile vendor
intends)

Getting past my n00b interpretations, I'm curious what the production
behavior of APPEND is (with and without the \Draft flag) in other
groupware/mailsystems that the obviously experienced list members are
knowledgeable about.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080131/3bf7ef23/attachment.html>
