Subject: RE: [lemonade] Life on the List, and Vienna

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Sun, 8 Jun 2003 20:10:06 -0500

I (with Greg White) plan to have a revised future delivery submission draft, reflecting the agreed upon changes at the last IETF...  No IMAP outbox, keep within SMTP-submit framework, other edits.

Are there other comments before we post a new version?

Greg V.

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]]
Sent: Sunday, June 08, 2003 5:03 PM
To: Eric Burger
Cc: IETF LEMONADE (E-mail)
Subject: Re: [lemonade] Life on the List, and Vienna

Eric,

EB> Now that things are moving again, do we want to meet in Vienna?

EB> I would envision more of a working session than a presentation
EB> session.  E.g., sharpen your pencils, styli, and notebooks.

The question is what we will discuss.  So we should simply offer items
to discuss (and, yes, discuss, not present.)

I'll be in Vienna.  Don't have items to suggest at the moment.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

_______________________________________________
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: Sun, 8 Jun 2003 18:44:04 -0700 (PDT)

On Sun, 8 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> I (with Greg White) plan to have a revised future delivery submission
> draft, reflecting the agreed upon changes at the last IETF...  No IMAP
> outbox, keep within SMTP-submit framework, other edits.

I think that a successful IMAP-aware delivery-submission mechanism will
have the following characteristics:

1) Keep IMAP and POP out of the MTA and MSA business.

2) Allow the submitted message to reference data available upon multiple
   IMAP or POP servers.

3) Not depend upon having unlimited access to the user's IMAP or POP data.

The people who argued at the last IETF for an IMAP outbox focused on
action item (3) -- which I agree is important -- but chose to disregard
(1) (in spite of this principle appearing in both the IMAP and POP RFCs)
and completely failed to consider (2).

It is very tempting to "just have an outbox in IMAP" that, being the IMAP
server, can grab all the needed data as local disk access.  However,
besides being a red flag for IMAP implementors, it ignores existing server
facilities in which the user's data isn't on a single IMAP server.

I recommend a mechanism which I brought up briefly (albeit was shouted
down due to a misunderstanding of what I was going to say) at the last
IETF:
	We need a mechanism (ala IMAP URL) which, when presented
	to an IMAP server, would deliver a particular data item
	from a particular mailbox owned by a particular user
	*without* providing access to any other data in the
	mailbox.

This mechanism would be used by the submission server (which some of us
want to be a different machine from the IMAP servers!) to obtain the data
from the IMAP server.

A possible mechanism is via SASL.  Details of how such a mechanism would
work, what security mechanisms it would have, etc. to be filled in (e.g.
by experts such as Chris Newman, who may already be working on this).

The amount of effort to do this is no more than the effort to do an outbox
in IMAP; and I suspect that it would be substantially less.

-- 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: [email-masked]
Date: Mon, 9 Jun 2003 12:33:11 -0700 (PDT)

> want to be a different machine from the IMAP servers!) to obtain the data
The above mechanism would work, however it would be quite complicated still.

The particular problem is that its quite often not the entire email you 
want to forward but only part of it and that can be very much inside your 
own reply email with one part of original email, followed by reply text, 
followed by another part, etc. etc.  

This gets very complicated if we do it by URL:
 1. We have to allow for email on IMAP server to be broken into multiple 
    small parts and store each part with special security settings (only 
    for submit server use). These parts have to be deleted after submission.
 2. We have to allow submit server to not only add particular headers but 
    create new body for the email - i.e. it takes part of the text sent to 
    it, looks at particular references to other parts of the text adds it 
    all up and creates new mime body. Not an easy process to describe - I 
    see inventions of new MIME types, like "Partial-email-text" (what if  
    its not a text???) and "Partial-email-imap-reference-url". And then 
    submit server has to deal with cases of content-type being different
    in original email (at IMAP server) and new parts being sent to it.

In the end I think it would be better (and possibly even less complicated?)
to allow editing of email within IMAP itself, so that there is entire 
email body already ready for submission.  After this it does not matter if 
submit process is called by end-user and refernces this already-made body
(and actual headers are added by submit) or if IMAP calls submit process 
itself.

And having email created entirely within IMAP framework does have its
advantages in the practical use as it would not be necessary to create 
such a complicated authorization system and since in real-world right now 
firewalls often do not filter IMAP but they do filter SMTP and SMTP-submit.

---
William Leibzon
Elan Communications Inc. 
[email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Mon, 9 Jun 2003 15:25:55 -0700 (Pacific Daylight Time)

> followed by another part, etc. etc.

IMAP already solves this.  It has partial message operations.

>     for submit server use). These parts have to be deleted after submission.

Since IMAP has partial message operations, there is no need to do this
breaking or subsequent deletion.  The capability is already there.

> such a complicated authorization system

But you would have to create an extremely complicated editing system.
Editing is more complicated than authorization.

> and since in real-world right now

As soon as spammers work out how to spam with IMAP, you can be confident
that we'll start seeing blocking of IMAP ports too.

-- Mark --

---

From: Doug Royer <[email-masked]>
Date: Mon, 09 Jun 2003 16:55:11 -0600

Mark Crispin wrote:

> ....

True. My experience shows me that most SPAM comes from open relays.
IMAP submissions would be already authenticated and could be signed
in some simple or complex way on their way out.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Randall Gellens <[email-masked]>
Date: Mon, 9 Jun 2003 23:19:39 -0400

At 12:33 PM -0700 6/9/03, [email-masked] wrote:

>  in real-world right now

Firewalls filter inbound or outbound SMTP and Submit?  Filtering 
inbound SMTP blocks all external access to the SMTP server, which 
makes it impossible for anyone outside to send you mail.  Filtering 
inbound Submit serves only to block access to the submit server by 
authorized persons wishing to submit mail from outside (assuming the 
submit server requires authentication for all transactions, as is 
recommended).  Filtering outbound SMTP prevents your users from 
spamming; this may or may not be useful, depending on how much 
control you have over your users.  Filtering outbound Submit doesn't 
make sense, since Submit servers should require authentication and 
thus aren't generally useful for spamming.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Democracy is a form of government in which it is permitted to wonder
aloud what the country could do under first-class management.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade