Subject: RE: [lemonade] Comments on PUSH and PULL drafts

From: Mark Crispin <[email-masked]>
Date: Tue, 2 Mar 2004 15:46:33 -0800 (Pacific Standard Time)

On Tue, 2 Mar 2004, Vaudreuil, Greg M (Greg) wrote:
> A quibble... I view the IMAP server in the push model to be the submit 
> server... no reason to pass credentials to a subsequent submit server, 
> the user is already authenticated.

That still presumes that credentials to access mail are equivalent to 
credentials to post mail.  That's not always the case now.  If mobile 
clients make that a requirement, that will limit the cases in which mobile 
clients can be used.

-- Mark --

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

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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 3 Mar 2004 09:29:26 -0800 (PST)

On Wed, 3 Mar 2004, Rob Siemborski wrote:
> > server...
> This doesn't hold up if we are, indeed, only solving the
> forward-without-download problem.  Such clients still need to be able to
> access an SMTP server for mail submission that is not
> forward-without-download.
> As many people are fond of saying on this list, solving anything beyond
> forward-without-download is outside of our charter.

That's a good point.

If (as was said in Seoul) one of the purpose of Push is to insulate mobile 
clients from changes in SMTP, then the current Push proposal is not good 
enough since it exposes SMTP details.

In order to insulate mobile clients from changes in SMTP via Push, you 
need a complete abstraction in IMAP -- essentially a new submit protocol 
layered in IMAP.  And that is out of charter.

That is the choice faced in the Push world:
  (1) create an SMTP-free way to do submit, overcoming charter objections,
      and hope that it stays useful after SMTP changes.
  (2) jacket SMTP-in-IMAP (as the current Push proposal does) and hope that
      changes in IMAP do not break it
  (3) create a mechanism which is only useful for forward-without-download,
      thus forcing all clients to implement two mechanisms to send mail.

I find none of these choices appealing.

(2) is a wretched compromise between the out-of-charter (1) and the 
obviously unsatisfactory (3).  Wretched compromises lead to wretched 
implementations.

-- Mark --

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 2 Mar 2004 17:40:23 -0600

A quibble... I view the IMAP server in the push model to be the submit server... no reason to pass credentials to a subsequent submit server, the user is already authenticated.  The IMAP server can pass the message onto any ordinary outbound SMTP relay.  Whether an implementor choses to separate these roles for some reason is irrelevant to the protocol standard.  

Greg V.

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]]
Sent: Wednesday, March 03, 2004 8:23 AM
To: Vaudreuil, Greg M (Greg)
Cc: Rob Siemborski; Marcus D. Leech; [email-masked]
Subject: RE: [lemonade] Comments on PUSH and PULL drafts

Much of this becomes clearer when you consider a SUBMIT server to be a 
separate service from the SMTP server.  As such, it is an authenticated 
service just as the IMAP service is.

Such servers are not in the DMZ, unless being in the DMZ is a requirement 
to make outgoing SMTP connections.

Of course, if you wish to allow submissions from outside, then it would 
have to be in the DMZ.  However, this is pretty useless unless you also 
allow IMAP access from outside.  In which case you don't really have a 
DMZ.  So, for the purpose of discussion a DMZ type environment, this 
doesn't apply.

Whether the SUBMIT server shares authentication credentials with the IMAP 
server, or has independent authentication credentials, is orthogonal.  
The key point to understand is that it does not impact Pull in either 
case.

The reason is URLAUTH.  URLAUTH restricts the access of the SUBMIT server 
to that data -- and only that data -- authorized by the sender of the 
message. There are additional value-added bells and whistles in URLAUTH so 
that, for example, the SUBMIT server may be required to authenticate 
itself as the SUBMIT server before it can use URLAUTH credentials.

In Pull, there is no need for the IMAP server to have any credentials on 
the SUBMIT server.  Nor is there a need for the SUBMIT server to have 
per-user credentials on the IMAP server (it *may* have credentials to 
prove that it's the SUBMIT server as value-added paranoia).

Push, on the other hand, presumes an authentication model in which either 
the SUBMIT server trusts the IMAP server completely, or the SUBMIT server 
is passed the credentials from the IMAP server.

As for your question as to which is better, an IMAP proxy or an SMTP 
proxy. Both are evil and fiendishly difficult to get right.  However, 
having written both, an SMTP proxy is much simpler than an IMAP proxy.

Finally, your comment about being required to use VPN or SSL/TLS to send 
mail from the IETF is what I'm talking about.  For people like me, this is 
nothing new.  For a few years now, I can not submit without authenticating 
to the SUBMIT server first, and unless I have Kerberos credentials I can't 
authenticate to the SUBMIT server without negotiating TLS with it first.

We still have a path in which clients from "good IP addresses" are allowed 
to submit without authentication.  That path periodically causes our 
outgoing mailers (which are different from the SUBMIT servers) to get 
listed in various RBLs.  Thanks to virus authors and spammers, 
non-authenticated submission from "trusted" addresses is on its way out.

-- Mark --

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 3 Mar 2004 09:19:42 -0500 (EST)

On Tue, 2 Mar 2004, Vaudreuil, Greg M (Greg) wrote:

> the user is already authenticated.  The IMAP server can pass the message
> onto any ordinary outbound SMTP relay.  Whether an implementor choses to
> separate these roles for some reason is irrelevant to the protocol
> standard.

-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?