Subject: [lemonade] Outside the box suggestion about Lemonade

From: Marc Perkel <[email-masked]>
Date: Thu, 18 Aug 2005 07:41:10 -0700

Hello,

I'm Marc Perkel - and I'm new to this list. I run a span filtering 
service called junkemailfiltercom and do some web hosting.

I've read sme of the discussion about LDELIVER and I just wanted to 
throw out a wild idea and see where it goes.

The Problem: Sending email without having to separately config outgoing 
SMTP so that an IMAP connection can be used especially by moble users to 
send email.

So - suppose that instead of adding something complex - why not just 
establish a tunnel to SMTP over IMAP?

Here's what I propose. The client when sending email would establish a 
second IMAP connection to the server. One of the CAPABILITIES will be 
SMTP-TUNNEL. After sending the command the IMAP server opens a 
connection to the SMTP server and acts as a straight pipe through until 
the connection is closed.

The advantage of this is that you can take your existing SMTP code and 
instead of connecting it on port 25 you connect it on port 143. Then 
everything you could do with SMTP is available. You would just need to 
add a smal layer to the SMTP layer to authenticate to the IMAP server 
and tell it to open a tunnel to the SMTP server. On the server side you 
just connect to localhost:25 or whatever you configure it to and pass data.

Basically what I'm suggesting is that IMAP act as a tunnel to SMTP 
providing and authenticated connection using the same credentials as the 
imap client uses.

Unless I'm missing something - and I might be - seems to me this would 
be dirt simple to implement and wouldn't impose any of the limitations 
to the SMTP protocol that other people here are concerned about.

Who likes this idea?

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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 18 Aug 2005 17:18:32 +0100

On Thu Aug 18 01:41:10 2005, Marc Perkel wrote:
> Here's what I propose. The client when sending email would 
> establish a second IMAP connection to the server. One of the 
> CAPABILITIES will be SMTP-TUNNEL. After sending the command the 
> IMAP server opens a connection to the SMTP server and acts as a 
> straight pipe through until the connection is closed.

> Who likes this idea?

Not me. You could do a SUBMISSION=smtp:submission.example.net 
however, achieve the same result, for a marginally higher overhead 
for the client, but much, much lower cost of support in the server, 
both in terms of initial code and ongoing operation. That appears to 
solve all problems solved by your proposal.

I'm willing to bet that all server implementors present could 
implement such an "extension" in a matter of minutes (Some wouldn't 
need to write a line of code). Client implementors may need to 
connect during config time in order to check the capability string, 
but many clients already run a probe at config time anyway.

However, mobile phones already have the ability to receive 
configuration data via SMS, etc - Sony Ericsson have a GUI 
configuration thing on their web page, after all. I don't believe 
configuration to be a concern for mobile devices.

I believe it to be a solved issue for desktops, too - ACAP works fine 
for me even over low-bandwidth, high latency, connectivity.

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Aug 2005 17:10:44 -0700

> straight pipe through until the connection is closed.

What is the advantage of a separate connection to the IMAP server 
instead of a separate connection to the Submit (port 587) server?

>
>  The advantage of this is that you can take your existing SMTP code 
> and instead of connecting it on port 25 you connect it on port 143.

Why not take your existing code and connect on port 587?

>   Then everything you could do with SMTP is available.

Likewise with 587, everything is available.

>  You would just need to add a smal layer to the SMTP layer to 
> authenticate to the IMAP server and tell it to open a tunnel to the 
> SMTP server. On the server side you just connect to localhost:25 or 
> whatever you configure it to and pass data.
>
> providing and authenticated connection using the same credentials 
> as the imap client uses.

I don't see the advantage to the client.

>
>  Unless I'm missing something - and I might be - seems to me this 
> would be dirt simple to implement and wouldn't impose any of the 
> limitations to the SMTP protocol that other people here are 
> concerned about.

What limitations?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
...All repairs tend to destroy the structure [of the software], to
  increase the entropy and disorder of the system.  Less and less
  effort is spent on fixing original design flaws; more and more is
  spent on fixing flaws introduced by earlier fixes.  As time passes,
  the system becomes less and less well-ordered.  Sooner or later the
  fixing ceases to gain any ground.  Each forward step is matched by a
  backward one.  Although in principle usable forever, the system has
  worn out as a base for progress.  [...] Systems program building is
  an entropy-decreasing process, hence inherently metastable.  Program
  maintenance is an entropy-increasing process, and even its most
  skillful execution only delays the subsidence of the system into
  unfixable obsolescence.
                             --Fred Brooks in _The Mythical Man Month_

---

From: Marc Perkel <[email-masked]>
Date: Thu, 18 Aug 2005 17:46:07 -0700

The advantage answer to all your questions is - it eliminates the need 
to configure outgoing email.

Randall Gellens wrote:

>>  Here's what I propose. The client when sending email would establish 
>> a second IMAP connection to the server. One of the CAPABILITIES will 
>> be SMTP-TUNNEL. After sending the command the IMAP server opens a 
>> connection to the SMTP server and acts as a straight pipe through 
>> until the connection is closed.
>
>
>> providing and authenticated connection using the same credentials as 
>> the imap client uses.
>
>
>> limitations to the SMTP protocol that other people here are concerned 
>> about.
>
>
> What limitations?
>

-- 
Marc Perkel - [email-masked]

Spam Filter: http://www.junkemailfilter.com
    My Blog: http://marc.perkel.com

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Aug 2005 17:58:28 -0700

At 5:46 PM -0700 8/18/05, Marc Perkel wrote:

>  The advantage answer to all your questions is - it eliminates the 
> need to configure outgoing email.

Eliminates the need to configure what?  The client?  There are a 
number of other approaches to the configuration problem.  I agree 
that we can't expect users to have to enter a bunch of configuration 
details into different clients, especially on a small form-factor 
device with a limited keyboard.

For example, years ago Eudora clients and servers implemented an 
automatic configuration option which used a subset of ACAP to access 
a slew of configuration details.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
"!sgub evah t'nseod CP sihT ?sgub naem ayaddahW"

---

From: Dave Cridland <[email-masked]>
Date: Fri, 19 Aug 2005 09:13:29 +0100

On Thu Aug 18 11:58:28 2005, Randall Gellens wrote:
> that we can't expect users to have to enter a bunch of 
> configuration details into different clients, especially on a small 
> form-factor device with a limited keyboard.
> 
> 
And hence SyncML, DM, et al. Most phones appear to have a 
configuration-via-SMS facility.

> automatic configuration option which used a subset of ACAP to 
> access a slew of configuration details.

And today, Polymer, my client, uses full ACAP to do the same, 
enabling full configuration roaming, administratively directed 
configuration, etc.

I completely agree this is a solved problem.

Dave.

---

From: Marc Perkel <[email-masked]>
Date: Fri, 19 Aug 2005 08:03:22 -0700

Randall Gellens wrote:

> Eliminates the need to configure what?  The client?

The advantage is that it eliminates the need to configure outgoing email 
on the client.