MBOX-Line: From JohnD at cciu.org  Wed Jan 30 22:13:51 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?
Message-ID: <fc.00802cf1026ac56600802cf1026ac566.26adfec@cciu.org>


I'm stuck between two interpretations of the function of APPEND by
different vendors, and my reading of RFC 3501 doesn't make it extremely
clear which vendor is correct, so I thought I'd bring it to this list
for an opinion/clarification.

*  The first vendor (the developer of my groupware system) maintains
that the APPEND command should create an *unsent* message in the user's
mailbox.  This message has all of the information present, and appears
to the user as an unsent message, allowing them to use a "Send" action
in the client interface.

*  The second vendor (developer of a mobile device email/sync suite)
maintains that the APPEND command should create a *sent* message, just
as if the message had been sent using the first vendor's normal
groupware client.  This second vendor uses APPEND to create a message
in a "Mail Sent" folder, representing in the main groupware system all
mail that has been sent from the mobile device.  They expect that
APPENDed messages will be as immutable as any other sent messages would
be:  they are a record of already-sent mail, not an unsent message that
could (accidentally or purposefully) be sent a second time.

In my research, I've found conflicting interpretations of APPEND, with
some saying that an APPEND creates an unsent message that another
process is then free to automatically send, while others reference
APPEND as a way to migrate sent email from one system to another,
obviously implying that the final message will appear to have already
been sent.

Is this something that the IMAP protocol can be expected to define, or
has it been purposefully left open to interpretation, and this kind of
disagreement between vendors is thus expected?

I very much appreciate any input and clarification that the list
members might be able to offer.

Thanks,
John DeMillion
Director of Information Technology
Chester County Intermediate Unit

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