Subject: [lemonade] I-D ACTION:draft-royer-lemonade-submit-00.txt

From: [email-masked]
Date: Tue, 17 Jun 2003 07:56:29 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IMAP-PROXY service for mobile clients to do submitting
                          and forwarding
	Author(s)	: D. Royer
	Filename	: draft-royer-lemonade-submit-00.txt
	Pages		: 7
	Date		: 2003-6-16
	
This memo describes a method that allows mobile clients to use the
IMAP protocol and submit messages to a IMAP-PROXY service that
understands [E]SMTP and IMAP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-royer-lemonade-submit-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-royer-lemonade-submit-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-royer-lemonade-submit-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 17 Jun 2003 14:11:40 -0700 (Pacific Daylight Time)

Why is this called an "IMAP proxy" instead of an "IMAP and SMTP proxy"?

This document very suspiciously refers to a "standard IMAP client" as
being a client of the proxy.  I thought that this was about about
providing an efficient means of forward and remail for mobile clients, not
a backdoor attempt (without going through IMAPEXT) to force submit into
IMAP for all clients.

Nothing, other than some handwaving in section 2, gives any indication of
how this is an "IMAP proxy" rather an added CAN-SUBMIT extension to the
IMAP protocol (which belongs in IMAPEXT not LEMONADE).

The SUBMIT command apparently relies upon parsing of the RFC 2822 header
to extract the SMTP envelope information.  If that was a good idea, then
SMTP could have been much simpler.  I wonder why this great insight wasn't
presented during the RFC 2821 effort.

The document fails to discuss the following requirements of such a
mechanism:
 1) Any bcc headers must be removed prior to transmission.
 2) Handling of RFC 2822 group syntax (are the contents suppressed?) needs
    to be fully specified
 3) How is the SMTP Return-Path derived?
 4) How is the From: header line validated?

I hope that nobody claims that (3) and (4) are done from the IMAP login.

I also hope that you're not going to tell me that I can't use a valid
From: address just because the IMAP server doesn't have a clue about that
address.

There is further handwaving about "might replac[e] the Message-ID,
remov[e] any Received-By [sic] lines, Date, and so on."  Exactly what
processing is this mechanism to do?

I also note with considerable irony that the raison d'e^tre for the
effort, forwarding and resending of existing IMAP mailbox content, is
completely overlooked by this document.  Where is the tagging mechanism by
which data from the IMAP server is inserted in this message.

The tagged NO response adds a leading comma syntax not used by any other
IMAP command.  Why doesn't this use the standard status response code
mechanism?

As far as I can tell, this document is about one thing and one thing only:
adding a SUBMIT command to IMAP.  It uses the word "proxy" but in no
respects (other than an ASCII-art picture) exhibits any aspects of a
proxy.  Nor is it about any form of efficient forward/remail to mobile
clients.

-- 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: Tue, 17 Jun 2003 15:52:25 -0600

> Why is this called an "IMAP proxy" instead of an "IMAP and SMTP proxy"?

Its just a strings of characters that made a readable name.

> a backdoor attempt (without going through IMAPEXT) to force submit into

Why is is 'suspicious'? There have been no hidden e-mail between
conspirators to do horrible things. Even with the proxy, no one would
be FORCING anything. It is an optional over the wire extension use it, or not.

> IMAP protocol (which belongs in IMAPEXT not LEMONADE).

Yet it is part of this lemonade debate.

> presented during the RFC 2821 effort.

I do not know. Did you ask Pete?
I suspect that it had a lot to do with the fact they wanted to
be compatible with 82[12].

>  1) Any bcc headers must be removed prior to transmission.

Good point. I am sure we can add something.

>  2) Handling of RFC 2822 group syntax (are the contents suppressed?) needs

I forgot about those. Good point.

>  3) How is the SMTP Return-Path derived?

The proxy can be configured to conform to the ISPs standards.

>  4) How is the From: header line validated?

Same as (3).

> I hope that nobody claims that (3) and (4) are done from the IMAP login.

That would be up to the ISP and vendor. It does not need to be
hard coded in the spec. It just needs to be mentioned.

> From: address just because the IMAP server doesn't have a clue about that

