Subject: [lemonade] Time to Stand up and be counted

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 10 Feb 2004 09:11:21 -0600

I'd like to see all who have a stake to clearly express their views and a few lines supporting their position.  A collection of such positions will help determine if we have an emerging consensus or not.

I now strongly favor a IMAP PUSH model.

1) It can be implemented using an IMAP submission proxy in front of any current IMAP server.  This reduces the barrier to entry for early deployments. 

2) It simplifies the engineering of a secure submission service.  I don't need a separate DMZ-resident submission service with access to users credentials as SMTP-Submit now requires.  (I can proxy IMAP without access to passwords to a store in a more secure zone, while I can't do that easily with SMTP-submit)  One less hole in the firewall, one less avenue for attack.

3) It saves a network connection for the SMTP-submit, a number of round-trips, and at least some bandwidth.  While this may be of marginal benefit in well connected environments, I find faster and cheaper to be compelling on today's wireless data networks.  (Also 1/3 fewer new connections / flows to manage on firewalls and load-balancers also saves $$)

4) It seems overall simpler in avoiding the hard work of getting a third-party trust model right. It also avoids an obvious race condition and simplifies the logic for doing a reliable, coordinated delete from the "outbox".  This benefit is especially evident in the likely case where the submission server and IMAP store are provided by different vendors.

5) It seems easier to add in other lemonade-charter items such as future delivery with revocation.  In the case of future delivery the long-term queues and associated message data are in a single place, usually subject to regular backups.  I view the PUSH model as sharing state between submission queues on the SMTP-Submit server and content in the IMAP store, creating conditions where the two may easily get out-of-sync.  Also, submission servers don't typically store long-term persistent data and are rarely backed-up. Storing long-term future-delivery queues will require adding backup to that system as well as requiring higher availability hardware.

I see both proposals as equally capable of being extended over time to support richer composition capabilities, for good or bad.

Other views?

Greg V.

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

---

From: Chris Newman <[email-masked]>
Date: Wed, 11 Feb 2004 17:11:46 -0800

Vaudreuil, Greg M (Greg) wrote on 2/10/04 9:11 -0600:
> 1) It can be implemented using an IMAP submission proxy in front of any
> current IMAP server.  This reduces the barrier to entry for early
> deployments. 

Most of these proxies will have fundamental design errors.  About 95% of the
protocol-level interoperability problems in SMTP are caused by SMTP proxies,
and that's exactly what you're proposing to write only much more complex.  This
will not interoperate well so I do not consider this a compelling argument for
push.

One of my responsibilities at work is to maintain an IMAP/POP/SMTP proxy.  It
consumes about 50% of my time.  We regularly find new bugs and the original
author of the code was an above average engineer (top 20%).  The proxies I
maintain go into a pure pass-through mode after authentication so they are much
simpler than the proxy you're proposing to write.

> 2) It simplifies the engineering of a secure submission service.  I don't
> need a separate DMZ-resident submission service with access to users
> credentials as SMTP-Submit now requires.  (I can proxy IMAP without access to
> passwords to a store in a more secure zone, while I can't do that easily with
> SMTP-submit)  One less hole in the firewall, one less avenue for attack.

This is a valid point.  However, it applies only to a narrow subset of mail
deployments.  Most real-world deployments require SMTP AUTH to audit spamming
from local users and thus already have the submit server in the DMZ.  The one
I'm using right now requires SSL/TLS and SMTP AUTH.

> 3) It saves a network connection for the SMTP-submit, a number of
> round-trips, and at least some bandwidth.  While this may be of marginal
> benefit in well connected environments, I find faster and cheaper to be
> compelling on today's wireless data networks.  (Also 1/3 fewer new
> connections / flows to manage on firewalls and load-balancers also saves $$)

Valid point.

> 4) It seems overall simpler in avoiding the hard work of getting a
> third-party trust model right. It also avoids an obvious race condition and
> simplifies the logic for doing a reliable, coordinated delete from the
> "outbox".  This benefit is especially evident in the likely case where the
> submission server and IMAP store are provided by different vendors.

Yes, it _seems_ simpler.  But I've thought through the code I'd have to write
for push vs. pull on both client and server, and pull is significantly simpler
in practice.  Pull is a bit harder for the client implementer, but push is _a
lot_ harder for the server implementer.

