Subject: Re: [lemonade] Outside the box suggestion about Lemonade

From: Marc Perkel <[email-masked]>
Date: Thu, 18 Aug 2005 09:40:29 -0700

OK thanks. I would clarify what I'm proposing.

I looked at the current proposal and what I'm proposing might be in 
addition to rather than instead of the current proposal. LDELIVER as it 
is now offers capabilities of sending messages and forwarding 
attachments without downloading them, leaving more power on the server 
side. This is important for mobile clients with limited power on the 
client end.

What I'm suggesting is something in addition to LDELIVER where we add 
SMTP-TUNNEL as a capability. This is for laptop users who have to deal 
with finding an outgoing smpt server and who might be behind a firewall 
that blocks smtp ports.

What is different about my proposal is that what I'm suggesting isn't a 
straight pass through at the beginning. The client has to talk to IMAP, 
then authenticate, and then upon successfil authentication would ask for 
an SMTP connection to the local smtp server. At that point it is a 
tunneled connection.

1) This allows the IMAP ports to be used for SMTP and avoid port blocking.
2) It uses the same IMAP authentication for SMTP so outgoing SMTP nee 
not be configured separately. It merely acts as an authenticated condiut 
to get to SMTP.
3) It would in no way interfere with future advancements in SMTP 
technology at others were concerned about.
4) Client and server recoding would be trivial.
5) This could be used in place of SMTP-AUTH and would eliminate the need 
for authenticated SMTP making server smtp configuration easier.

So - if you look at it as an addition then you don't have to choose 
between them.

Stephane Maes wrote:

>Marc,
>
>Based on the suggestions that we have received so far, we will publish a proposed update. We are looking at smtp proxy options.
>
>Note that LDELIVER contributes also in supporting server side recomposition with upload of only body / header part diffs. I am not sure that tunneling would allow this. But I am looking into it.
>
>Thanks
>
>Stephane
>
>PS I still have an action item to provide the use cases / reasons / pros of using it. I will distribute soon on the list.
>_____
>Stephane H. Maes, PhD,
>Director of Architecture - RTCC & Mobile, Oracle Corporation.
>Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296.
>e-mail: [email-masked]
>IM: shmaes (AIM, Y!,Skype) or [email-masked] (MSN Messenger) 
>
>-----Original Message-----
>From: [email-masked] <[email-masked]>
>To: [email-masked] <[email-masked]>
>Sent: Thu Aug 18 08:41:10 2005
>Subject: [lemonade] Outside the box suggestion about Lemonade
>
>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
>
>
>
>
>  
>

-- 
Marc Perkel - [email-masked]

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

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

---

From: Mark Crispin <[email-masked]>
Date: Thu, 18 Aug 2005 10:31:40 -0700 (PDT)

On Thu, 18 Aug 2005, Marc Perkel wrote:
> SMTP-TUNNEL as a capability. This is for laptop users who have to deal with 
> finding an outgoing smpt server and who might be behind a firewall that 
> blocks smtp ports.

That is only for a very simple-minded view that assumes that mail access 
rights are equivalent to mail posting rights; and that the same 
credentials to establish the former suffice to perform the latter.