Correct, I was not proposing that the validation information come
from the IMAP server. I was suggesting that an implementation
may add validation checking at that point so they do not have
to alter their SMTP or IMAP server.

> processing is this mechanism to do?

What is need to enforce site policy and track spam sources. No specific
thing must be done. Just a catch all to allow those to be done.

> which data from the IMAP server is inserted in this message.

It is not overlooked, it is skipped and it says that it is skipped.
It was not a proposal for the include mechanism, it is a proposal
for a proxy mechanism that uses the include mechanism.

> IMAP command.  Why doesn't this use the standard status response code

Off of the top of my head I do not recall any formatted NO responses.
If there is one, I would be happy to use that format.

> proxy.  Nor is it about any form of efficient forward/remail to mobile

It is about how to allow IMAP clients the ability to submit. This
plus the yet undefined include mechanism would solve the problem
of forward and include without download for IMAP clients with
minimum over the wire protocol changes.

If you are correct and it is horrible or impossible to add this
to an IMAP server, then this would work and not effect existing clients.

-- 

  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: Pete Resnick <[email-masked]>
Date: Tue, 17 Jun 2003 17:40:04 -0500

With my "chair-of-IMAPEXT" hat planted firmly on my head:

On 6/17/03 at 2:11 PM -0700, Mark Crispin wrote:

>...a backdoor attempt (without going through IMAPEXT) to force 
>submit into IMAP for all clients.
>
>...extension to the IMAP protocol (which belongs in IMAPEXT not LEMONADE).

Though the length of its life would seem to indicate otherwise, 
IMAPEXT is not some sort of a permanent standing working group that 
works on any IMAP extension that comes along. IMAPEXT has a charter 
which indicates certain tasks to be completed, and after those task 
are completed, it is finished. (Perhaps it would have been better to 
name the group "IMAPSORTTHREADANNOTATE".) Nothing *belongs* in 
IMAPEXT that isn't already on the charter of IMAPEXT. There are folks 
who work on IMAP issues, and they can just as well participate in 
LEMONADE as any other group if there is a suggestion to solve a 
LEMONADE problem with an IMAP extension. That a proposed solution is 
an IMAP extension is not a basis for saying it does not belong in 
LEMONADE.

End of point of order.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Mark Crispin <[email-masked]>
Date: Tue, 17 Jun 2003 15:53:10 -0700 (Pacific Daylight Time)

Well, Pete, I agree with you that "nothing belongs in IMAPEXT that isn't
already on the charter of IMAPEXT", and confess a backdoor motivation;
shove "submit as a general extension for all clients, not just mobile
clients" from LEMONADE (where extensions for non-mobile clients are
outside of charter) to IMAPEXT, which promptly tosses it as outside of its
charter.

> That a proposed solution is

No, but...:

The charter states that "Lemonade is tasked to provide a set of
enhancements and profiles of Internet email submission, transport, and
retrieval protocols to facilitate operation on platforms with constrained
resources, or communications links with high latency or limited
bandwidth."

The submit document explicitly states that it is to be used on others
platforms.  What's more, the submit document does not address work item
(2) at all.

Since the submit document covers platforms other than what is in the
charter, and because it does not address any of the work items of the
charter, I claim that it does not belong in LEMONADE.

A possible fix to this document would be to remove all references to
non-mobile clients and to add the functionality for work item (2).

-- Mark --

---

From: Doug Royer <[email-masked]>
Date: Tue, 17 Jun 2003 18:51:47 -0600

Mark Crispin wrote:

> platforms.

Where is that 'explicitly' stated? Or do you mean that it should be
disqualified or declared sneaky because it would work with existing
IMAP clients?

 >  What's more, the submit document does not address work item
 > (2) at all.

How about we specify a new message/external-body 'access-type'
of 'include' that must also specify a URL. Example below
using a "Relative IMAP URL" defined in 2192 (sorry
I do not recall the exact syntax of the URL).

Example:

      Content-type: message/external-body;
                    access-type=include;
		   url=imap:mailboxname;uid=123

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Jun 2003 14:13:02 -0600

> outside of charter) to IMAPEXT, which promptly tosses it as outside of its

Having re-read the charter, I see nothing in it that says that if
it is compatible with existing clients that it must be tossed.
And I see it as a plus that it is compatable.

--