Subject: [lemonade] Advantages of Pull

From: Rob Siemborski <[email-masked]>
Date: Tue, 10 Feb 2004 08:55:19 -0500 (EST)

Ted/Pete,

I'm sitting here reading through the "Embedded URI Varient" thread, and I
think I'm missing something important.  What do you see as the man
*advantages* of push over pull?

Currently, I can see:
a) Fits exactly into the LEMONADE charter -- no more, no less.
b) There is a perception that is simpler to deploy (possibly because it
only modifies the IMAP server, possibly because it does not require
implementing a URLFETCH client).

Am I missing something?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

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

---

From: Rob Siemborski <[email-masked]>
Date: Tue, 10 Feb 2004 08:59:53 -0500 (EST)

> Am I missing something?

(Other than the fact that the subject of this message probably should have
been "Advantages of Push?") :)

Sigh.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12

---

From: Pete Resnick <[email-masked]>
Date: Tue, 10 Feb 2004 21:06:48 -0600

Since I was asked:

On 2/10/04 at 8:55 AM -0500, Rob Siemborski wrote:

>What do you see as the main *advantages* of push over pull?
>
>Currently, I can see:

That's an administrative reason, not a technical one, and it's not a 
big deal to me.

>b) There is a perception that is simpler to deploy (possibly because 
>it only modifies the IMAP server, possibly because it does not 
>require implementing a URLFETCH client).

That has some traction to it for me, but is not primary. Greg and Ted 
laid out some interesting ones in their messages. For me, the main 
two are:

- For the use cases that I think are going to be the vast majority, 
push seems the simplest architecturally

- I think the security model is more manageable

Architecturally: As a client, I've got an IMAP reference to data 
which is already on my IMAP server because I am either collecting 
together from other places in my IMAP store or I'm putting it there 
because I wanted a copy of the sent message.

With push, in the same IMAP session, I give that IMAP reference to 
the IMAP server, tell it to collect together the data from its local 
storage, and push it out to the submit server. It's a straight line 
conversation: client->IMAP Server->Submit Server.

With pull, I tell the IMAP server to collect together the data (if 
I'm using CATENATE or making my own copy of a new message), I form a 
different reference to that data (which includes the authorization 
data), I have an independent conversation with a submit server using 
a different protocol, and tell the submit server to have a 
conversation with my IMAP server to retrieve the data. The 
conversation is client->IMAP Server, client->Submit Server, and 
Submit Server->IMAP Server. That 3-way handshake just seems more 
complicated.

Aside from that, IMAP servers seem well equipped to retrieve and 
transmit data. Submit servers do not seem well equipped to retrieve 
data. Putting this burden on the IMAP server seems like a logical 
extension of operations it already does. Putting the burden on the 
submit server seems a significant departure from its current 
operations.

Security: The primary security consideration for me is "Who gets to 
look at user message data?". Next in order is "Who has access to user 
credentials?" Further down the list is "Who on my network is 
authorized to send messages?". With push, there is an obvious 
security configuration that makes sense to me: Users are 
authenticated and authorized to use the IMAP server (and therefore 
the IMAP server has an authorization/authentication database), only 
the IMAP server is authorized to send mail through the submit server 
(by co-locating the IMAP and submit server on the same machine or 
secure network), and the submit server has no access to 
authorization/authentication information or to any user message data 
not sent to it by the IMAP server directly. I could even firewall off 
port 143 from the submit server. That means that a compromised submit 
server will not give the attacker access to the 
authorization/authentication database, or any permission to messages 
not specifically sent to it by the IMAP server. It also means that 
some of the easier-to-write rouge SMTP processes on my net aren't 
able to use my submit server. My submit server can have one and only 
one job: To receive submissions from my IMAP server. That seems like 
a more secure environment.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Mark Crispin <[email-masked]>
Date: Tue, 10 Feb 2004 20:49:45 -0800 (PST)

On Tue, 10 Feb 2004, Pete Resnick wrote:
> Aside from that, IMAP servers seem well equipped to retrieve and transmit 
> data.

I think that you may have a misunderstanding of what IMAP servers do.

IMAP servers are well equipped to manipulate disk files.  IMAP servers are also 
well equipped to do stdio type I/O (to the controlling TTY).  Many IMAP servers 
have no TCP code at all; they are spawned by [x]inetd and as far as they know 
are console applications on under a shell.

It would be a major new mandate for IMAP servers to require them to have TCP 
code capable of acting as a protocol client of an MSA (e.g. SMTP server).

-- Mark --

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

---

From: Neil Katin <[email-masked]>
Date: Tue, 10 Feb 2004 21:14:23 -0800

To follow your argument forward Mark, couldn't those
programs that are not "tcp aware, but spun off by
inetd" just fork and exec /usr/lib/sendmail, and
pipe the message to it?

I'm not saying that's the optimal solution, but if
you really feel that tcp programming is a great burden,
there are (platform dependent) easy solutions.

	Neil

Mark Crispin wrote:

>> transmit data.
> IMAP servers are well equipped to manipulate disk files.  IMAP servers 
> are also well equipped to do stdio type I/O (to the controlling TTY).  
> Many IMAP servers have no TCP code at all; they are spawned by [x]inetd 
> and as far as they know are console applications on under a shell.
> 
> It would be a major new mandate for IMAP servers to require them to have 
> TCP code capable of acting as a protocol client of an MSA (e.g. SMTP 
> server).
> 
> -- Mark --
>