Subject: [lemonade] The Big Picture

From: Marc Perkel <[email-masked]>
Date: Fri, 19 Aug 2005 11:44:52 -0700

OK - read and think before you reply.

IMAP can move messages to and from the server. So if you have a protocol 
that can deliver messages to a server then why not let IMAP hand off 
outgoing email to SMTP?

Why use a submission protocol on a separate connection with a separate 
protocol and separate authentication and separate client configuration 
when the client already has and authenticated IMAP connection to the 
server that is already capable of transporting outgoing email?

Why use 2 different protocols when you can use one?

There are probably a lot of ways to get the outgoing email sent. You can 
use the fine proposals here. You can also tunnel to SMTP. You could make 
a virtual server side outbox and saving to the outbox means sending the 
email. Or you can do all of the above.

The advantages of eliminating the need for SMTP or SUBMISSION is that if 
you can send email with IMAP then for me anyhow SMTP-AUTH goes away. 
SUBMISSION goes away. It makes it so my server only talks SMTP to other 
servers and not to end users.

If users are limited to other protocols than SMTP then it will probably 
be a huge boost to eliminating SPAM because my servers won't have to 
talk to end users at all.

And - when an end user configures a client they only need to configure 
IMAP and not SMTP. The don't have to deal with port blocking and all the 
nasties of beling mobile with a laptop and trying to find some way to 
send email.

That to me is the big picture.

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

---

From: Mark Crispin <[email-masked]>
Date: Fri, 19 Aug 2005 12:33:27 -0700 (PDT)

> OK - read and think before you reply.

I fear that this is advice that you haven't been following.

> IMAP can move messages to and from the server. So if you have a protocol that 
> can deliver messages to a server then why not let IMAP hand off outgoing 
> email to SMTP?

The fact that two protocols have related functions does not mean that 
those two protocols should be merged into one protocol.  Otherwise, 
everything would have been TELNET protocol in the 1970s, and HTTP protocol 
today.

Exchange is an existing example of a monolithic protocol that attempts to 
perform multiple tasks (email, calendering, task management, etc.).  It's 
"the Windows way."

For better or worse, the design focus of the IETF protocol suite is upon a 
set of small protocols, each of which are focused upon a single task and 
doing that one task well.  It's "the UNIX way."

> protocol and separate authentication and separate client configuration when 
> the client already has and authenticated IMAP connection to the server that 
> is already capable of transporting outgoing email?

That presumes that the server is "already capable of transporting outgoing 
email."  That presumption is demonstrably invalid.

My organization, serving a 6-digit user community, does not want its IMAP 
server machines to run an MSA, much less an MTA.

Message submission and message transport are each handled by dedicated 
servers.  These servers perform multiple tasks relating to outgoing mail 
(some, but not all, related to the four-letter "S" word), none of which 
have anything to do with IMAP service and which would seriously impact 
IMAP service if run on the same system.

Finally, that presumes that authentication and authorization credentials 
for message access are the same for message posting.  That too is 
demonstrably invalid.

My organization has IMAP servers which provide access to a community which 
does NOT have message posting rights.  So, now IMAP servers have to be in 
the business of identifying which users have posting rights (and can use 
the SMTP pass-through) and which users do not.

> Why use 2 different protocols when you can use one?

That is precisely why your proposal is rejected.  You want to add a new 
means to submit mail when one already exists.

> The advantages of eliminating the need for SMTP or SUBMISSION is that if you 
> can send email with IMAP then for me anyhow SMTP-AUTH goes away.

You just said the key phrase: "for me anyhow".

You are asserting that your personal convenience is of greater importance 
than any of the other concerns raised by others.

Your personal convenience is worth more than the extra RTT suffered by the 
mobile phone vendors who are desperate to eliminate RTTs, and whose 
response to my success in reducing IMAP's startup RTTs from 5 to 3 is "not 
good enough, get rid of 2 more."

> SUBMISSION goes away.

