Subject: RE: [lemonade] Strawman for Submit based message composition

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Thu, 12 Jun 2003 06:57:03 -0500

Alan,

This looks like one of several possible implementations of IMAP-Submit.  The protocol between the mobile client and IMAP server is not materially different from Pete's outline.  It does not matter to the mobile client whether the IMAP server does the processing itself or it delegates it to an external submission client.  However, as you note, separating the functions does require additional enhancements to IMAP.  It appears to me this implementation as all the costs of both IMAP-submit and SMTP-submit since the submission client needs all the access control machinery (and more) of an external SMTP-submit server.

One question:  Do we believe the IMAP client needs some form of confirmation at the end of the submission transaction that the submission was sucessful?   It seems very valuable to return a sucess or detailed failure reason at submission time rather than to send a complete DSN back to the senders mailbox for subsequent retreival.... lots more round-trips and a degraded user experience.

Greg V.

-----Original Message-----
From: Alan K. Stebbens [mailto:[email-masked]]
Sent: Thursday, June 12, 2003 12:39 AM
To: Doug Royer
Cc: [email-masked]
Subject: Re: [lemonade] Strawman for Submit based message composition

Hello Doug,

DR> I still think that the best approach is to have the IMAP server do the
DR> submit :-)

Here is an alternative submission protocol for mobile clients, supporting
forwarding without downloading, using standard IMAP4 features and standard
SMTP features.

I'll use a picture (because I like them :^)

            Please view in a fixed-width font such as Courier.

+--------+           +--------+           +----------+    5         +-----+
| Mobile |           |  IMAP  |---RECENT->|  Outbox  |--MAIL From-->| MTA |
| Client |--APPEND-->| Server |     2     |  Server  |  RCPT To     |     |
|        |    1      |        |<--SEARCH--| ( IMAP ) |  DATA        |     |
+--------+           |        |   RECENT  | (Client) |  ...         |     |
                     |        |     3     |          |  .           |     |
                     |        |---FETCH-->|          |              |     |
                     |        |     4     |          |              |     |
                     |"Outbox"|           |          |              |     |
                     +--------+           +----------+              +-----+

The "envelope" information that is needed for the SMTP transactions could be
carried in the message that is APPENDed to the IMAP4 "Outbox".  Example:

        To: [email-masked]
        From: [email-masked]
        Subject: a mail
        X-Env-From: [email-masked]
        X-Env-To: [email-masked]

        blah blah

The "X-Env-From:" and "X-Env-To:" headers would carry the MAIL and RCPT
information, and would be removed from the message transmitted over the SMTP
connection.

When a message is appended to a given user's Outbox, a later connection by
another, server-based IMAP client, called the "Outbox Server", would be used
to search for RECENT messages in the "Outbox".  For concurrent sessions,
asynchronous, untagged RECENT responses would be sent as a notification to
the Outbox Server, which would then do a SEARCH RECENT to get the recently
arrived messages in the Outbox.

After FETCHing the recent messages in the Outbox, the Outbox Server would
dereference any MIME parts consisting of IMAP URLs, the UIDs of which would
be relative to the same mailbox containing the Outbox.

After FETCHing any IMAP URLs to referenced MIME parts (or entire messages),
and replacing the MIME part of the outgoing message with the FETCHed
contents, the new outgoing message would be submitted to a configured MTA
using the envelope information defined by the "X-Env" headers.

This mechanism does not require any protocol changes to IMAP or to SMTP.

By virtue being part of the operator's infrastructure, the Outbox Server can
obtain access to each user's IMAP Outbox folder and limit itself to further
access solely within that same mailbox, including the IMAP URLs to messages
in the INBOX.

The sole liability to this mechanism is the current lack of a scalable
notification mechanism of newly APPENDed messages across all Outbox folders
for a given IMAP server.  It is not practical for an Outbox Server to
maintain sessions for *all* Outbox folders in order to receive asynchronous
untagged RECENT responses, and it is not practical for an Outbox Server to
repeatedly poll all the Outbox folders on a large scale IMAP server.

Instead, the occurrence of newly APPENDed messages into an Outbox folder
should trigger a notification mechanism to the Outbox Server.  How can this
be accomplished and by what mechanism should be an interesting discussion.