Furthermore, laptops should not be using SMTP servers.  They should be 
using SUBMISSION servers.  Different port, different service.  I look 
forward to the day when personal machines find SMTP to be totally 
inaccessible.  [We're doing that now on the UW campus network.]

Next, you will find substantial push-back from IMAP server developers that 
they do not desire to create Yet Another Message Submission Protocol; 
which is precisely what putting submission into IMAP would do.  You 
underestimate the long-term support and maintenance costs of this 
deceptively "simple" notion.

Next, the availability of the YAMSP in IMAP is a trap.  Some cretin will 
build a client that requires YAMSP; that in turn will force IMAP servers 
to implement YAMSP even when it is inappropriate.  For example, we have 
dedicated IMAP server systems for our bugtracker and various other "group" 
mailboxes.  These systems are intentionally read-only, and most certainly 
do not want to be in the business of handling posts.

We have enough traps due to Blackberry (curse its developers to eternal 
damnation), thank you.  Do you know what it is like to have to support an 
Exchange server for *one* VIP?

I wish the Gnu cult would turn itself to something useful, such as 
developing an open-source Blackberry portal that doesn't require Exchange, 
instead of reimplementing other open source projects because they don't 
like that project's definition of "free".

Finally, and this especially applies to some of the mobile devices used by 
Lemonade, charging is important with some forms of mobile devices.  IMAP 
is primarily a "download" service; SUBMISSION is an "upload" service.  I 
may be obliged to pay higher packet charges to access my downloads in a 
roaming scenario, but there is no reason to do for upload; email can be 
injected anywhere in the network.

-- 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: Thu, 18 Aug 2005 11:14:26 -0700

Mark Crispin wrote:

>> SMTP-TUNNEL as a capability. This is for laptop users who have to 
>> deal with finding an outgoing smpt server and who might be behind a 
>> firewall that blocks smtp ports.
>
>
> That is only for a very simple-minded view that assumes that mail 
> access rights are equivalent to mail posting rights; and that the same 

Yep - that's exactly right - yes. That's what I want - the same 
credentials. The assumption is that if you are authorized to get email 
then you are authorized to send email. The idea is - simplicity.

> inaccessible.  [We're doing that now on the UW campus network.]

That's your setup - not mine.

>
> Next, you will find substantial push-back from IMAP server developers 
> that they do not desire to create Yet Another Message Submission 
> Protocol; which is precisely what putting submission into IMAP would 
> do.  You underestimate the long-term support and maintenance costs of 
> this deceptively "simple" notion.

It's not a new protocol. it's a pass through to your existing submission 
protocol. Not everyone has separate submission servers.

>
> Next, the availability of the YAMSP in IMAP is a trap.  Some cretin 
> will build a client that requires YAMSP; that in turn will force IMAP 
> servers to implement YAMSP even when it is inappropriate.  For 
> example, we have dedicated IMAP server systems for our bugtracker and 
> various other "group" mailboxes.  These systems are intentionally 
> read-only, and most certainly do not want to be in the business of 
> handling posts.

You could restrict it on the back end any way you want. In any proposed 
system here I would assume that one would want to have some options to 
further restrict access to new features. No access for read only 
accounts. This isn't a new submission service. It's a gateway to your 
existing service. It provides authentication and then passes through.

---

From: Curtis King <[email-masked]>
Date: Thu, 18 Aug 2005 12:17:27 -0600

On 18-Aug-05, at 10:40 AM, Marc Perkel wrote:

> 5) This could be used in place of SMTP-AUTH and would eliminate the  
> need for authenticated SMTP making server smtp configuration easier.

A poor implementation is no excuse to re-implement a protocol. You  
can accomplish your goals now by using Message Submission and SMTP-AUTH.

ck

---

From: Marc Perkel <[email-masked]>
Date: Thu, 18 Aug 2005 11:29:05 -0700

> can accomplish your goals now by using Message Submission and SMTP-AUTH.

Yes - I'm doing that now. The reason I'm proposing this is to eliminate having to do that. My SMTP-AUTH just authorizes against IMAP using Cyrus-SASL talking to Dovecot.

The idea here is to eliminate outgoing smtp setup and to be able to both receive and send with only one login - not two. Users only need set up their incoming and the outgoing just works.

It isn't reimplimenting a protocol. It's a pass through to an existing protocol.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 18 Aug 2005 11:55:29 -0700

On Thu, 18 Aug 2005, Marc Perkel wrote:
> Yep - that's exactly right - yes. That's what I want - the same credentials. 
> The assumption is that if you are authorized to get email then you are 
> authorized to send email. The idea is - simplicity.

That is a false assumption.

Clients that make that assumption are broken.  The creation of such 
clients should not be encouraged.

Your "simplicity" involves considerable costs to others.

> That's your setup - not mine.

Do you really mean to suggest that your convenience is of such great 
importance that:
  . IMAP server implementors are forever doomed to maintain a separate
    independent message submission mechanism.
  . IMAP server system administrators are forever doomed to support
    submission on a read-only server system?
  . client implementors are forever doomed to support, and maintain,
    multiple posting mechanisms?
  . the Lemonade working group must shelve its other important work
    in order re-open an already-settled debate?

Please explain why your convenience rates such importance.

>> they do not desire to create Yet Another Message Submission Protocol; which 
>> is precisely what putting submission into IMAP would do.  You underestimate 
>> the long-term support and maintenance costs of this deceptively "simple" 
>> notion.

It is so a new protocol.  It involves a massive change to IMAP's protocol 
engine; effectively, IMAP must have two protocol engines.

This is not a cost to be dismissed airily.

This thread is out of order.  It re-opens an old debate (and old wounds), 
and it distracts the working group from more pressing business that is 
already well behind schedule.

> You could restrict it on the back end any way you want.

This statement staggers me.

Server vendors and server managers have only the most tenuous control over 
their infrastructure.  I already gave the example of Blackberry as a 
client which forces server managers to provide a particular configuration 
that they did not want to provide.

Your proposal would have the effect of further eroding that control.

-- Mark --

---

From: Marc Perkel <[email-masked]>
Date: Thu, 18 Aug 2005 12:15:45 -0700

Mark Crispin wrote:

>> credentials. The assumption is that if you are authorized to get 
>> email then you are authorized to send email. The idea is - simplicity.
>
>

It's an option. If you don't like it - don't implement it.

> clients should not be encouraged.

That's your opinion. Some people want the simplicity of allowing people 
who have read access to use the same connection to send. Just because 
you don't want to do it doesn't mean others are like you.

> Your "simplicity" involves considerable costs to others.

What cost? Those who don't want to use it mearly don't use it? The 
capability is optional for those who want to implement it.

>
>>> Furthermore, laptops should not be using SMTP servers.  They should 
>>> be using SUBMISSION servers.  Different port, different service.  I 
>>> look forward to the day when personal machines find SMTP to be 
>>> totally inaccessible.  [We're doing that now on the UW campus network.]
>>

It isn't a separate independent mecanism - it's a pass through to your 
existing submission server.

>    submission on a read-only server system?

Why are you assuming that? You wouldn't activate this feature on a read 
only server.

>    multiple posting mechanisms?

This is a slight enhancement of the existing posting mecanism. once the 
initial handshake establishes a connection it talks using the existing 
protocols.

>    in order re-open an already-settled debate?

I have no idea why you say this. My suggestion is in addition to what is 
proposed.

> Please explain why your convenience rates such importance.

It might come as a shock to you but out in the real world convienence is 
everything. When non-geek users have half the configuration to deal with 
that is significant in that it cuts support.

>
>>> Next, you will find substantial push-back from IMAP server 
>>> developers that they do not desire to create Yet Another Message 
>>> Submission Protocol; which is precisely what putting submission into 
>>> IMAP would do.  You underestimate the long-term support and 
>>> maintenance costs of this deceptively "simple" notion.
>>
>> It's not a new protocol. it's a pass through to your existing 
>> submission protocol. Not everyone has separate submission servers.
>
>
> It is so a new protocol.  It involves a massive change to IMAP's 
> protocol engine; effectively, IMAP must have two protocol engines.

No - it's a pass through. Once you authenticate it's a tunnel. It is NOT 
a new protocol.

> This statement staggers me.

You know Mark there's something called a configuration file. Ever other 
IMAP server developer except you uses one. In a configuration file you 
can choose if you are going to offer this feature or not or maybe allow 
it for some users and not others.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 18 Aug 2005 21:23:19 +0200

> It's an option. If you don't like it - don't implement it.

LEMONADE isn't in the business of specifying options. It specifies a 
mandatory-to-implement set of SMTP/IMAP extensions.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Thu, 18 Aug 2005 13:52:40 -0700 (PDT)

> It's an option. If you don't like it - don't implement it.

Until some cretin makes the option mandatory in his client, and then posts 
on his support page that the reason my server doesn't work with his client 
is that my server is broken.

This has happened before, and a steep price was paid each time.

>> Clients that make that assumption are broken.  The creation of such clients 
>> should not be encouraged.
> That's your opinion.

Those opinions are founded upon 30+ years of experience with 
ARPAnet/Internet protocols in general, and upon my experience as the 
inventor of IMAP in particular.

Maybe it is the case that that plus $4.32 is worth a quad latte in a
Seattle Starbucks; but I tend to think that the opinions of individuals 
with decades of experience should be considered and not airily dismissed.

> Some people want the simplicity of allowing people who 
> have read access to use the same connection to send. Just because you don't 
> want to do it doesn't mean others are like you.

Just because it would greatly simplify my life to be Dictator Of The World 
does not mean that I should be elevated to that office.  In fact, it would 
be a very bad idea.

Sometimes, it is necessary to accept being told "no".

Sometimes, it is necessary to recognize that "no" is the correct answer 
even if it involves personal inconvenience.

Everybody would like to have what is simple for them in all things.  But 
often it is necessary to make concessions.  It is necessary to consider 
not only what is good for oneself, but what is good for others.  Even more 
importantly, it is necessary to consider that what is good for oneself may 
wreak harm upon others.

> What cost? Those who don't want to use it mearly don't use it? The capability 
> is optional for those who want to implement it.

There is no such thing as an "option".

If an "option" is widely used, it becomes de facto mandatory.  If an 
"option" is not widely used, it languishes in obscurity and dies.

> existing submission server.

What existing submission server?!?

What makes you think that I have a submission server?  Maybe the system 
manager who uses my IMAP server also has a submission server someplace, 
but I don't know anything about it.

Maybe you want me to write TCP I/O routines and an SUBMISSION/SMTP engine 
in my IMAP server to talk to this server.  An SUBMISSION/SMTP client 
engine is not a trivial undertaking.

Do you think that all that has to be done is just pipe bytes (your 
repeated reference to a "tunnel")?  This is a common novice mistake.

> Why are you assuming that? You wouldn't activate this feature on a read only 
> server.

Then the client that requires that this feature be present, since it does 
not implement message posting any other way, will fail on that system.

> initial handshake establishes a connection it talks using the existing 

Proxies are quite complex by themselves, and proxies embedded inside other 
protocols (which is what you propose) are even more complex.

To start with, you have to recognize that IMAP, not TCP, is now the 
transport mechanism in SMTP-over-IMAP.  This means that all the TCP 
conditions which can occur in an SMTP session must now be represented in 
the IMAP session.  This is necessary to distinguish between TCP conditions 
which occur in the IMAP to SMTP path from TCP conditions that occur in the 
client to IMAP path.  This involves the creation of an escape mechanism. 
This in turn involves the creation of a quoting mechanism.

Next, we have to have some mechanism by which the authentication and 
authorization credentials are passed from the IMAP server to the SMTP 
server.  The very simplest means (and it's not so simple) is to have some 
out-of-band transmission along with a SASL AUTH EXTERNAL negotation. 
[No, you can't just validate IP address; all the kewl d00dz have known how 
to crack that "security" for years now.]

We're still talking about embedding one protocol inside another.  We 
haven't even gotten to the problems faced by a proxy yet.

> I have no idea why you say this. My suggestion is in addition to what is 

Do you honestly believe that you are the very first person ever to have 
come up with this idea?

Do you honestly believe that everybody else is so stupid that they never 
thought about it?

Do you honestly believe that I am so stupid that I didn't think about it 
when I first invented IMAP?

Please read the archives of the mailing list.  This idea monopolized the 
working group's attention for a considerable period of time (more than a 
year).

> everything. When non-geek users have half the configuration to deal with that 
> is significant in that it cuts support.

The membership of this working group contains many individuals from very 
large and important vendors and extremely diverse backgrounds who are very 
aware of real world issues.

There are many real world issues that this working group needs to address 
of much greater consequence than your convenience.

> No - it's a pass through. Once you authenticate it's a tunnel. It is NOT a 
> new protocol.

It can't be a tunnel, at least not a tunnel by any definition that I am 
aware of, and I've been writing tunnels since 1978.

Your proposal is for a proxy, and more importantly a proxy embedded in 
another protocol.

> You know Mark there's something called a configuration file. Ever other IMAP 
> server developer except you uses one. In a configuration file you can choose 
> if you are going to offer this feature or not or maybe allow it for some 
> users and not others.

Apparently you feel that is a flaw in my server.

-- Mark --

---

From: Marc Perkel <[email-masked]>
Date: Thu, 18 Aug 2005 14:48:03 -0700

Mark Crispin wrote:

> Until some cretin makes the option mandatory in his client, and then 
> posts on his support page that the reason my server doesn't work with 
> his client is that my server is broken.

If it isn't lisdted in the CAPABILITIES then the client won't try to use 
it. There are a lot of things your IMAP server doesn't support.

> inventor of IMAP in particular.

That doesn't impress me. Your IMAP server is the weakest server of any 
of them. WU-IMAP is totally stuck in the past. I don't know why you are 
even part of this discussion because you're against any progress. Note 
the title of this thread "Thinking outside the box" - you are the box!

> Seattle Starbucks; but I tend to think that the opinions of 
> individuals with decades of experience should be considered and not 
> airily dismissed.

Decades of experience are meaningless when people who have been in it 
for far less time have surpassed you. Your IMAP server quite frankly 
sucks. 

>
>> Some people want the simplicity of allowing people who have read 
>> access to use the same connection to send. Just because you don't 
> Just because it would greatly simplify my life to be Dictator Of The 
> World does not mean that I should be elevated to that office.  In 
> fact, it would be a very bad idea.

Agreed.

> Sometimes, it is necessary to accept being told "no".

And - you have the authority to do that? I thought this was a discussion 
list but you seem to want to be the gig dog and tell everyone what they 
can and can't suggest.

>
> Sometimes, it is necessary to recognize that "no" is the correct 
> answer even if it involves personal inconvenience.

My answer to that is - no!

>
> Everybody would like to have what is simple for them in all things.  
> But often it is necessary to make concessions.  It is necessary to 
> consider not only what is good for oneself, but what is good for 
> others.  Even more importantly, it is necessary to consider that what 
> is good for oneself may wreak harm upon others.

I don't know if you've noticed but the only people who are using your 
IMAP server are people who haven't managed to move away from it yet. 
That's because they do want convience.

> There is no such thing as an "option".

Not on your server - everyone else has configuration files.

> "option" is not widely used, it languishes in obscurity and dies.

Your server is already dead. You're holding everyone else back.

>
>> It isn't a separate independent mecanism - it's a pass through to 
>> your existing submission server.
>
>

Any one you set it for. On the server side you woulf have a 
configuration file that said what server and ports to connect to. 
Generally it would be port 25 and localhost.

>
> What makes you think that I have a submission server?  Maybe the 
> system manager who uses my IMAP server also has a submission server 
> someplace, but I don't know anything about it.

That's your problem.

>
> Maybe you want me to write TCP I/O routines and an SUBMISSION/SMTP 
> engine in my IMAP server to talk to this server.  An SUBMISSION/SMTP 
> client engine is not a trivial undertaking.

Definitely not.

> repeated reference to a "tunnel")?  This is a common novice mistake.

If you are running smtp on the same box then you would connect to 
localhost. If you don't have an smtp server then you can't use the feature.

>> Why are you assuming that? You wouldn't activate this feature on a 
>> read only server.
>
>
> Then the client that requires that this feature be present, since it 
> does not implement message posting any other way, will fail on that 
> system.

The client could still configure for SMTP as it does now if the feature 
isn't present.

>
>> This is a slight enhancement of the existing posting mecanism. once 
>> the initial handshake establishes a connection it talks using the 
>> existing protocols.
>
>
> Proxies are quite complex by themselves, and proxies embedded inside 
> other protocols (which is what you propose) are even more complex.

Now you're just being silly.

> conditions which can occur in an SMTP session must now be represented 
> in the IMAP session.  This is necessary to distinguish between TCP 
> conditions which occur in the IMAP to SMTP path from TCP conditions 
> that occur in the client to IMAP path.  This involves the creation of 
> an escape mechanism. This in turn involves the creation of a quoting 
> mechanism.

You clearly don't understand what I'm suggesting.

> server.  The very simplest means (and it's not so simple) is to have 
> some out-of-band transmission along with a SASL AUTH EXTERNAL 
> negotation. [No, you can't just validate IP address; all the kewl 
> d00dz have known how to crack that "security" for years now.]

Nope - you don't pass the credentials from IMAP to SMTP. The idea is 
that if you are already authenticated by IMAP then to connect to SMTP 
without and authentication. If you actually READ what I proposed you 
could talk about it accurately. The reason to use this is bacause you 
are eliminating the need for SMTP AUTH.

> haven't even gotten to the problems faced by a proxy yet.

No - we aren't.

>> I have no idea why you say this. My suggestion is in addition to what 
>> is proposed.
>
>
> Do you honestly believe that you are the very first person ever to 
> have come up with this idea?

perhaps ...

>
> Do you honestly believe that everybody else is so stupid that they 
> never thought about it?

you don't even grasp the proposal so it's clearly above your head.

>
> Do you honestly believe that I am so stupid that I didn't think about 
> it when I first invented IMAP?

yep - you are really so full of yourself aren't you.

>
> Please read the archives of the mailing list.  This idea monopolized 
> the working group's attention for a considerable period of time (more 
> than a year).
>
>> It might come as a shock to you but out in the real world convienence 
>> is everything. When non-geek users have half the configuration to 
>> deal with that is significant in that it cuts support.
>
>
> The membership of this working group contains many individuals from 
> very large and important vendors and extremely diverse backgrounds who 
> are very aware of real world issues.

Some are - some aren't.

>
> There are many real world issues that this working group needs to 
> address of much greater consequence than your convenience.

If your not looking for convience then why are we trying to create a 
standard for IMAP sending email?

>> No - it's a pass through. Once you authenticate it's a tunnel. It is 
>> NOT a new protocol.
>
>
> It can't be a tunnel, at least not a tunnel by any definition that I 
> am aware of, and I've been writing tunnels since 1978.
>

My proposal is to open a separate connection to the IMAP server - 
authenticate to it - send a SMTP-TUNNEL command - and then the IMAP 
server open a port 25 connection to localhost and passes to to the 
client over the IMAP port. The client then acts like it is talking to an 
SMTP server over port 143.

>
>> You know Mark there's something called a configuration file. Ever 
>> other IMAP server developer except you uses one. In a configuration 
>> file you can choose if you are going to offer this feature or not or 
>> maybe allow it for some users and not others.
>
>

One of the happiest days this year was when I got Timo over at Dovecot 
to add a few features I needed to get rid of your IMAP server. Your 
server really sucks. Now I can talk to MySQL if I want to, I can use 
MAILDIR if I want to. I am free of the WU-IMAP cage.

Free at last! Free at last! Free at last!

You're as stubborn and arrogant as Richard Stallman.

---

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

At 9:40 AM -0700 8/18/05, Marc Perkel wrote:

>  This is for laptop users who have to deal with finding an outgoing 
> smpt server and who might be behind a firewall that blocks smtp 
> ports.

That's what port 587 is for.  That's why we try to speak of 
"submission" or "SMTP/submit" instead of just SMTP or port 25.

Blocking outbound port 25 is an attempt to block outbound spam sent 
via SMTP relay.

Port 587 is dedicated to message submission and is supposed to 
require authentication.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I am not "Deliciously Saucy"
   --Written on the chalkboard by Bart in the
     opening of _The_Simpsons_ (TV show)

---

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

At 11:29 AM -0700 8/18/05, Marc Perkel wrote:

>  My SMTP-AUTH just authorizes against IMAP using Cyrus-SASL talking 
> to Dovecot.

Can't you configure both servers to authenticate against a common 
service?  That might be easier than changing IMAP.  Likely I'm not 
understanding the intent of your proposal.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
  "American Non Sequitur Society --
   We don't make sense,
   But we do like pizza."

---

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

At 12:15 PM -0700 8/18/05, Marc Perkel wrote:

> access to use the same connection to send.

Now I know I'm confused.  I thought your proposal was that the client 
opens a second connection?

>   When non-geek users have half the configuration to deal with that 

There are a number of ways to make the configuration problem easier. 
You can certainly offer both IMAP and Submission on the same host 
(which might be a front-end that just accepts connections and farms 
them out to back-end servers).  You can deploy a server that offers 
both services in one package.  You can use a variety of mechanisms to 
configure the client without user entry (such as ACAP, XCAP, etc.)

>  The capability is optional for those who want to implement it.

There is a cost in protocol complexity to having optional 
functionality with limited usefulness.  There is a much larger cost 
(IMHO) in the client not knowing if servers are likely to offer a 
function or not.  This is (again, IMHO) one of the major problems 
IMAP already faces: clients need to implement multiple code paths to 
be able to deal with a variety of servers.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
If there's a possibility that something might be controversial,
then why not eliminate it?
  --Wild Rose, Wis. district administrator, explaining why _Bury
  My Heart at Wounded Knee_ by Dee Brown was removed from schools.

---

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

At 2:48 PM -0700 8/18/05, Marc Perkel wrote:

> client over the IMAP port. The client then acts like it is talking 
> to an SMTP server over port 143.

Why wouldn't the server connect to port 587?

What credentials would the IMAP server pass to the Submit server? 
Its own?  Or the user's?  If the user's, how does it get it?  Is the 
client required to use username/password?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Dr. Beverly Crusher to Wesley Crusher as he is about to beam down to
begin his journey with the Traveler into other dimensions: "Be sure to
dress warmly on those other planes of existence."