> 5) It seems easier to add in other lemonade-charter items such as future
> delivery with revocation.  In the case of future delivery the long-term
> queues and associated message data are in a single place, usually subject to
> regular backups.  I view the PUSH model as sharing state between submission
> queues on the SMTP-Submit server and content in the IMAP store, creating
> conditions where the two may easily get out-of-sync.  Also, submission
> servers don't typically store long-term persistent data and are rarely
> backed-up. Storing long-term future-delivery queues will require adding
> backup to that system as well as requiring higher availability hardware.

When you lose functional separation, it is simpler to implement boundary
features because you don't have to worry about functional separation any
longer.  But these problems can be solved while preserving functional
separation and the benefits will outweigh the costs.

If we dropped the distinction between TCP and IP, then HIP would be much easier
to implement.

                - Chris

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 12 Feb 2004 12:41:31 -0500 (EST)

> will not interoperate well so I do not consider this a compelling argument for

I agree -- implementing a stateful IMAP proxy is a non-trivial amount of
work, and even then is likely to have problems coping with the wide
variety of different extensions that different backend servers implement
of.

> If we dropped the distinction between TCP and IP, then HIP would be much easier

I think the functional separation argument is still the key, and is why I
prefer the pull method.  Both from an architectural standpoint *and* from
the standpoint that IMAP is not the end-all-be-all of message retrieval
protocols.

It is very difficult for me to accept a proposal that throws out a
longstanding separation of functionality just because it is perceived to
be easier.

Regardless of charter limitations, we cannot ignore the fact that IMAP is
not the only message retrieval protocol and we should at least acknowledge
that fact in our design.  We definitely don't want to find out that we
need to add SUBMIT to POP in a few years.  I don't want to find out in 10
years that we've added SUBMIT to POP, NNTP, IMAP, and HTTP for whatever
various reasons.

Take the example of SASL -- despite being *designed* as a protocol that
could be integrated in other protocols, there are a significant number of
subtle difference in each application protocol that cause easily (and
often) overlooked subtle problems in implementation.  This is for a
protocol that is *simple* compared to SUBMIT, and is *designed* to be
integrated into other protocols.

I don't welcome an era of a large number of subtlety different SUBMIT
mechanisms.

In the long run, the right answer here is to keep SUBMIT on the submission
server.

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

---

From: Rick Block <[email-masked]>
Date: Fri, 13 Feb 2004 16:01:57 -0700

> I'd like to see all who have a stake to clearly express their views and a few lines supporting their position.  A collection of such positions will help determine if we have an emerging consensus o…

I could likely live with either approach, although favor "pull" for
many of the same reasons recently expressed ("push" seems to entangle
current and future submit extensions; "pull" seems more generally
useful).  A couple of specific examples (the server I work on supports
both IMAP and SMTP; it's primarily a "voicemail" server):

1) Future delivery is a voicemail concept which we've implemented
in SMTP, per Greg's very own I-D.  It's not obvious to me how we'd
mirror this in the "push" model.

2) The imap reference part of "pull" will lead to a mechanism
allowing a piece of a message to be (reasonably) securely
referenced in another protocol (SMTP for the discussion at
hand).  We have need to allow a full desktop GUI (not what you'd
normally consider a "bandwidth limited" device) the ability to
direct a networked server to "play" a voice message on the
phone (using, at this point, a proprietary protocol).  The very
same solution used to allow a submit server to "pull" content
from an imap server can be used in this situation to allow the
voice server to pull the content to be played on the phone
(avoiding requiring the client to download the content from
imap and then upload it to the voice server, sound familiar?).

Pull seems simpler to me and solutions to its issues seem to
apply to other problems as well.

-Rick Block

---

From: Mark Crispin <[email-masked]>
Date: Fri, 13 Feb 2004 15:34:54 -0800 (Pacific Standard Time)

On Fri, 13 Feb 2004, Rick Block wrote:
> The very

Hi Rick -

Indeed, one of my considerations was to see if it would be possible to 
make you voicemail guys happy as a side effect.  A marriage of URLAUTH and 
CHANNEL is not out of the question either (although they're currently not 
dating, they look like a hot couple just waiting to be introduced...).

If there are any obvious ways to make URLAUTH friendlier to voicemail, 
please let me know.  It'd be great to get you folks on board.

-- Mark --

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