-- 
Best regards,
 Alan K. Stebbens <[email-masked]>
 Principal Product Technologist, Messaging
 Openwave Systems, Inc.
 Cell: +1.805.886.8886  Voice/Fax: +1.866.579.0801
 Desk: +1.805.884.3162
 YIM/MSN: alan_stebbens  ICQ: 51361674  AIM: akstebbens   

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 12 Jun 2003 11:50:46 -0600

[Folks, please trim down the included text in your replies ...]

On Thursday, June 12, 2003, at 05:57  AM, Vaudreuil, Greg M (Greg) 
wrote:

> One question:  Do we believe the IMAP client needs some form of 
> confirmation at the end of the submission transaction that the 
> submission was sucessful?   It seems very valuable to return a sucess 
> or detailed failure reason at submission time rather than to send a 
> complete DSN back to the senders mailbox for subsequent retreival.... 
> lots more round-trips and a degraded user experience.

By the time we add this to IMAP-Submit we'll have reinvented SMTP (or 
at least, Submission). Having had a few days to digest all the list 
traffic, I'm starting to lean strongly towards a separate "message 
composition" service. Neither IMAP nor SMTP can do what we want, at 
least not without some ugly bastardization. The idea of remote 
composition has applicability in a wide range of applications, and it 
seems silly to restrict ourselves to a hacked up solution that is 
applicable to only a fraction of the potential solution space. If we 
solve this only for the IMAP server space, and the idea catches on (and 
I am convinced it will), then either a) the hack continues to get 
hacked to encompass other application spaces, or b) a new remote 
composition protocol is developed that isn't limited to just the IMAP 
space. Both of these scenarios are bad.

--lyndon

---

From: Doug Royer <[email-masked]>
Date: Fri, 13 Jun 2003 08:06:32 -0600

Vaudreuil, Greg M (Greg) wrote:
 > submission was sucessful? It seems very valuable to return a
 > sucess or detailed failure reason at submission time rather than
 > to send a complete DSN back to the senders mailbox for subsequent
 > retreival.... lots more round-trips and a degraded user experience.

It might be unavoidable.  Right now I can submit e-mail to my
smtp-host which accepts the message with minimal checking
when heavily loaded, queues it, and then later sends any
bounce message.

Plus a heavily loaded smtp-host does not respond quickly which
would hold up the reply back to the IMAP client. I think it would
be best to allow both 'queued for delivery' and 'delivered' status
codes to be returned to minimize the delay.

The 'MAIL FROM' would not need any feedback as the user is
authenticated via IMAP. The 'RCPT' could return 'valid' or
'accepted for now'. And the at the end of DATA it could
return 'delivered' or 'queued'.

As the blob of data is appended to the OUTBOX a single
return could contain the RCPT and DATA results. As
the over the air CELL transfer speed is much slower than the
interprocess communication on the server, it should not
be a problem to return the results quickly relative to
the send time after the append.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Mark Crispin <[email-masked]>
Date: Fri, 13 Jun 2003 10:31:03 -0700 (PDT)

On Fri, 13 Jun 2003, Doug Royer wrote:
> authenticated via IMAP.

Since when is the MAIL FROM tied to IMAP authentication?  Are you also
going to claim that the From: header is also tied to IMAP authentication?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Doug Royer <[email-masked]>
Date: Fri, 13 Jun 2003 13:04:40 -0600

Mark Crispin wrote:
> Since when is the MAIL FROM tied to IMAP authentication? 

In the context of the email I replied to.

>Are you also

Are you claming I said that?

--

---

From: Mark Crispin <[email-masked]>
Date: Fri, 13 Jun 2003 22:24:56 -0700 (PDT)

> In the context of the email I replied to.

Why is the SMTP return-path tied to IMAP authentication?

> Are you claming I said that?

Why is the SMTP return-path is tied to IMAP authentication but the From:
header is not?

-- Mark --

---

From: Doug Royer <[email-masked]>
Date: Sat, 14 Jun 2003 11:42:19 -0600

> Why is the SMTP return-path is tied to IMAP authentication but the From:

Why are you mis-quoting me?

--

---

From: Mark Crispin <[email-masked]>
Date: Sat, 14 Jun 2003 12:41:12 -0700 (PDT)

> Why are you mis-quoting me?

Are you claiming that the SMTP return-path (which is what MAIL FROM sets)
is not tied to IMAP authentication?

Are you claiming that the From: header is tied to IMAP authentication?

If "no" to both of the above, then where is the misquote?

-- Mark --