Subject: RE: [lemonade] IMAP push/pull plan

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 5 Jan 2004 20:22:46 -0600

For some diversity of opinion...

I mildly favor the push model, in part because it feels more secure.  

In my corner of the world, there is not a wide diversity of legacy clients.  If I have IMAP push, I can imagine being able to dispense with a client-accessible SMTP-submit server.  This reduces the number of entities that must reside within the DMZ network that need access to fairly sensitive subscriber directory data.  An authenticated submission server generally requires access to the users passwords (or encrypted passwords) stored in a directory by the server in the DMZ.  An IMAP proxy server in the DMZ only needs access to more limited information mapping the recipient identity to a message store... or less.  Gaining control of the IMAP proxy does not gain access to the password data.  Gaining access to a submission server does get me access to enough info to authenticate the user.... and to play off-line guess the password games.

So, if I get push submission via IMAP, I think I get a more secure environment for my end-users.  I also get fewer client-to-server protocols to manage and fewer firewall rules.  Overall, this feels like a pretty good win for push.

Greg V.

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]]
Sent: Monday, January 05, 2004 7:02 PM
To: Mark Crispin
Cc: Rob Siemborski; Glenn Parsons; IETF LEMONADE (E-mail)
Subject: RE: [lemonade] IMAP push/pull plan

At 3:37 PM -0800 01/01/2004, Mark Crispin wrote:
> > And while all of this is a very interesting, I think we have to go back
>> to the common use case, and ask ourselves whether "forward without
>> download", which is one of the immediately motivating cases here,
>> would require anything more than what an IMAP server can do
>> using the local mailboxes.
>
>Indeed.  The advocates of pull have seen this coming from the onset.

I'm afraid I don't follow you here.  Do you mean that the advocates
of pull have seen from the outset that "forward without download" requires
more than what an IMAP server can do using the local mailboxes?

There is a very critical scope question here, from my point of view.
If the working group sees this task as developing what we might call
"non-client compose", in which the client can direct some server
(be it Submit or IMAP) to assemble a message from multiple
data sources without downloading the parts, then the "compose
from a single, local data source" would be a degenerate case of the
"non-client compose".    Using the same mechanism for the
degenerate case as the full functionality makes lots of sense.

But I think this working group has a much more focused deliverable:

>2. Enhance the existing IMAP4 message retrieval and/or message
>submission (RFC 2476) protocols to satisfy the requirements for
>forwarding a message and/or its attachments without downloading
>the message to the client and subsequently uploading the message to a
>server.

"a message and/or its attachments" does look to me like
a message and its parts taken from a single data source
were/are the key motivating use case for the words
in the charter.  Charters are not unchangeable holy writ, of course,
and there is some room for disagreement about the limitations
inherent even in this statement.  But I personally believe that this
use case gives a very focused view of what needs to be done
and that getting it done quickly and right would be a very
valuable piece of work.  A quick round of the working group
to be sure which problem we're tackling seems to be in order,
as the engineering trade-offs are surely different with
the different perspectives. 

Again speaking personally, if the consensus of the working group
is that the task is "non-client compose", rather than "forward without
download", then I am not really sure that either a Submit server or
an IMAP server would be the right place to do the work.  Revisiting
the use of a multi-function proxy might be appropriate in that
case, because the core functionality may be beyond what are
safe and sane ways to extend IMAP or Submit servers.  I am nagged,
though, by the idea that we will end up re-inventing the remote shell,
as that is what I and many others use to handle this problem
(I sometimes use ssh to reach a remote server with better connectivity
when I need to handle email over a very poor link; sometimes, though,
I take it as a sign to take a day or two away from email.  This is the
source of the delay in my reply to this message.  Apologies for any
inconvenience).
			regards,
				Ted Hardie

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

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 5 Jan 2004 18:35:08 -0800 (Pacific Standard Time)

On Mon, 5 Jan 2004, Vaudreuil, Greg M (Greg) wrote:
> In my corner of the world, there is not a wide diversity of legacy
> clients.  If I have IMAP push, I can imagine being able to dispense with
> a client-accessible SMTP-submit server.  This reduces the number of
> entities that must reside within the DMZ network that need access to
> fairly sensitive subscriber directory data.

This is an argument for a submission mechanism that is within the DMZ
network.  It is not an argument for push, except in the weak sense that
push forces such a configuration.

The dichotomy here is MUST vs. MAY (or SHOULD).

-- Mark --

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 6 Jan 2004 11:35:57 -0800 (Pacific Standard Time)

On Tue, 6 Jan 2004, Pete Resnick wrote:
> What I read Greg as saying is that
> with push, he can have one entity (the IMAP server) that has access to user
> authentication data,

This is true if (and only if) all the data is located on the IMAP server.

> whereas if he has a submission server that users need to
> access, it would also need access to user authentication data.

The submit server needs authorization data.  User authentication data can
be used as such, but it is not the only example.

Note that in many environments, the submit server and IMAP server are
already in the same authorization web.  For example, at UW the IMAP
servers and submit servers both require authentication and are in the same
Kerberos realm.

The cases to worry about are:
 . the case in which the submit server does not require authentication
   that is, are open relays.  I suspect that this is a vanishly small
   number.
 . the case in which the submit server authenticates via a weak mechanism
   such as client IP address.
 . the case in which the submit server authenticates strongly, but
   differently from the IMAP server.

Where we may differ is my belief that the first two cases are heading
towards extinction.  I've used strong submit server authentication for so
long I find it difficult to believe that, given a choice, anyone who
choose otherwise.

-- Mark --

---

From: Pete Resnick <[email-masked]>
Date: Tue, 6 Jan 2004 13:23:16 -0600

On 1/5/04 at 6:35 PM -0800, Mark Crispin wrote:

>>If I have IMAP push, I can imagine being able to dispense with a 
>>client-accessible SMTP-submit server. This reduces the number of 
>>entities that must reside within the DMZ network that need access 
>>to fairly sensitive subscriber directory data. An authenticated 
>>submission server generally requires access to the users passwords 
>>(or encrypted passwords) stored in a directory by the server in the 
>>DMZ.
>
>This is an argument for a submission mechanism that is within the DMZ network.

Actually, it sounds like there's more to it than that, but I'm not 
sure I fully understand the security implications: What I read Greg 
as saying is that with push, he can have one entity (the IMAP server) 
that has access to user authentication data, whereas if he has a 
submission server that users need to access, it would also need 
access to user authentication data. That *sounds* like a more secure 
environment, but again, I'm not sure I've got a full grasp of the 
security issues involved.

Chairs: Can we get a security "geek" to give us some sort of review 
as to whether this is really an issue or not?
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102