How is this a benefit?  Since SUBMISSION goes away, all software must 
implement IMAP in order to submit mail.  What about POP3 clients, or any 
other application that needs to submit mail but does not need IMAP?

> talk to end users at all.

Please read RFC 2476.

> And - when an end user configures a client they only need to configure IMAP 
> and not SMTP. The don't have to deal with port blocking and all the nasties 
> of beling mobile with a laptop and trying to find some way to send email.

As has been pointed out many times by myself and others, the configuration 
problem is addressed quite well by other mechanisms.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Marc Perkel <[email-masked]>
Date: Fri, 19 Aug 2005 13:36:34 -0700

Mark Crispin wrote:

> That is precisely why your proposal is rejected.
>
So - it is your sole decision as to what is accepted and rejected?

 > You want to add a new means to submit mail when one already exists.

1.    Introduction 
    
   LDELIVER is a LEMONADE extension to the IMAP protocol (P-IMAP) 
   defines extensions to the IMAPv4 Rev1 protocol [RFC3501] to enable 
   sending email as an IMAP command. This provides simple ways to 
   provide reply and forward without download with a gateway to the 
   email and submit servers.

---

From: Mark Crispin <[email-masked]>
Date: Fri, 19 Aug 2005 14:21:06 -0700 (Pacific Daylight Time)

> So - it is your sole decision as to what is accepted and rejected?

Have you noticed anyone else speak up in favor of your proposal?

Haven't you noticed other WG members speak out in strong opposition to 
your proposal?

> 1.    Introduction      LDELIVER is a LEMONADE extension to the IMAP protocol 
> (P-IMAP)   defines extensions to the IMAPv4 Rev1 protocol [RFC3501] to enable 
> sending email as an IMAP command. This provides simple ways to   provide 
> reply and forward without download with a gateway to the   email and submit 
> servers.

Do you know what P-IMAP is, and in particular its status is in the 
Lemonade Working Group?

-- Mark --

---

From: Dave Cridland <[email-masked]>
Date: Sat, 20 Aug 2005 00:21:32 +0100

On Fri Aug 19 05:44:52 2005, Marc Perkel wrote:
> And - when an end user configures a client they only need to 
> configure IMAP and not SMTP.

With my client all they need to configure is ACAP. It's not like I'm 
the only one present with a client like that either - this is 8 year 
old technology. Eudora can pick up its configuration via ACAP, too. 
Cyrusoft is probably the winner on this front with Mulberry, which 
can additionally use ACAP's precursor, IMSP. There are other 
technologies in this area, too.

Both Mulberry and my own client will pick up configuration data for 
several protocols on several different servers, quite happily, 
freeing the user from entering anything but a hostname and a 
username/password for multiple IMAP accounts, submission servers, 
SIEVE servers, etc - if their administrator has preconfigured 
everything for them, or if they're simply roaming between laptop and 
desktop.

Mine's GPL, Cyrusoft do a free trial of Mulberry, both are 
cross-platform, and I have a GPL ACAP server - or else 
acap://;AUTH=[email-masked]/ should create you an account on one. 
(Via a SASL transition to PLAIN, in case you wonder). You'll then be 
able to roam with your configuration with either quite happily. I 
have a PHP script that'll set things up for Eudora, too, if you 
prefer, so you can preconfigure that for people, too.

With all three, it's possible to go from a fresh software install to 
reading and replying to your mail within a few seconds. (I think it's 
6 round trips with my client and my ACAP server to load the complete 
configuration over the network.)

In my personal case, that includes 15 IMAP accounts, 4 submission 
servers, a few addressbooks, and some bookmarks, but I admit I'm not 
a typical case. Most people do have two email addresses, however.

So I'm sorry, but this kind of configuration technology has existed 
for about a decade in a form far more impressive in scope and 
versatility than your proposal, and with zero impact to any existing 
server. If your email client isn't doing this, you should be 
complaining to the developers, not us.

> That to me is the big picture.

I hate to say this, but my picture's bigger than yours.

Dave.