Subject: Internet Draft for flexible proxying of the mail protocols

From: "Kumar Gaurav Khanna" <[email-masked]>
Date: Wed, 27 Sep 2000 20:56:44 +0530

Hello Everyone :)

I have proposed a an internet-draft take care of the problems faced while proxying the mail (SMTP, POP3 and IMAP) protocols. I submitted it to the IETF today. Lets see what happens... Meanwhile, kindly go through the attached document which details the draft, discussing the need, problems faced, and the solution suggested.

Yours Sincerely,
Kumar Gaurav Khanna

WinTools on the web - http://www.wintools.f2s.com/
Email: [email-masked]
          [email-masked]
          [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Thu, 28 Sep 2000 08:27:04 -0700 (PDT)

Hi.

[I have CC'd [email-masked], as it may be a slightly more appropriate
list.]

This puts the onus on the client to know its server.  There are other
protocols which solve this problem at various levels such as ACAP, LDAP,
and DNS SRV records.

For SMTP, the problem is solved with MX records.

For POP, the protocol is arguably dying in favor of IMAP4.

For IMAP4, have you considered RFC2193, which appears to already provide a
mechanism for the behavior you desire?

-Dan Wing

On Wed, 27 Sep 2000 20:56 +0530, Kumar Gaurav Khanna wrote:

> Hello Everyone :)
> 
> I have proposed a an internet-draft take care of the problems faced
> while proxying the mail (SMTP, POP3 and IMAP) protocols. I submitted
> it to the IETF today. Lets see what happens... Meanwhile, kindly go
> through the attached document which details the draft, discussing the
> need, problems faced, and the solution suggested.
> 
> Yours Sincerely,
> Kumar Gaurav Khanna
>

---

From: "Lee Thompson" <[email-masked]>
Date: Thu, 28 Sep 2000 14:04:57 -0700

> For POP, the protocol is arguably dying in favor of IMAP4.

Here's your argument :)

I wouldn't say POP3 is dying.   At least not from where I sit.    Most ISPs
appear to not want to be message stores for people either.  (Large
corporations and Universities, I'm sure, love IMAP.)

My Two Cents anyway

-- 
Lee Thompson                       [email-masked]
Seattle Lab Inc.           http://www.seattlelab.com
Software Engineer                      ICQ: 19545760

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 28 Sep 2000 15:20:31 -0600 (MDT)

On Thu, 28 Sep 2000, Lee Thompson wrote:

> appear to not want to be message stores for people either.

A common misconception. Nothing requires an IMAP server provide anything
other than INBOX (or any folders at all for that matter), and both IMAP
and POP clients can decide to leave read messages on the server or not.

--lyndon

---

From: Dan Wing <[email-masked]>
Date: Thu, 28 Sep 2000 14:25:24 -0700 (PDT)

> corporations and Universities, I'm sure, love IMAP.)

Considering that:

 o IMAP has a proposed standard to do this already (RFC2193)
 o SMTP should probably utilize AUTH to help redirect someone to a
   correct server

it seems the proposal is only really applicable to POP3, then, yes?

If so, how about rewriting it so it only extends POP3.

It would seem most useful, however, to use ACAP and connect to a default
server, say, acap.default.com, and ask it for the SMTP, POP3, IMAP4, LDAP,
IPP, etc. servers that are appropriate for the user.  Confining the
solution to only email solves only about 3/4 of the configuration that
typically has to be done of applications to find servers.

-d

---

From: Tony Hansen <[email-masked]>
Date: Thu, 28 Sep 2000 17:30:03 -0400

Something lots of people miss is that IMAP doesn't >>require<< the
support for server-side mailboxes (other than INBOX). It's purely a
server-side decision whether or not to allow messages to be stored
there.

	Tony Hansen
	[email-masked]

---

From: Russ Allbery <[email-masked]>
Date: 28 Sep 2000 15:29:17 -0700

> corporations and Universities, I'm sure, love IMAP.)

We much prefer POP from the server side.  The protocol is far simpler
(after having had to implement a very small portion of the IMAP protocol
once, I'm rather afraid of it; I think it's one of the most complicated
and difficult protocols that I've seen), the clients are far more reliable
(we rarely see oddities with POP clients, but IMAP clients routinely do
all sorts of strange things), and a POP server is much lighter weight on
the server side and can handle significantly more users.

Of course, the users understandably want the features of IMAP so we're
getting pushed in that direction, but there will definitely be a price
corresponding to much higher server resources and administrative time
needed over POP.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Philip Hazel <[email-masked]>
Date: Fri, 29 Sep 2000 09:21:33 +0100 (BST)

On 28 Sep 2000, Russ Allbery wrote:

> We much prefer POP from the server side.  

We don't, but then we have permanently connected clients that keep 
probing for new mail at regular intervals. POP requires a password 
authentication for each probe, and a download of the entire mailbox to 
check for new messages. When the users set their probe interval 
ridiculously short (e.g. 1 minute), and leave several megabytes in their 
mailboxes, this hits the machine badly. We make a continuous effort to
educate the users to probe no more than every 5 minutes, and not to set
"leave mail on server", but people being what they are, this is a battle
that can never be entirely won.

IMAP, in contrast, because it keeps a session going throughout, and 
doesn't need to download the entire mailbox to find the list of 
messages, is much lighter on the server.

> corresponding to much higher server resources and administrative time

So I would argue that that isn't always the case (at least for server 
resources). I realise, of course, that in a different scenario, the 
trade-offs are different.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.