Subject: Re: MS vs. pop and imap
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Cc: Dave Crocker <[email-masked]>, Cyrus Daboo <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Date: Mon, 31 May 2004 16:32:13 -0500
List-Id: <ietf-smtp.imc.org>

On 5/31/2004 11:59 AM, [email-masked] wrote:

>> 2. HTTP is not used to deliver, post or even transfer mail, as a 
>> semantic object.
> 
> I hate to have to disagree again, but it most certainly has been used
> this way. For example, it is entirely possible to push MUA
> functionality into the web browser using, say, Java, and then transfer
> messages as semantic objects to and from the browser using HTTP.

See also http://www.thecodeproject.com/csharp/httpmail.asp. Before saying
that this stuff doesn't count because it's non-standard, remember that so
is STDIN and /usr/lib/sendmail.

Having said that, balancing filters (such as /-dav.*\.hotmail\.com$/ in
this example) also prove useful given the relative immaturity of these
interfaces and the speed with which they have been exploited.

> MUAs may also provide local mailbox storage and it is perfectly
> reasonable for messages to be delivered to such storage directly. But
> an MUA that provides local message storage is not a message store, for
> two reasons: (1) It doesn't provide remote access and (2) It doesn't
> support multiple users.

The specs don't dictate anything to do with storage formats or how the
mail should be read. Any mechanisms for accessing mail (including reading
it via local filesystem directly) is equal. We might have feelings and
ideas about what we think are real mailstores or not but I can't think of
any separators that survive for long.

The mbox folders on the sparc workstation in my lab are created by way of
LMTP over UNIX-domain sockets, and there's only one set of folders in the
filesystem-based mailstore. The mbox folders on the windows laptop are
created by way of IMAP and support multiple users via profiles. Which one
is more serious? The sparc runs SMTP and IMAP daemons, but that's all got
to do with protocols not the mailstore.

I'd say that when a message reaches the storage where it is acted upon by
the authorized agent (where disposition notifications are generated, for
example), then it has reached a legitimate mailstore.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: Dave Crocker <[email-masked]>
Cc: "Eric A. Hall" <[email-masked]>, [email-masked]
Subject: Re: Internet Mail Architecture draft 
From: [email-masked]
Date: Mon, 31 May 2004 15:58:38 -0400
Sender: [email-masked]

--==_Exmh_1341538828P
Content-Type: text/plain; charset=us-ascii

On Sat, 29 May 2004 07:28:58 PDT, Dave Crocker said:

> Would it be valid to have an email transmission client that bounced
> messages after the first transmission failure (of any kind)?  If it is
> legal but no one can possibly envision that it is a viable choice for an
> implementation, then retries are probably a core aspect of the service.

It's been envisioned as being viable for at least some subset of usages,
although in the context of a ESMTP extension. RFC2852, section 4.1.4.1 is
pretty clear that if you're attempting to relay a Deliver-By: mail with a very
small deliver-by delta, and that if the server at the other end advertises a
larger minimum value, you have to bounce as a permanent error, even if it's
the first attempt.  

--==_Exmh_1341538828P
Content-Type: application/pgp-signature

--==_Exmh_1341538828P--

Date: Mon, 31 May 2004 14:30:30 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

One elaboration on the comments Ned made (with which I agree):

--On Monday, May 31, 2004 09:59:27 AM -0700 [email-masked] wrote:

>> Your diagram implies scenarios such as delivering into the MS by imap
>> and then having the MUA access the MUA by pop. Do we really want to
>> imply that?
>
> It is not all that uncommon for IMAP append to be used to deliver
> messages to a store. For example, suppose you have an MTA that performs
> final delivery using LMTP and you want to use it with an IMAP server that
> doesn't support LMTP delivery. The obvious thing to do is write an LMTP
> server that stuffs messages into the IMAP server using APPEND.

Its worth noting that many message stores provide both POP and IMAP access 
simultaneously, so its quite possible to have message delivery into the 
store via IMAP APPEND and MUAs using POP (or IMAP) to read the messages.

-- 
Cyrus Daboo

Date: Mon, 31 May 2004 09:59:27 -0700 (PDT)
From: [email-masked]
Subject: Re: MS vs. pop and imap
To: Dave Crocker <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Virus-test: FALSE
Sender: [email-masked]

> Cyrus,

> CD>            |        MTA
> CD>            |         |
> CD>            |         |  smtp, lmtp
> CD>            |         |
> CD>            |    +-- MDA   <-------------------------+
> CD>            |    |    |                              |
> CD>            |    |    |  smtp, imap, (local)         |
> CD>            |    |    |                              |
> CD>            |  smtp   MS                           sieve
> CD>            |    |    |                              |
> CD>            |    |    |  imap, pop, http, (local)    |
> CD>            |    |    |                              |
> CD>            |    +--->+                              |
> CD>            |         |                              |
> CD>            |         |                              |
> CD>            +------> MUA recipient (rMUA) -----------+

> Your diagram implies scenarios such as delivering into the MS by imap
> and then having the MUA access the MUA by pop. Do we really want to
> imply that?

It is not all that uncommon for IMAP append to be used to deliver messages to a
store. For example, suppose you have an MTA that performs final delivery using
LMTP and you want to use it with an IMAP server that doesn't support LMTP
delivery. The obvious thing to do is write an LMTP server that stuffs messages
into the IMAP server using APPEND.

> We need to get clear about the difference between an MTA-related
> transfer of responsibility, versus an action with the MUA of moving a
> message from one folder to another. In the former, the message is held
> in something that is a queue. It's difficult to imagine any utility in
> modeling a folder as a queue.

Nobody is talking about moving messages between folders here.

> CD> - some clients 'pull' messages into their local store via smtp and ETRN,
> CD> bypassing the message store.

There's also ATRN.

> For the scenario you describe, what is the difference between a Message
> Store and an MTA's queue? It suggests that "delivery" is bypassing the
> MS. I don't know what it means to bypass the MS.

You're still thinking of the MS as some kind of adjunct to the MUA. It isn't.
It is a separate piece of functionality, consisting of a collection
of mailboxes and some means to access them remotely.

MUAs may also provide local mailbox storage and it is perfectly reasonable for
messages to be delivered to such storage directly. But an MUA that provides
local message storage is not a message store, for two reasons: (1) It doesn't
provide remote access and (2) It doesn't support multiple users.

> Where does the message
> go? Onto the MUA's screen?

I don't know that I've ever seen a MUA that does "screen delivery", but  I have
most certainly seen specialized MUAs that print the mail they receive.

> CD> - I'm afraid we cannot ignore webmail, so note the addition of http as an
> MS->>MUA access protocol. I guess http should appear for the sender MUA ->
> CD> MSA step in which case the MSA is actually a webserver.

> 2. HTTP is not used to deliver, post or even transfer mail, as a
> semantic object.

I hate to have to disagree again, but it most certainly has been used this way.
For example, it is entirely possible to push MUA functionality into the web
browser using, say, Java, and then transfer messages as semantic objects to and
from the browser using HTTP. Basically what you're using is downloading the MUA
and running it in the browser. And since browsers prefer HTTP, well, there you
go.

Mind you, I'm not saying this is a good idea. Experience has shown that it
isn't. The generally sad state of interoperability in the browser world makes
this approach fairly problematic in anything but the most homogeneous
environments. Additionally, inferring SMTP envelope information from what's in
the header (something these things sometimes do to implement message
submission) has its own set of issues. But this has been done. Has it been done
often enough for us to describe it as part of our architecture? I simply don't
have the data to say. (I generally try and stay as far away from webmail
schemes as possible.)

> It is used as a front-end exchange protocol between an
> application and the user interface (the display functions.) It has no
> semantics for the data being transferred. So the use of http is really
> within a split MUA. (Hmmm. Maybe that's the elaboration that will help,
> showing a cross-net split MUA sometimes and not others?)

This is indeed the most popular way it is done. But not the only way.

> In other words, http is a presentation-layer exchange protocol, not an
> email protocol.

In most cases, yes. But not all.

				Ned

Date: Mon, 31 May 2004 09:37:55 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Cyrus Daboo <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

Cyrus,

CD>            |        MTA
CD>            |         |
CD>            |         |  smtp, lmtp
CD>            |         |
CD>            |    +-- MDA   <-------------------------+
CD>            |    |    |                              |
CD>            |    |    |  smtp, imap, (local)         |
CD>            |    |    |                              |
CD>            |  smtp   MS                           sieve
CD>            |    |    |                              |
CD>            |    |    |  imap, pop, http, (local)    |
CD>            |    |    |                              |
CD>            |    +--->+                              |
CD>            |         |                              |
CD>            |         |                              |
CD>            +------> MUA recipient (rMUA) -----------+

Your diagram implies scenarios such as delivering into the MS by imap
and then having the MUA access the MUA by pop. Do we really want to
imply that?

We need to get clear about the difference between an MTA-related
transfer of responsibility, versus an action with the MUA of moving a
message from one folder to another. In the former, the message is held
in something that is a queue. It's difficult to imagine any utility in
modeling a folder as a queue.

CD> - some clients 'pull' messages into their local store via smtp and ETRN,
CD> bypassing the message store.

For the scenario you describe, what is the difference between a Message
Store and an MTA's queue? It suggests that "delivery" is bypassing the
MS. I don't know what it means to bypass the MS. Where does the message
go? Onto the MUA's screen?

CD> - I'm afraid we cannot ignore webmail, so note the addition of http as an 
MS->>MUA access protocol. I guess http should appear for the sender MUA -> 
CD> MSA step in which case the MSA is actually a webserver.

2. HTTP is not used to deliver, post or even transfer mail, as a
semantic object. It is used as a front-end exchange protocol between an
application and the user interface (the display functions.) It has no
semantics for the data being transferred. So the use of http is really
within a split MUA. (Hmmm. Maybe that's the elaboration that will help,
showing a cross-net split MUA sometimes and not others?)

In other words, http is a presentation-layer exchange protocol, not an
email protocol.

So it is really more like telnet than smtp, pop or imap.

webmail is an important data point in an array of marketing
distinctions, but I do not see how it warrants reference in an
architecture discussion.

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>

Date: Mon, 31 May 2004 08:33:09 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: MS vs. pop and imap (alternate response)
Sender: [email-masked]

Pete,

An elaboration on the second diagram occurs to me, with some
clarification of the terminology:

>>2. How do we model the components and downstream interactions of srv2 and pc2:
>>
>>        |
>>   +---MTA----+
>>   |          |
>>   | messages |
>>   |          |
>>   +----------+
>>        |
>>   +--<srv1>--+
>>   |          |
>>   | messages |
>>   |          |
>>   +----------+
>>        |
>>   +--<pc1>---+
>>   |          |
>>   | messages |
>>   |          |
>>   +----------+
>>
>>Messages are retained on pc1 and not on srv1.

The difference between "moving" a message versus copying, of course, is
that a message is retained in its original location when there is
copying, and not retained with there is moving.  Hence, MTA-MTA
transfers involve moving.

So, the difference between the diagram that showed the pc as having no
<messages> versus the one that shows it as having them is about
long-term retention after a move. When PC1 is shown with no <messages>
it means that it does take over responsibility for the message.

And the reason for elaborating the MTA depiction is to raise the
question about the distinction between the MTA and srv1.  When pc1 takes
over responsibility for a message, as a result of a moving it to the
pc1, what is the difference between MTA's holding messages and srv1's
holding messages?  Both are used for queuing, and both hand off
responsibility to the next machine in the sequence.

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>

From: "Hector Santos" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, <[email-masked]>
Subject: Re: MS vs. pop and imap (alternate response)
Date: Mon, 31 May 2004 00:41:27 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, May 30, 2004 1:36 PM
Subject: Re: MS vs. pop and imap (alternate response)

> 1. How do we model the components and downstream interactions of srv1
> and pc1:
> ...
>
>   pc1 does not retain any messages. Repeated readings of the same
>   message require repeated retrievals from srv1.
>
> 2. How do we model the components and downstream interactions of srv2
> and pc2:
>
> ....
>
>   Messages are retained on pc1 and not on srv1.

Dave, this (both designs) is a very fundamental issue with our system.  I
can only speak on how we do it.  Can it be modeled generically?   Maybe, but
I think the issue is that the mail policies or the expectations of the
clients may not be honored.  This is important today especially in the era
of legitation and corporate mail retaintion policies

First, again, strong mail policies can not be voilated by clients.  So #2
would be a foriegn or "loose" server design by my standards.

However, from the MUA standpoint, it looks like a "Deletion" or physical
transfer of storage location.

The following goes back to the days where older traditional "access" did not
have offer "preview" or "delete" mail options.  (As a side note, keep in
mind these end-user "features" can have a major effect on the server mail
maintenance.   This is a major consideration.)

So for our system we have options such as:

      "[X] Mark Downloaded Mail as Received"
      "[X] Allow Mail Previewing (for non-POP3 clients)"
      "[X] Allow Mail Deletion"

What this does is basically define how the #1 and #2 behind, especially how
the PC1 "Repeated Reading" of the same mail is "emulated"

Lets forget the server side for the moment and thing purely MUA, such as
POP3:

PC1 with "[X] Leave Mail On Server" options
              Number of Days ___
              [X] When Deleted

      MTA
       |
       |
     MESSAGES
       |
       |
    PC1 LISTNEW
        DNLDNEW
        KILLOLD (based on MUA "Leave Mail On Server" Options)

PC1 with "[_] Leave Mail On Server"

      MTA
       |
       |
     MESSAGES
       |
       |
    PC1 LISTNEW
        DNLDNEW
        KILLOLD

Also keep in mind that MUAs like Outlook will have a F1 help on the "Leave
Mail On Server" options that says basically the options may not be honored.

But as we discovered, the market pressure is quite certainly there to
support the "roaming user" concept who want to read their mail from vacation
or remote job sites via web mail or their LapTop POP3 client but do not want
to loose the downloading at the home based PC.   So an preverledged option
of "mail snooping" had to be allowed without losing mail auditing, tracking,
signaling capabilities on the server.  The last thing we wanted was to have
a system sent "Subscription Expiration Payment Notices" and then the "mail
snooping" allowed the user to bypass any indication that the mail was
actually received.

So with Model #1 and #2, it all depends on how the above server options are
set.

What this means is that the LISTNEW command may list trully new mail along
with mail already downloaded but not marked received.  We call this the
user's "Direct Mail Chain"   If the server allows for mail snooping,  then
download mail is not removed from the chain.

What this means is that the DNLDNEW command may or may not mark the
message received

and finally, what this means is th KILLOLD command may or may not delete the
message. It
might mark the message received.

This might be a implementation issue, but what it all basically means (in my
view) is that the LISTNEW may not be honored.

In the eyes of the MUA, when it does a LISTNEW,  the list of ids it sees is
for its own management. It determines what is actually new and from the list
of ids that are not already recorded, it sends the DNLDNEW command.   But if
the server is going to disallow mail previewing/snooping, etc, the LISTNEW
will only have unread new mail ids - which is not what roaming users want.

I hope this make some sense and not too much of a specific design, but I
think it is generic design consideration with any high-end mail server that
has strong mail policies and more important, multiple access methods, not
just POP3 like systems.     If a system does not want any mail previewing
whatsoever, the last thing the admin wants to control this via Console, GUI,
clients, only to be bypassed by POP3.

Also, keep in mind, may not be important, but in POP3, it has the UPDATE
process.  This is very important and it basically means that server side
mail markings can only be done when the QUIT command is issued.   So if PC1
download a message and ungracefully aborts or does not issue the QUIT
command, the server will not record the download.

Date: Sun, 30 May 2004 15:43:04 -0500
To: Cyrus Daboo <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: MS vs. pop and imap (alternate response)
Cc: Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/30/04 at 2:48 PM -0400, Cyrus Daboo wrote:

>--On Sunday, May 30, 2004 01:06:12 PM -0500 Pete Resnick 
><[email-masked]> wrote:
>
>>>pc1 does not retain any messages. Repeated readings of the same 
>>>message require repeated retrievals from srv1.
>>
>>This would make for an amazingly stupid POP client, a somewhat 
>>stupid IMAP client, and a use of a local access client that would 
>>piss-off some sys admins.
>
>No! There is a well defined usage case for this: kiosk clients that 
>do not leave messages behind in a local cache. This is vital for any 
>public access email stations.

Even for kiosk clients, having temporary local storage (memory or 
disk) for repeated readings of the same message during a single 
session I would think is pretty common. I suppose there are 
situations where you would not have enough local storage to even do 
that, but I would stand by my claim that such a client wouldn't be 
terribly intelligent: You don't want to have to re-parse the MIME 
every time a user re-opens a message. Perhaps that's what's done in 
some cases, but it doesn't seem like the best way to implement it.

In no case was I saying that kiosk mode was stupid.

>There is a third option: messages kept on both server and client 
>with synchronisation.

Again, I would claim that architecturally, this is identical to the 
other two: The message is delivered into the Message Store, at which 
point the UA accesses and manipulates that store, either with a 
protocol like POP or IMAP, or directly like /bin/mail. The details of 
the manipulations, and the richness of the interactions, are all part 
of the UA/MS interaction.

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

Date: Sun, 30 May 2004 14:09:11 -0500
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
CC: Pete Resnick <[email-masked]>, [email-masked], Chris Newman <[email-masked]>, [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

On 5/30/2004 8:20 AM, [email-masked] wrote:

>>> POP really does finally delivery,
> 
> No, it really does no such thing. Final delivery is a well defined
> action that takes place before POP comes into the picture.

"Final delivery" is "well defined" within the context of SMTP (it occurs
when the last public transfer takes place, where no more Received headers
will be written, where the Return-Path is written, and so forth, [except
when it doesn't (*)]). SMTP only provides the "public-transport" function
for the global network of mailboxes and its terms and meanings have to be
restricted to its area of relevance.

In the context of global end-to-end messaging infrastructure, final
delivery occurs when the message reaches the storage where it will be
accessed by the recipient. This is obviously different from the last-hop
SMTP server when things like Exchange, DECmail, AOL, or other "gateway"
systems where SMTP's idea of "final destination" visibly differs from the
destination's idea of final destination. This is also somewhat obvious
with things like fetchmail that use POP to redistributed and file messages
locally. Even LMTP transfers into a local store on the same box is
different since LTMP is for private transfers (*). Another point of order
here is that SMTP and the associated specifications DO NOT SPECIFY STORAGE
FORMATS so as far as that goes, every permanent-storage end-point is via
some kind of gateway, and which is precisely why the scope of SMTP (and
its definition of "final delivery") has to be limited to the public
transfer portion of the network and treated as irrelevant otherwise.

(*) I note that the Cyrus IMAP server acts like it's part of the actual
SMTP network; it will write its own Recieved and Return-Path headers even
though it is not part of the SMTP network (it doesn't have an SMTP
listener on port 25, and LMTP on port 24 is definitely not SMTP, so...).
Sieve redirects in Cyrus redirect incoming mail without rewriting the
sender envelope, instead of generating new messages like one would expect
from a post-delivery expansion. So even where there is a pretty clear
architecture once it is divided into functional groups, exceptions exist.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Sun, 30 May 2004 14:48:26 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: Re: MS vs. pop and imap (alternate response)
Sender: [email-masked]

Hi Pete,

--On Sunday, May 30, 2004 01:06:12 PM -0500 Pete Resnick 
<[email-masked]> wrote:

>> 1. How do we model the components and downstream interactions of srv1
>> and pc1:
>>
>>        |
>>       MTA
>>        |
>>   +--<srv1>--+
>>   |          |
>>   | messages |
>>   |          |
>>   +----------+
>>        |
>>       <pc1>
>>
>> pc1 does not retain any messages. Repeated readings of the same
>> message require repeated retrievals from srv1.
>
> srv1 - MDA
> messages - MS
> pc1 - MUA
> line between MTA and srv1 - SMTP
> line between messages and pc1 - POP or IMAP or local access
>
> This would make for an amazingly stupid POP client, a somewhat stupid
> IMAP client, and a use of a local access client that would piss-off some
> sys admins.

No! There is a well defined usage case for this: kiosk clients that do not 
leave messages behind in a local cache. This is vital for any public access 
email stations. Often people just get by with webmail in such cases but 
there is no reason why a full blown desktop client can't offer the same and 
thus provide the richer desktop GUI interaction with email over the limited 
GUI a browser can provide.

>> 2. How do we model the components and downstream interactions of srv2
>> and pc2:
>>
>>        |
>>       MTA
>>        |
>>   +--<srv1>--+
>>   |          |
>>   | messages |
>>   |          |
>>   +----------+
>>        |
>>   +--<pc1>---+
>>   |          |
>>   | messages |
>>   |          |
>>   +----------+
>>
>> Messages are retained on pc1 and not on srv1.
>
> srv1 - MDA
> messages under srv1 - MS
> pc1 - MUA
> messages under pc1 - MUA's local cache of messages (same for /bin/mail
> messages in ~/Mail, POP client's mailboxes, or IMAP client's cached data)
> line between MTA and srv1 - SMTP
> line between messages and pc1 - POP or IMAP or local access
>
> These two implementations/configurations are not architecturally
> different.

There is a third option: messages kept on both server and client with 
synchronisation.

In fact this is what I call the 'three modes of IMAP':

Online mode: client has no local cache of data, always re-fetches messages 
from the server. This effectively implements kiosk mode.

Offline mode: client does 'pop-over-imap' and pulls all messages down to 
the client cache and deletes from the server. Whilst that is a viable use 
of IMAP, its a pretty pointless one, and I don't know of any clients that 
actually behave that way.

Disconnected mode: client maintains a cache of messages that are on the 
server and synchronizes changes between the two. The client may really be 
in a situation where it connects/disconnects from the network, or it may be 
connected but uses the local cache to speed up the 'online mode' where 
local caching is allowed.

-- 
Cyrus Daboo

Date: Sun, 30 May 2004 13:06:12 -0500
To: Dave Crocker <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: MS vs. pop and imap (alternate response)
Cc: [email-masked]
Sender: [email-masked]

On 5/30/04 at 10:36 AM -0700, Dave Crocker wrote:

>1. How do we model the components and downstream interactions of srv1 and pc1:
>
>        |
>       MTA
>        |
>   +--<srv1>--+
>   |          |
>   | messages |
>   |          |
>   +----------+
>        |
>       <pc1>
>
>pc1 does not retain any messages. Repeated readings of the same 
>message require repeated retrievals from srv1.

srv1 - MDA
messages - MS
pc1 - MUA
line between MTA and srv1 - SMTP
line between messages and pc1 - POP or IMAP or local access

This would make for an amazingly stupid POP client, a somewhat stupid 
IMAP client, and a use of a local access client that would piss-off 
some sys admins.

>2. How do we model the components and downstream interactions of srv2 and pc2:
>
>        |
>       MTA
>        |
>   +--<srv1>--+
>   |          |
>   | messages |
>   |          |
>   +----------+
>        |
>   +--<pc1>---+
>   |          |
>   | messages |
>   |          |
>   +----------+
>
>Messages are retained on pc1 and not on srv1.

srv1 - MDA
messages under srv1 - MS
pc1 - MUA
messages under pc1 - MUA's local cache of messages (same for 
/bin/mail messages in ~/Mail, POP client's mailboxes, or IMAP 
client's cached data)
line between MTA and srv1 - SMTP
line between messages and pc1 - POP or IMAP or local access

These two implementations/configurations are not architecturally different.

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

Date: Sun, 30 May 2004 10:12:39 -0700 (PDT)
From: [email-masked]
Subject: Re: MS vs. pop and imap
To: Dave Crocker <[email-masked]>
Cc: [email-masked], Pete Resnick <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Virus-test: FALSE
Sender: [email-masked]

> > No, it really does no such thing. Final delivery is a well defined action that
> > takes place before POP comes into the picture.

> As I said, that is the current view, yes.  However it is not the
> original view of its role.

While the historical role may be interesting in an academic sense, I have to
say I don't regard it as particularly relevant to the current exercise, which
is to document the current architecture, not one that's lost in the mists of
time, assuming it ever existed at all.

> The very first POP specifications used the word "access", so that would
> seem to support the position that delivery is pre-POP. However those
> documents did not really talk about email models and no one was trying
> to be so precise with the model and terminology, back then.

Even if I were to grant that ancient POP specifications are relevant (I don't),
they do not in fact support the reading you claim. For example, the
introduction to RFC 918 states:

  The intent of the Post Office Protocol (POP) is to allow a user's workstation
  to access mail from a mailbox server. It is expected that mail will be posted
  from the workstation to the mailbox server via the Simple Mail Transfer
  Protocol (SMTP). For further information see RFC-821 [1] and RFC-822 [2].

To be sure, the word "access" is used here, but in the context of "access to a
mailbox server". Not "access to a delivery agent", "access to a message queue",
or anything similar. And the term "delivery" was in use at the time - it
appears throughout RFC 821, of course.

> Worse, the model did not have the concept of a message store, as an
> independent component, so it was difficult to talk about this point.

A mailbox server along with a collection of mailboxes is pretty darned close
IMO. So the concept in some form dates back to at least 1984 in the RFC series.

> A
> module was either a UA or an MTA. Posting and Delivering were the
> actions between them.

The word "deliver" does not appear in RFC 918. You'd think that if POP was
intended to be a delivery process the word would have come up at least once.

> In any event, POP was definitely for _moving_ messages from the server
> to the client.

Not exclusively it isn't. Again, if it were the option to leave mail on the
server would not exist. Instead there would be some form of transactional
handoff and there would be no need for unique identifers so clients
can tell what messages they have downloaded.

> Note that the current spec observes the change/addition
> of retention on the server:

> rfc1939> 8. Scaling and Operational Considerations
> rfc1939>
> rfc1939>    Since some of the optional features described above were added to the
> rfc1939>    POP3 protocol, experience has accumulated in using them in large-
> rfc1939>    scale commercial post office operations where most of the users are
> rfc1939>    unrelated to each other.  In these situations and others, users and
> rfc1939>    vendors of POP3 clients have discovered that the combination of using
> rfc1939>    the UIDL command and not issuing the DELE command can provide a weak
> rfc1939>    version of the "maildrop as semi-permanent repository" functionality

The optional features weren't added to make things like leaving mail on the
server possible. The fact of the matter is that these  things were being done
basically from the get-go. The problem is that without UIDL it can only be done
badly. UIDL makes it possible to do leave mail on server "well".

> As for the question of "delivery" versus "access" in the sense that we
> mean it today, going back to by RFC1081 (1988):

> rfc1081> Introduction
> rfc1081>
> rfc1081>    On certain types of smaller nodes in the Internet it is often
> rfc1081>    impractical to maintain a message transport system (MTS).  For
> rfc1081>    example, a workstation may not have sufficient resources (cycles,
> rfc1081>    disk space) in order to permit a SMTP server and associated local
> rfc1081>    mail delivery system to be kept resident and continuously running.
> rfc1081>    Similarly, it may be expensive (or impossible) to keep a personal
> rfc1081>    computer interconnected to an IP-style network for long amounts of
> rfc1081>    time (the node is lacking the resource known as "connectivity").
> rfc1081>
> rfc1081>    Despite this, it is often very useful to be able to manage mail on
> rfc1081>    these smaller nodes, and they often support a user agent (UA) to aid
> rfc1081>    the tasks of mail handling.

Nothing here says or even implies that POP is going to take over the task of
performing final delivery.

> and

> rfc1081> The POP and the Split-UA model
> rfc1081>
> rfc1081>    The underlying paradigm in which the POP3 functions is that of a
> rfc1081>    split-UA model.  The POP3 client host, being a remote PC based
> rfc1081>    workstation, acts solely as a client to the message transport system.
> rfc1081>    It does not provide delivery/authentication services to others.

> That last line is the only place we get a statement that has a statement
> involving the model as precisely as we are using it now.

See above. There are statements as far back as RFC 918 that describe something
quite close to the current model.

> > Which is why all the original work on so-called "timely delivery" in the FAX WG
> > never panned out.

> First of all, folks seem to be missing my distinction between POP's
> original intent versus current usage.

On the contrary, I see the distinction you're attempting to make. I just don't
buy it and even if I did buy it I don't think it is particularly relevant. The
intent of POP was explicitly stated almost 20 years ago to access mailboxes on
a mailbox server. And most of the implementations of POP since then have been
one of a server that sits on top of a bunch of mailboxes - exactly what
RFC 918 talked about and one form of the things we now call "message
stores".

> And the reference to the fax work is both ironic and wrong.  First, the
> fax effort underscored the problem with having the DSN mechanism stop
> before POP and the need to have POP more capable in the role of
> effecting delivery.

I never said it wasn't a problem. However, it is a problem precisely because
POP wasn't designed for the use the fax folks wanted to put it to, and it is
much harder than it first appears to change it.

In any case, I believe the diagram Cyrus proposed is pretty much on target.

				Ned

Date: Sun, 30 May 2004 10:36:55 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: MS vs. pop and imap (alternate response)
Sender: [email-masked]

Folks,

DC> That said, it seems worth pursuing a bit further.

Oh, the benefits of futher, shower-based cogitation...

It occurs to me that this might be one of those times that are helped by
talking implementation and configuration details, rather than being
distracted by them.

1. How do we model the components and downstream interactions of srv1
and pc1:

       |
      MTA
       |
  +--<srv1>--+
  |          |
  | messages |
  |          |
  +----------+
       |
      <pc1>

  pc1 does not retain any messages. Repeated readings of the same
  message require repeated retrievals from srv1.

2. How do we model the components and downstream interactions of srv2
and pc2:

       |
      MTA
       |
  +--<srv1>--+
  |          |
  | messages |
  |          |
  +----------+
       |
  +--<pc1>---+
  |          |
  | messages |
  |          |
  +----------+

  Messages are retained on pc1 and not on srv1.

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>

Date: Sun, 30 May 2004 12:32:49 -0500
To: Dave Crocker <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: MS vs. pop and imap
Cc: [email-masked], Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/30/04 at 9:50 AM -0700, Dave Crocker wrote:

>>Final delivery is a well defined action that takes place before POP 
>>comes into the picture.
>
>As I said, that is the current view, yes.  However it is not the 
>original view of its role.

I don't buy it, and none of the text you've pointed to indicates it.

>The very first POP specifications used the word "access", so that 
>would seem to support the position that delivery is pre-POP.

Right.

>Worse, the model did not have the concept of a message store, as an 
>independent component, so it was difficult to talk about this point. 
>A module was either a UA or an MTA. Posting and Delivering were the 
>actions between them.

No. I disagree completely. Think about the UA's pre-POP. Things like 
/bin/mail and ELM. They acted on the MS to read messages, delete 
messages from the store, move messages to different places, and reply 
to messages. Remember, all messages were delivered to a single MS (at 
the time, "the spool") where a UA could manipulate those messages. 
They had no part of delivery to that spool. (Posting is different; 
more on that later.)

>In any event, POP was definitely for _moving_ messages from the 
>server to the client.

Sort of, but not precise enough for the point: POP was for moving 
messages from the machine where the MS lived to a UA which, for the 
first time, was on a different machine. Using "client" and "server" 
clouds the issue here. They are a "POP client" and a "POP server", 
but they were not "mail transport servers".

>Note that the current spec observes the change/addition of retention 
>on the server:

I don't see anything in that quote from 1939 sec. 8 that supports 
your point. POP back to 1081 always had the DELE command. The only 
operational change the quote points out is that, unlike traditional 
UAs like /bin/mail, where users usually got things out of the mail 
spool and put them into private disk space, people started using POP 
to leave lots of stuff in the mail spool as permanent storage. That 
doesn't change the MS as separate from UA model.

>As for the question of "delivery" versus "access" in the sense that 
>we mean it today, going back to by RFC1081 (1988):
>
>rfc1081> Introduction
>rfc1081>
>rfc1081>    On certain types of smaller nodes in the Internet it is often
>rfc1081>    impractical to maintain a message transport system (MTS).  For
>rfc1081>    example, a workstation may not have sufficient resources (cycles,
>rfc1081>    disk space) in order to permit a SMTP server and associated local
>rfc1081>    mail delivery system to be kept resident and continuously running.
>rfc1081>    Similarly, it may be expensive (or impossible) to keep a personal
>rfc1081>    computer interconnected to an IP-style network for long amounts of
>rfc1081>    time (the node is lacking the resource known as "connectivity").
>rfc1081>
>rfc1081>    Despite this, it is often very useful to be able to manage mail on
>rfc1081>    these smaller nodes, and they often support a user agent 
>(UA) to aid
>rfc1081>    the tasks of mail handling.

Of course, you skip the key next sentence:

    To solve this problem, a node which can
    support an MTS entity offers a maildrop service to these less endowed
    nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
    permit a workstation to dynamically access a maildrop on a server
    host in a useful fashion.

A "maildrop service" *is* the MS. Old UAs used to access the MS 
directly and that POP is provide distant UAs the ability to access 
the MS remotely. That model is completely apparent in 1081.

>...folks seem to be missing my distinction between POP's original 
>intent versus current usage.

Not at all. Speaking for myself, I think you're just mistaken about 
original intent. See above quote from 1081. I agree that the model at 
that time wasn't precise, but if "maildrop service" doesn't mean the 
same thing as "Message Store" in the way we've been talking about it, 
I don't know what else it could mean.

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

Date: Sun, 30 May 2004 09:50:32 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
CC: Pete Resnick <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

Ned.

Preface: My goal for this sort of exchange is to have a community
consensus for precise language and usage. The lack of this is what
motivated the architecture document. So I'm happy to occupy my familiar
position, holding a minority-of-one view, since I don't see anyone else
sharing it.

That said, it seems worth pursuing a bit further.

>> > POP really does finally delivery,
nfmc> No, it really does no such thing. Final delivery is a well defined action that
nfmc> takes place before POP comes into the picture.

As I said, that is the current view, yes.  However it is not the
original view of its role.

The very first POP specifications used the word "access", so that would
seem to support the position that delivery is pre-POP. However those
documents did not really talk about email models and no one was trying
to be so precise with the model and terminology, back then.

Worse, the model did not have the concept of a message store, as an
independent component, so it was difficult to talk about this point. A
module was either a UA or an MTA. Posting and Delivering were the
actions between them.

In any event, POP was definitely for _moving_ messages from the server
to the client. Note that the current spec observes the change/addition
of retention on the server:

rfc1939> 8. Scaling and Operational Considerations
rfc1939>
rfc1939>    Since some of the optional features described above were added to the
rfc1939>    POP3 protocol, experience has accumulated in using them in large-
rfc1939>    scale commercial post office operations where most of the users are
rfc1939>    unrelated to each other.  In these situations and others, users and
rfc1939>    vendors of POP3 clients have discovered that the combination of using
rfc1939>    the UIDL command and not issuing the DELE command can provide a weak
rfc1939>    version of the "maildrop as semi-permanent repository" functionality

As for the question of "delivery" versus "access" in the sense that we
mean it today, going back to by RFC1081 (1988):

rfc1081> Introduction
rfc1081>
rfc1081>    On certain types of smaller nodes in the Internet it is often
rfc1081>    impractical to maintain a message transport system (MTS).  For
rfc1081>    example, a workstation may not have sufficient resources (cycles,
rfc1081>    disk space) in order to permit a SMTP server and associated local
rfc1081>    mail delivery system to be kept resident and continuously running.
rfc1081>    Similarly, it may be expensive (or impossible) to keep a personal
rfc1081>    computer interconnected to an IP-style network for long amounts of
rfc1081>    time (the node is lacking the resource known as "connectivity").
rfc1081>
rfc1081>    Despite this, it is often very useful to be able to manage mail on
rfc1081>    these smaller nodes, and they often support a user agent (UA) to aid
rfc1081>    the tasks of mail handling.

and

rfc1081> The POP and the Split-UA model
rfc1081>
rfc1081>    The underlying paradigm in which the POP3 functions is that of a
rfc1081>    split-UA model.  The POP3 client host, being a remote PC based
rfc1081>    workstation, acts solely as a client to the message transport system.
rfc1081>    It does not provide delivery/authentication services to others.

That last line is the only place we get a statement that has a statement
involving the model as precisely as we are using it now.

>> > "moving" messages from upstream to
>> > downstream -- to choose some neutral terms. By contrast, IMAP does
>> > "copying" from upstream to downstream. That is, POP changes where
>> > the message actually resides. It is eliminated from the upstream.
nfmc> Not necessarily. POP can be used in a variety of ways,

I said that in my original note.

>> Not convinced? Consider: If the distance between the MDA and the MS
>> (e.g., in the case of SMTP) can't be traversed (due to a disk full
>> situation, for instance), a DSN is returned to the sender.
>> ...   Neither POP nor IMAP have such responsibilities. They aren't
>> part of that bit of the architecture.
nfmc> Which is why all the original work on so-called "timely delivery" in the FAX WG
nfmc> never panned out.

First of all, folks seem to be missing my distinction between POP's
original intent versus current usage.

And the reference to the fax work is both ironic and wrong.  First, the
fax effort underscored the problem with having the DSN mechanism stop
before POP and the need to have POP more capable in the role of
effecting delivery.

Second, the reason I stopped trying to specify timely delivery was that
the entire Internet Mail service model has no such concept and the only
way to retrofit it was increasingly looking like it needed to create a
real-time, end-to-end link.

In any event, this thread was started with the hope of getting
convergence on the diagram. Comments about choices and preferences for
it would be helpful.

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>

Date: Sun, 30 May 2004 06:20:23 -0700 (PDT)
From: [email-masked]
Subject: Re: MS vs. pop and imap
To: Pete Resnick <[email-masked]>
Cc: [email-masked], Chris Newman <[email-masked]>, [email-masked]
Virus-test: FALSE
Sender: [email-masked]

> > > The architecture needs a "Message Store" piece.  The MDA delivers
> > > messages into the message store, while POP/IMAP transfer messages
> > > from the message store to the rMUA.

> > This looks like it needs to be discussed a bit. I think that reality
> > is a bit different than you describe.

> > Here's why:

> > POP really does finally delivery,

No, it really does no such thing. Final delivery is a well defined action that
takes place before POP comes into the picture.

> > "moving" messages from upstream to
> > downstream -- to choose some neutral terms. By contrast, IMAP does
> > "copying" from upstream to downstream. That is, POP changes where
> > the message actually resides. It is eliminated from the upstream.

Not necessarily. POP can be used in a variety of ways, and leave mail
on server modes are quite popular in practice.

> > As
> > a core construct, IMAP leaves the message on the upstream host and
> > simply provides a copy to the MUA.

> I don't buy your distinction at all and don't believe it is part of
> the architecture.

I agree. It may seen odd that POP in particular operates after final
delivery, but that's the way it is.

> POP and IMAP are protocols that pull mail out of
> the MS and bring them to an MUA. Both POP and IMAP have commands to
> get the contents of the message from the MS. Both POP and IMAP have
> commands to delete the message from the MS. And the getting and
> deleting are separate commands. They manipulate the MS for the MUA.
> They are in the same functional layer.

Yep.

> Not convinced? Consider: If the distance between the MDA and the MS
> (e.g., in the case of SMTP) can't be traversed (due to a disk full
> situation, for instance), a DSN is returned to the sender. If the
> distance between the MS and IMAP can't be traversed, that's not
> information that is sent back. POP is exactly analogous to IMAP in
> that situation: The distance between POP and its previous hop (which
> I claim is the MS) is a local matter and failure (or success) is not
> part of the transport reporting scheme. The MDA is the agent
> responsible for taking the message out of the transport system and
> bringing it into the MS for the user. It therefore has
> responsibilities to report back to the transport system success or
> failure. Neither POP nor IMAP have such responsibilities. They aren't
> part of that bit of the architecture.

Which is why all the original work on so-called "timely delivery" in the FAX WG
never panned out. Originally this was a (misnamed) attempt to extend ESMTP
DELIVERBY semantics past the point of final delivery to cover POP and IMAP
activities. It ran afoul of the architectural issue that POP and IMAP actions
don't consist of a single, well defined transactin, which makes it impossible
to know when the message has been "delivered". And there was also the
implementation issue that Message Stores don't have queues and queue timeouts. 

> > Each protocol can do some/all of the functions of the other.  But
> > each has the primary job I've described.  I think that that should
> > be depicted differentially.

> Nope. Disagree completely.

I agree with Pete.

				Ned

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "Chris Newman" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: MS vs. pop and imap
Date: Sun, 30 May 2004 05:39:50 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Chris Newman" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, May 29, 2004 2:32 PM
Subject: MS vs. pop and imap

> Here's why:
>
> POP really does finally delivery, "moving" messages from upstream to
> downstream -- to choose some neutral terms. By contrast, IMAP does
> "copying" from upstream to downstream. That is, POP changes where the
> message actually resides. It is eliminated from the upstream. As a core
> construct, IMAP leaves the message on the upstream host and simply
> provides a copy to the MUA.

This is not true in general Dave.  POP3/IMAP are just mechanisms and System
Mail Policies can not be altered by POP3/IMAP or in general client commands.
This is discussed in the POP3 RFC and most POP3 clients (like Outlook)
provide on-line help telling the user that their POP3 "Leave Mail On Server"
download options may not be honored.  See POP3 RFC 1939  "8. Scaling and
Operational Considerations"

In fact, POP3 has violated many traditional hosting systems where "Mail
Previewing" was secured or a priverledged access (i.e, Sysops only).   Mail
previewing is now pretty much requirement in order to offer POP3 vs HTML
roaming users access to reread the same mail from multiple sites.  It
altered our secured design where mail marking, auditing and tracking was a
security requirement.  I.e, Admin sends a "Payment Notice" and the user now
says he need saw it because he was able to preview it without marking it as
read or bypassing the return receipt trigger.  POP3 allows for this behavior
and hosting systems need to take that into account.

> .... strikes me as too much about implementation and not enough about
> architecture.
>
> Thoughts?

You're trying to "map"  (excuse the pun) access methods to backends.   Some
system, such as our system, has the following different "access" methods:

- Text Mode (Dialup/Telnet) Mail Access
- Web Mail Client Access
- Windows GUI Frontend Mail Access
- QWK, RIME, Offline Mail Systems
- Peer To Peer Mail Distribution (Fidonet)
- POP3 Client Access
- News Client Access
- WEB Service Mail API
- or 3rd party native language mail API access

etc.  So whether its POP3 or IMAP or what have you,  regardless of how the
mail is accessed, it can not violate the security of the backend.  No client
can "Preview" or "Delete" the mail unless the admin provides the security
for it.

In my view, they all provide "copies" to the MUA and only if the MUA says to
delete the mail, does it make an attempt, and whether it works or not
depends on the backend.  For example, the POP3 delete command can actually
translate to a server function of marking the mail as "Received" instead.

Of course, you can have a backend with a mail storage designed with POP3
100% in mind, having the POP3 client control every aspect of the
maintenance.  But in general, your client design is based on what the server
provides.  POP3 and IMAP are just 2 or many ways backend servers offer mail
access.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Sat, 29 May 2004 19:49:16 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

Hi Dave,

--On Saturday, May 29, 2004 11:32:29 AM -0700 Dave Crocker 
<[email-masked]> wrote:

> Here's an attempt:
>
>            |        MTA
>            |         |  smtp, lmtp
>            |        MDA   <-------------------------+
>            |         |  smtp, pop, (local)          |
>            |         MS                           sieve
>            |         |  imap, (local)               |
>            |         |                              |
>            +------> MUA recipient (rMUA) -----------+

I think the following would be better (given comments by others with which 
I mostly agree):

           |        MTA
           |         |
           |         |  smtp, lmtp
           |         |
           |    +-- MDA   <-------------------------+
           |    |    |                              |
           |    |    |  smtp, imap, (local)         |
           |    |    |                              |
           |  smtp   MS                           sieve
           |    |    |                              |
           |    |    |  imap, pop, http, (local)    |
           |    |    |                              |
           |    +--->+                              |
           |         |                              |
           |         |                              |
           +------> MUA recipient (rMUA) -----------+

Some things to note:

- imap can be used to deliver messages into the message store (the MDA -> 
MS step) since it has the APPEND command. Indeed a number of tightly 
integrated systems have the MDA doing imap appends linked with the sieve 
fileinto command to store messages into specific mailboxes beyond just the 
inbox. pop cannot be used in the same way as there is no equivalent to the 
append command.

- some clients 'pull' messages into their local store via smtp and ETRN, 
bypassing the message store. This is not very common but I do know of 
several ISPs that behave that way.

- I'm afraid we cannot ignore webmail, so note the addition of http as an 
MS->MUA access protocol. I guess http should appear for the sender MUA -> 
MSA step in which case the MSA is actually a webserver.

-- 
Cyrus Daboo

Date: Sat, 29 May 2004 17:48:08 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: MS vs. pop and imap
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/29/04 at 11:32 AM -0700, Dave Crocker wrote:

>>The architecture needs a "Message Store" piece.  The MDA delivers 
>>messages into the message store, while POP/IMAP transfer messages 
>>from the message store to the rMUA.
>
>This looks like it needs to be discussed a bit. I think that reality 
>is a bit different than you describe.
>
>Here's why:
>
>POP really does finally delivery, "moving" messages from upstream to 
>downstream -- to choose some neutral terms. By contrast, IMAP does 
>"copying" from upstream to downstream. That is, POP changes where 
>the message actually resides. It is eliminated from the upstream. As 
>a core construct, IMAP leaves the message on the upstream host and 
>simply provides a copy to the MUA.

I don't buy your distinction at all and don't believe it is part of 
the architecture. POP and IMAP are protocols that pull mail out of 
the MS and bring them to an MUA. Both POP and IMAP have commands to 
get the contents of the message from the MS. Both POP and IMAP have 
commands to delete the message from the MS. And the getting and 
deleting are separate commands. They manipulate the MS for the MUA. 
They are in the same functional layer.

Not convinced? Consider: If the distance between the MDA and the MS 
(e.g., in the case of SMTP) can't be traversed (due to a disk full 
situation, for instance), a DSN is returned to the sender. If the 
distance between the MS and IMAP can't be traversed, that's not 
information that is sent back. POP is exactly analogous to IMAP in 
that situation: The distance between POP and its previous hop (which 
I claim is the MS) is a local matter and failure (or success) is not 
part of the transport reporting scheme. The MDA is the agent 
responsible for taking the message out of the transport system and 
bringing it into the MS for the user. It therefore has 
responsibilities to report back to the transport system success or 
failure. Neither POP nor IMAP have such responsibilities. They aren't 
part of that bit of the architecture.

>Each protocol can do some/all of the functions of the other.  But 
>each has the primary job I've described.  I think that that should 
>be depicted differentially.

Nope. Disagree completely.

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

Date: Sat, 29 May 2004 16:39:55 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dave Crocker <[email-masked]>
CC: [email-masked]
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

On 5/29/2004 4:25 PM, Dave Crocker wrote:

> EAH> 4xx means something completely different at:
> 
> Well, the 4yz response code model is actually the only reason I think
> queuing _might_ be in the architecture.

5xx has the same sort of input.

  user(@domain(mx(A)))
   ^           ^  ^
   |           |  |
   |           |  try next host in MX set
   |           |
   |           try next-best MX
   |
   give up entirely

4xx is worse because of things like disk space causing requeuing

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Sat, 29 May 2004 14:25:57 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: "Eric A. Hall" <[email-masked]>
CC: [email-masked]
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

Eric,

EAH> On 5/29/2004 9:28 AM, Dave Crocker wrote:

>> Certainly the role of independent mta-based routing needs to be cited.
>> 
>> I'm not so sure that re-queuing does. I think of email's queuing as a 
>> (popular) local implementation issue.

EAH> 4xx means something completely different at:

Well, the 4yz response code model is actually the only reason I think
queuing _might_ be in the architecture.

EAH> The peculiarities are dictated in the specs accordingly. More to my point
EAH> however, is that the [re-]queuing algorithms in the specs also gives
EAH> instructions on what to do in each of those cases.

Well...

2821>       4.2.1 Reply Code Severities and Theory
 ...
2821>       ... but the SMTP
2821>       client is encouraged to try again.  A rule of thumb to determine

and

2821>    4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
2821>    When an SMTP server returns a positive completion status (2yz code)
2821>    after the DATA command is completed with <CRLF>.<CRLF>, it accepts
2821>    responsibility for:
...
2821>    -  if attempts to deliver the message fail due to transient
2821>       conditions, retrying delivery some reasonable number of times at
2821>       intervals as specified in section 4.5.4.

are examples of the directives given in the specification. By any
reasonable measure of protocol specification, they are pretty darn weak.

Still, the text "...an SMTP server... it accepts responsibility for...
retrying delivery" would seem, to me, to eliminate any question.  It is
an explicit statement that retrying is part of the model.

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>

Date: Sat, 29 May 2004 15:52:46 -0500
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

On 5/29/2004 1:32 PM, Dave Crocker wrote:

> strikes me as too much about implementation and not enough about
> architecture.

try it with functions instead of agents

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Sat, 29 May 2004 15:50:50 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dave Crocker <[email-masked]>
CC: [email-masked]
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

On 5/29/2004 9:28 AM, Dave Crocker wrote:

> Certainly the role of independent mta-based routing needs to be cited.
> 
> I'm not so sure that re-queuing does. I think of email's queuing as a 
> (popular) local implementation issue.

4xx means something completely different at:

  greeting banner
  helo response
  mail from
  rcpt to
  end-of-data

The peculiarities are dictated in the specs accordingly. More to my point
however, is that the [re-]queuing algorithms in the specs also gives
instructions on what to do in each of those cases. So no, I don't think
the queue-management stuff is local whim or intepretation at all.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Sat, 29 May 2004 11:32:29 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: MS vs. pop and imap
Sender: [email-masked]

Chris,

CN> The architecture needs a "Message Store" piece.  The MDA delivers messages into
CN> the message store, while POP/IMAP transfer messages from the message store to
CN> the rMUA.

This looks like it needs to be discussed a bit. I think that reality is
a bit different than you describe.

Here's why:

POP really does finally delivery, "moving" messages from upstream to
downstream -- to choose some neutral terms. By contrast, IMAP does
"copying" from upstream to downstream. That is, POP changes where the
message actually resides. It is eliminated from the upstream. As a core
construct, IMAP leaves the message on the upstream host and simply
provides a copy to the MUA.

Each protocol can do some/all of the functions of the other.  But each
has the primary job I've described.  I think that that should be
depicted differentially.

Here's an attempt:

           |        MTA
           |         |  smtp, lmtp
           |        MDA   <-------------------------+
           |         |  smtp, pop, (local)          |
           |         MS                           sieve
           |         |  imap, (local)               |
           |         |                              |
           +------> MUA recipient (rMUA) -----------+

This might suggest that one could use pop to do final delivery and then
imap for access, but I think that showing more differential components
and "paths" in the architecture slide would be worse.

That is:

           |        MTA
           |         |  smtp, lmtp
           |        MDA   <------------------------------+
           |         |                                   |
           |         +---------------------+           sieve
           |         |  smtp               |  pop        |
           |         MS                    MS            |
           |         |  imap, (local)      |  (local)    |
           |         |                     |             |
           |         +---------------------+             |
           |         |                                   |
           +------> MUA recipient (rMUA) ----------------+

strikes me as too much about implementation and not enough about
architecture.

Thoughts?

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>

Date: Sat, 29 May 2004 11:42:34 -0400
From: Cyrus Daboo <[email-masked]>
To: Dave Crocker <[email-masked]>, Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

Hi Dave,

--On Saturday, May 29, 2004 07:14:30 AM -0700 Dave Crocker 
<[email-masked]> wrote:

> On the other hand, I have no sense of the actual adoption and use of
> Sieve.  It's been around awhile but I haven't been running into it in
> clients or servers.

There are several sieve client and server implementations around, and a 
number of sites, ISPs etc that are using it. We have a list of some of 
these on our sieve info page:

<http://www.cyrusoft.com/sieve>

-- 
Cyrus Daboo

Date: Sat, 29 May 2004 07:28:58 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: "Eric A. Hall" <[email-masked]>
CC: [email-masked]
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

Eric,

EAH> | End-to-end Internet mail exchange is accomplished by using a
EAH> | standardized infrastructure comprising:

EAH> Two additional core functions are routing and [re-]queuing algorithms,

As with Chris' note, I think yours extends the doc... but in a good way.

Certainly the role of independent mta-based routing needs to be cited.

I'm not so sure that re-queuing does. I think of email's queuing as a
(popular) local implementation issue. (However, as Graham Klyne persists
in noting, email's persistence across system outages is in marked
contrast with instant messaging's lack of it. And this permits very
different implementation choices.)

Let's explore this a bit: The formal service has the concept of
transient problems. This implies later retries by the client SMTP. But
it is not required and the specs specify remarkably little about this.

Would it be valid to have an email transmission client that bounced
messages after the first transmission failure (of any kind)?  If it is
legal but no one can possibly envision that it is a viable choice for an
implementation, then retries are probably a core aspect of the service.

EAH> | 3  Email System Architecture

EAH> I disagree with the use of this terminology for the purpose of describing
EAH> the global network of mailboxes; the "agent" model stopped being useful
EAH> for most environments by 1990, and it is far better to talk about the

You appear to want to invent an entirely new architecture reference
model.  That might be a fine exercise to pursue, but it's not a goal of
this document.

EAH> The principle reason for talking about functions instead of node-types is
EAH> that modern agents often incorporate functions that are not reflected by
EAH> historical classifications. For example, it's not unheard of for a
EAH> first-hop "MUA" to make routing and queuing decisions based on the
EAH> destination address, at which point it is no longer a simple MUA, but
EAH> instead is an MUA (presentation) with a local MSA (queuing) and MTA
EAH> (routing and transfer).

You would be making an interesting point, were it not for the NOTE at
the beginning of Section 3.

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>

Date: Sat, 29 May 2004 07:14:30 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

Chris,

CN> In section 3.1.3/3.1.4 you should mention LMTP (RFC 2033) as a protocol often
CN> used between an MTA and MDA.

My original thought was simply to list some popular exemplars, to
help explain the function being described. But things seem to have
grown. Now, I guess the rule for the doc should be to cite any ietf
standards-track protocol that performs the role being listed.

CN> The architecture needs a "Message Store" piece.  The MDA delivers messages into
CN> the message store, while POP/IMAP transfer messages from the message store to
CN> the rMUA.

yeah, i guess so. (for some reason I hadn't wanted to add it, but now
that seems silly.  thanks for citing it.)

CN> You also need to reference Sieve (RFC 3028) which is the standard language the
CN> IETF has to describe the operation of the MDA (it can also be used by the
CN> rMUA).

Interesting suggestion.  I had thought to focus on transfer protocols
(except for the end2end object description (2822... ooops. better add
MIME.).  So, what the heck, I guess the spirit of completeness calls for
adding it.

On the other hand, I have no sense of the actual adoption and use of
Sieve.  It's been around awhile but I haven't been running into it in
clients or servers.

CN>   procmail is also frequently used to control the MDA.

Ummm... Non-standard.  Not a protocol. Not ietf. Platform-specific...

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>

Date: Tue, 18 May 2004 04:36:42 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

On 5/15/2004 3:36 AM, Dave Crocker wrote:

> <http://brandenburg.com/specifications/draft-crocker-mail-arch-00.htm>

| End-to-end Internet mail exchange is accomplished by using a
| standardized infrastructure comprising:

Two additional core functions are routing and [re-]queuing algorithms,
both of which are central towards determining whether or not the
end-to-end exchange works (that's why they are specified in the core).
They are also frequently replaced with 'optimized' algorithms that are
better suited to specific environments.

| The <mailto:[email-masked]> list also is pertinent
| <http://www.imc.org/ietf-smtp/index.html>
                           ^^^^
                    should be '822'

| 3  Email System Architecture

I disagree with the use of this terminology for the purpose of describing
the global network of mailboxes; the "agent" model stopped being useful
for most environments by 1990, and it is far better to talk about the
various functions which can (and are) used by any node on the network to
affect end-to-end transfer.

The collection of independent, replacable functions are:

  addressing -- the public rules only define the public destination

  first-hop submission -- transfer protos [smtp, submit], retrieval
    protos [pop3 extensions, imap extensions], file-system queues,
    APIs [/usr/lib/sendmail], and many other mechanisms. this is the
    richest area.

  routing -- public [dns] and private [nis/ldap, static maps, etc]

  push-transfer -- smtp, lmtp, gateway [DECmail, AOL],... Dare I say
    that UUCP is making a comeback in some circles.

  last-hop delivery -- lmtp sometimes, usually its a private
    interface to a locally preferred mail-store database format.
    this is actually the least-defined of all the functions.

  pull-transfer (aka retrieval) -- just because the message is
    loitering in somebody's account spopol doesn't mean it has
    reached the final destination. pop, imap, atrn, etrn, etc.
    usually another delivery function here too.

The principle reason for talking about functions instead of node-types is
that modern agents often incorporate functions that are not reflected by
historical classifications. For example, it's not unheard of for a
first-hop "MUA" to make routing and queuing decisions based on the
destination address, at which point it is no longer a simple MUA, but
instead is an MUA (presentation) with a local MSA (queuing) and MTA
(routing and transfer). The historical terminology just doesn't cut it
anymore I'm afraid.

The remainder followed the agent model and thus I skipped it.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Mon, 17 May 2004 15:53:15 -0700
From: Chris Newman <[email-masked]>
Subject: Re: Internet Mail Architecture draft
To: Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

I skimmed the beginning of the draft.

Section 2.2:
  > A name usually maps to an IP Address.
should be:
  > A name usually maps to one or more IP addresses.

In section 3.1.3/3.1.4 you should mention LMTP (RFC 2033) as a protocol often
used between an MTA and MDA.  It's particularly useful because it eliminates
the need for a message queue on the MDA which reduces the administrative cost
and improves the scalability of an Internet messaging system.

The architecture needs a "Message Store" piece.  The MDA delivers messages into
the message store, while POP/IMAP transfer messages from the message store to
the rMUA.

You also need to reference Sieve (RFC 3028) which is the standard language the
IETF has to describe the operation of the MDA (it can also be used by the
rMUA).  procmail is also frequently used to control the MDA.

                - Chris

Dave Crocker wrote on 5/15/04 1:36 -0700:

> 
> Folks,
> 
> I've just sent draft-crocker-mail-arch-00 to be issued as an
> internet-draft.
> 
> In the interim, it is available at:
> 
>   <http://brandenburg.com/specifications/draft-crocker-mail-arch-00.htm>
> and
>   <http://brandenburg.com/specifications/draft-crocker-mail-arch-00.txt>
> 
> The document summarizes Internet Mail architectural components, their
> relationships, and the identities they use.
> 
> The draft recommends that discussion about the draft take place on the
> SMTP mailing list.
> 
> So I have only BCC'd the MARID and LEMONADE mailing lists, to let folks
> there know about the draft. But it really will be better to have
> discussion take place in only one venue.
> 
> d/
> ----- 
>  Dave Crocker <mailto:[email-masked]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA USA <tel: +1.408.246.8253>; <fax: +1.408.850.1850>
> 

Date: Mon, 17 May 2004 11:21:03 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Paul Overell <[email-masked]>
CC: [email-masked]
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

Paul,

>>              |       MTA
>>              |        |      < smtp
>>              |       MDA
>>              |        |      < pop, imap

PO> Perhaps unusual, but there are cases where SMTP is used for the final
PO> hop to the rMUA, e.g. the ISP Demon in the UK offer SMTP delivery.

       indeed.  once upon a time, it was the only way to do delivery.
       now we get to re-invent "push" delivery with yet-another
       mechanism.

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>

To: [email-masked]
Subject: Fw: http://brandenburg.com/specifications/draft-crocker-mail-arch-00.htm
From: Ed Bradford <[email-masked]>
Date: Mon, 17 May 2004 11:27:38 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 0054ECEE85256E97_=
Content-Type: text/plain; charset="US-ASCII"

An excellent writeup. I have two early thoughts. 

       1. Fix the links in the document from "e://". I can't seem to get 
any of them working. 

       2. Summarize the oMUA, rMUA, MSA, MTA, MDA actions as to who fills 
them in and who 
       reads them in a table. Include the "may" and "must" directives in 
the table. 

Ed Bradford 
http://egb.userv.ibm.com
T/L 444-4955; Outside: 1-919-254-4955 FAX 919-486-0574
[email-masked] 

--=_alternative 0054ECEE85256E97_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">An excellent writeup. I have two early
thoughts.</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
 &nbsp; &nbsp; &nbsp; 1. Fix the links in the document from &quot;e://&quot;.
I can't seem to get any of them working.</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
 &nbsp; &nbsp; &nbsp; 2. Summarize the oMUA, rMUA, MSA, MTA, MDA actions
as to who fills them in and who</font><font size=3> </font><font size=2 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; reads them in a table. Include the &quot;may&quot;
and &quot;must&quot; directives in the table.</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
Ed Bradford</font><font size=3> </font><font size=2 face="sans-serif"><br>
http://egb.userv.ibm.com<br>
T/L 444-4955; Outside: 1-919-254-4955 FAX 919-486-0574<br>
[email-masked]</font><font size=3> </font>
<br>
--=_alternative 0054ECEE85256E97_=--

Date: Mon, 17 May 2004 09:42:43 +0100
To: [email-masked]
From: Paul Overell <[email-masked]>
Reply-To: Paul Overell <[email-masked]>
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

This is a PGP signed message sent according to RFC3156 [PGP/MIME]

--=_Turnpike_OcfCx6DCsHqA5LZ3=
Content-Type: text/plain;charset=us-ascii;format=flowed
Content-Transfer-Encoding: quoted-printable

In message <[email-masked]>, Dave Crocker=20
<[email-masked]> writes
>
>Folks,
>
>I've just sent draft-crocker-mail-arch-00 to be issued as an
>internet-draft.
>
>In the interim, it is available at:
>
>  <http://brandenburg.com/specifications/draft-crocker-mail-arch-00.htm>
>and
>  <http://brandenburg.com/specifications/draft-crocker-mail-arch-00.txt>
>
>The document summarizes Internet Mail architectural components, their
>relationships, and the identities they use.
>

>3.  Email System Architecture

>              |        .
>              |        |
>              |       MTA
>              |        |      < smtp
>              |       MTA
>              |        |      < smtp
>              |       MDA
>              |        |      < pop, imap

Perhaps unusual, but there are cases where SMTP is used for the final=20
hop to the rMUA, e.g. the ISP Demon in the UK offer SMTP delivery.

>              |        |
>              +------ MUA recipient (rMUA)

Regards
--=20
Paul Overell         Internet Platform Development Manager, Thus plc

--=_Turnpike_OcfCx6DCsHqA5LZ3=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc

--=_Turnpike_OcfCx6DCsHqA5LZ3=--

Date: Mon, 17 May 2004 09:42:43 +0100
To: [email-masked]
From: Paul Overell <[email-masked]>
Reply-To: Paul Overell <[email-masked]>
Subject: Re: Internet Mail Architecture draft
Sender: [email-masked]

This is a PGP signed message sent according to RFC3156 [PGP/MIME]

--=_Turnpike_OcfCx6DCsHqA5LZ3=
Content-Type: text/plain;charset=us-ascii;format=flowed
Content-Transfer-Encoding: quoted-printable

In message <[email-masked]>, Dave Crocker=20
<[email-masked]> writes
>
>Folks,
>
>I've just sent draft-crocker-mail-arch-00 to be issued as an
>internet-draft.
>
>In the interim, it is available at:
>
>  <http://brandenburg.com/specifications/draft-crocker-mail-arch-00.htm>
>and
>  <http://brandenburg.com/specifications/draft-crocker-mail-arch-00.txt>
>
>The document summarizes Internet Mail architectural components, their
>relationships, and the identities they use.
>

>3.  Email System Architecture

>              |        .
>              |        |
>              |       MTA
>              |        |      < smtp
>              |       MTA
>              |        |      < smtp
>              |       MDA
>              |        |      < pop, imap

Perhaps unusual, but there are cases where SMTP is used for the final=20
hop to the rMUA, e.g. the ISP Demon in the UK offer SMTP delivery.

>              |        |
>              +------ MUA recipient (rMUA)

Regards
--=20
Paul Overell         Internet Platform Development Manager, Thus plc

--=_Turnpike_OcfCx6DCsHqA5LZ3=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc

--=_Turnpike_OcfCx6DCsHqA5LZ3=--

Date: Sat, 15 May 2004 01:36:25 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Internet Mail Architecture draft
Sender: [email-masked]

Folks,

I've just sent draft-crocker-mail-arch-00 to be issued as an
internet-draft.

In the interim, it is available at:

  <http://brandenburg.com/specifications/draft-crocker-mail-arch-00.htm>
and
  <http://brandenburg.com/specifications/draft-crocker-mail-arch-00.txt>

The document summarizes Internet Mail architectural components, their
relationships, and the identities they use.

The draft recommends that discussion about the draft take place on the
SMTP mailing list.

So I have only BCC'd the MARID and LEMONADE mailing lists, to let folks
there know about the draft. But it really will be better to have
discussion take place in only one venue.

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

To: [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 09 May 2004 12:18:22 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> I need to look at server_host again.  But one way to ask the question is
> - if a host has a cert that allows it to act as a web server for domain
> X, does that mean it has the authority to act as an MX for domain X?
> Basically if you want to have confidence that the mail is really going
> to the right place, you need different kinds of certs for the two
> situations.  And to do that you're going to need more than a TLS
> extension.

Ah, yes.  I'm sure that X.509 has a way to express things like this, but
I'm equally sure that no significant clients are currently verifying those
sorts of properties.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Cc: Keith Moore <[email-masked]>, [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
Date: Sun, 9 May 2004 13:34:51 -0400
To: Russ Allbery <[email-masked]>
Sender: [email-masked]

>> Whatever the other issues with MXs are, they are slightly different
>> issues.
>
> I'm not seeing why, other than that MX records are normally used for
> server-to-server communication rather than client-to-server 
> communication.

I need to look at server_host again.  But one way to ask the question 
is - if a host has a cert that allows it to act as a web server for 
domain X, does that mean it has the authority to act as an MX for 
domain X?  Basically if you want to have confidence that the mail is 
really going to the right place, you need different kinds of certs for 
the two situations.  And to do that you're going to need more than a 
TLS extension.

To: [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 07 May 2004 18:24:57 -0700
Sender: [email-masked]

Markus Stumpf <[email-masked]> writes:

> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031202
>     Displays a warning to check if tlstest.space.net and
>     www.spaceshop.de are identical and that the cert for
>     www.spaceshop.de is correct.

I'm not entirely sure what Mozilla/5.0 refers to, but Mozilla 1.5 on Linux
displays a dialog box with the following text:

    You have attempted to establish a connection with "tlstest.lamer.de".
    However, the security certificate presented belongs to
    "www.spaceshop.de".  It is possible, though unlikely, that someone
    may be trying to intercept your communication with this web site.

    If you suspect the certificate shown does not belong to
    "tlstest.lamer.de", please cancel the connection and notify the site
    administrator.

    [View Certificate]

    [OK]  [Cancel]  [Help]

Help pops up a bunch of additional information.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 8 May 2004 00:21:51 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Fri, May 07, 2004 at 10:58:56AM -0700, Russ Allbery wrote:
> The browser will complain, in the absence of implementation by both the
> server and the client of the new server_name TLS extension, unless that
> web site actually presents a certificate for www.example.com.

I did a setup with a name within my own domain
    tlstest.lamer.de
and a shop run by our company via http-TLS.
    www.spaceshop.de	     (sorry, this is not meant as a ad or something!!)

URL: https://tlstest.lamer.de/

Netscape® Navigator 4.7
    Displays the "secure site" Icon and NO WARNING

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031202
    Displays a warning to check if tlstest.space.net and
    www.spaceshop.de are identical and that the cert for
    www.spaceshop.de is correct.

w3m version w3m/0.5
    Bad cert ident www.spaceshop.de from tlstest.lamer.de: accept? (y/n)

Lynx Version 2.8.5dev.16 (01 Jun 2003)
  libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.6b
  Built on linux-gnu Jul 16 2003 16:19:18
    SSL error:host(tlstest.lamer.de)!=cert(www.spaceshop.de)-Continue? (y)

These are the browsers I could get my hand on (galeon is identical to
mozilla in this regard).
It looks like at least one older browser has problems getting it right.

	\Maex

P.S. I'll keep the  tlstest.lamer.de   for a while in case others want
     to test their browsers ;)

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

To: [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 07 May 2004 11:43:01 -0700
Sender: [email-masked]

John C Klensin <[email-masked]> writes:
> Russ Allbery <[email-masked]> wrote:

>> This is the reason why you didn't find an example like that.  This is
>> why web sites that require TLS have a separate IP address for every
>> host name.

> Of course, their doing so defeats all of the effort that people put into
> getting HOST into HTTP,

HOST is useless for solving this problem with HTTP over TLS because it
happens too late.  The TLS negotiation has already occurred by the time
the request with the Host header has been sent to the server.

> the position of sundry RIRs that assigning multiple addresses to one
> interface on a given host in order to work around poor protocol design
> was not justification for more addresses, etc.  Sigh.

Right.  That's why TLS added server_name, so that we can stop putting
multiple addresses on the same interface.  :)

> And I imagine that is part of the distinction Keith is trying to make.

If so, I think it's still lost on me....

> Whatever the other issues with MXs are, they are slightly different
> issues.

I'm not seeing why, other than that MX records are normally used for
server-to-server communication rather than client-to-server communication.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 07 May 2004 14:34:52 -0400
From: John C Klensin <[email-masked]>
To: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
Sender: [email-masked]

--On Friday, 07 May, 2004 10:58 -0700 Russ Allbery 
<[email-masked]> wrote:

> Markus Stumpf <[email-masked]> writes:
>> On Thu, May 06, 2004 at 09:11:54PM -0700, Russ Allbery wrote:
>
>>> I'm very suspicious of any place where TLS is done expecting
>>> any certificate other than the one matching the name that
>>> the user typed into their configuration or program, since it
>>> opens an avenue for attack.
>
>> How about
>>     www.example.COM	CNAME	cname.example.ORG.
>>     cname.example.ORG	A	10.0.0.1
>
>>     https://www.example.com/
>
>> Will the browser complain or is it happy as long as
>>     cname.example.com
>> has a valid cert?
>
> The browser will complain, in the absence of implementation by
> both the server and the client of the new server_name TLS
> extension, unless that web site actually presents a
> certificate for www.example.com.
>
>> Didn't find a setup like that for the moment, so I can't
>> check myself, but maybe someone on this list knows one ...
>
> This is the reason why you didn't find an example like that.
> This is why web sites that require TLS have a separate IP
> address for every host name.

Of course, their doing so defeats all of the effort that people 
put into getting HOST into HTTP, the position of sundry RIRs 
that assigning multiple addresses to one interface on a given 
host in order to work around poor protocol design was not 
justification for more addresses, etc.   Sigh.

And I imagine that is part of the distinction Keith is trying to 
make.  Whatever the other issues with MXs are, they are slightly 
different issues.

    john

To: [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 07 May 2004 11:17:43 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> This is true in general.  Just because you have a cert for a particular
> domain does not mean you are authorized to accept mail for that domain.

True.  The normal TLS PKI system is not particularly strong.

> Basically the email system, as part of its protocol definition, trusts
> the DNS.  If you don't have signed DNS records, there's a security hole.
> It's always been there.

I agree with that in general, but it is entirely possible to secure
specific SMTP links, and may even be valuable to do so in circumstances
more limited than exchanging e-mail with the entire Internet.  (On the
other hand, it's not clear to me that any of those circumstances would
entail MX records.)

> TLS simply wasn't designed to handle this case.

I believe that TLS with the server_name extension does actually handle
this case correctly and with the maximum possible security that one can
get out of whatever PKI system one is using for certificate validation.

> Since we don't have that, what this means is that TLS by itself is of
> limited applicability for email relaying.

Agreed.

> MX is not the same thing as virtual hosting.

Also agreed.  I'm just saying that at a TLS protocol level, the issues
involved look very similar.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 07 May 2004 10:58:56 -0700
Sender: [email-masked]

Markus Stumpf <[email-masked]> writes:
> On Thu, May 06, 2004 at 09:11:54PM -0700, Russ Allbery wrote:

>> I'm very suspicious of any place where TLS is done expecting any
>> certificate other than the one matching the name that the user typed
>> into their configuration or program, since it opens an avenue for
>> attack.

> How about
>     www.example.COM	CNAME	cname.example.ORG.
>     cname.example.ORG	A	10.0.0.1

>     https://www.example.com/

> Will the browser complain or is it happy as long as
>     cname.example.com
> has a valid cert?

The browser will complain, in the absence of implementation by both the
server and the client of the new server_name TLS extension, unless that
web site actually presents a certificate for www.example.com.

> Didn't find a setup like that for the moment, so I can't check myself,
> but maybe someone on this list knows one ...

This is the reason why you didn't find an example like that.  This is why
web sites that require TLS have a separate IP address for every host name.

> The same security problems apply as with an attacker being able to
> inject a MX record.

Exactly.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 7 May 2004 19:50:04 +0200
From: Markus Stumpf <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Thu, May 06, 2004 at 09:11:54PM -0700, Russ Allbery wrote:
> I'm very suspicious of any place where TLS is done expecting any
> certificate other than the one matching the name that the user typed into
> their configuration or program, since it opens an avenue for attack.

How about
    www.example.COM	CNAME	cname.example.ORG.
    cname.example.ORG	A	10.0.0.1

    https://www.example.com/

Will the browser complain or is it happy as long as
    cname.example.com
has a valid cert? Didn't find a setup like that for the moment, so I
can't check myself, but maybe someone on this list knows one ...

The same security problems apply as with an attacker being able to inject
a MX record.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

Date: Fri, 7 May 2004 11:54:20 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
Sender: [email-masked]

> 
> Keith Moore <[email-masked]> writes:
> 
> > That's the only way that makes sense.  If the SMTP client expected
> > the server's cert to match the domain in the email address (the one
> > used to query for MX records), it would not be feasible to use the
> > same SMTP server to accept mail for multiple MX domains.
> 
> The problem with taking this approach is that you've now reduced the
> security of your TLS session to the level of security of your DNS
> lookup.

This is true in general.  Just because you have a cert for a particular
domain does not mean you are authorized to accept mail for that domain.

Basically the email system, as part of its protocol definition, trusts
the DNS.  If you don't have signed DNS records, there's a security hole.
It's always been there.

TLS simply wasn't designed to handle this case.  If it were, there would
be a way to include additional certs of the form "domain X is authorized 
to be an MX for domain Y" that were signed by domain Y, with a complete
certificate chain for domain Y leading back to a trusted CA _in addition
to_ the certificate chain for domain X. 

Since we don't have that, what this means is that TLS by itself is of 
limited applicability for email relaying.   It does not guarantee that 
the mail goes where it's supposed to go.  Nor does it guarantee that
the traffic is not exposed to an eavesdropper.  It's safer than sending
the mail in cleartext, but that's not the same thing as saying you 
can trust it.

> You have correctly identified the problem, though, namely that there's
> no way prior to the TLS negotiation for the client to tell the server
> which certificate it should present.  HTTP has this same problem (thus
> making it currectly impossible to use TLS on a server farm without
> IP-based virtual hosts).

MX is not the same thing as virtual hosting.

Keith

To: [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 06 May 2004 21:11:54 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> That's the only way that makes sense.  If the SMTP client expected the
> server's cert to match the domain in the email address (the one used to
> query for MX records), it would not be feasible to use the same SMTP
> server to accept mail for multiple MX domains.

The problem with taking this approach is that you've now reduced the
security of your TLS session to the level of security of your DNS lookup.
If an attacker can insert their own MX record for the domain, the TLS
public key authentication will succeed.

I'm very suspicious of any place where TLS is done expecting any
certificate other than the one matching the name that the user typed into
their configuration or program, since it opens an avenue for attack.

You have correctly identified the problem, though, namely that there's no
way prior to the TLS negotiation for the client to tell the server which
certificate it should present.  HTTP has this same problem (thus making it
currectly impossible to use TLS on a server farm without IP-based virtual
hosts).

Thankfully, the TLS working group has released a fix for this that
actually solves the problem in the correct way.  See section 3.1 of RFC
3546.  Unfortunately, the server_name extension is probably still not
widely implemented.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: "Daryl Odnert" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SMTP/TLS: Authentication of an SMTP server's identity
Date: Thu, 6 May 2004 10:18:12 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4338E.1C4E26BE
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Greetings,

I would like to know what current industry standard
practices are with respect TLS enabled SMTP senders
and the expected domain name listed in the receiving
server's certificate.

RFC 3207 says that "a SMTP client would probably only
want to authenticate an SMTP server whose server certificate
has a domain name that is the domain name that the client
thought it was connecting to."

I assume this means that sending clients should expect
that the name in the certificate should match the name of
the Mail eXchanger host, and not the domain name that
was used to perform the MX lookup.  This makes sense
because the MX host might be in a different domain than
the one specified in the query.

For example, suppose an SMTP sender needs to send to
recipients at EXAMPLE.ORG and there are two MX hosts for
that domain: SMTP-1.EXAMPLE.COM and SMTP-2.EXAMPLE.COM.
The sending client should probably expect that each of
the MX hosts would have its own certificate and the name
in each certificate should match the MX host name.

Does this sound correct and does it match was existing
implementations are doing?

Thanks in advance,
Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C4338E.1C4E26BE
Content-Type: text/html
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2657.73">
<TITLE>SMTP/TLS: Authentication of an SMTP server's identity</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Greetings,</FONT>
</P>

<P><FONT SIZE=2>I would like to know what current industry standard</FONT>
<BR><FONT SIZE=2>practices are with respect TLS enabled SMTP senders</FONT>
<BR><FONT SIZE=2>and the expected domain name listed in the receiving</FONT>
<BR><FONT SIZE=2>server's certificate.</FONT>
</P>

<P><FONT SIZE=2>RFC 3207 says that &quot;a SMTP client would probably only</FONT>
<BR><FONT SIZE=2>want to authenticate an SMTP server whose server certificate</FONT>
<BR><FONT SIZE=2>has a domain name that is the domain name that the client</FONT>
<BR><FONT SIZE=2>thought it was connecting to.&quot;</FONT>
</P>

<P><FONT SIZE=2>I assume this means that sending clients should expect</FONT>
<BR><FONT SIZE=2>that the name in the certificate should match the name of</FONT>
<BR><FONT SIZE=2>the Mail eXchanger host, and not the domain name that</FONT>
<BR><FONT SIZE=2>was used to perform the MX lookup.&nbsp; This makes sense</FONT>
<BR><FONT SIZE=2>because the MX host might be in a different domain than</FONT>
<BR><FONT SIZE=2>the one specified in the query.</FONT>
</P>

<P><FONT SIZE=2>For example, suppose an SMTP sender needs to send to</FONT>
<BR><FONT SIZE=2>recipients at EXAMPLE.ORG and there are two MX hosts for</FONT>
<BR><FONT SIZE=2>that domain: SMTP-1.EXAMPLE.COM and SMTP-2.EXAMPLE.COM.</FONT>
<BR><FONT SIZE=2>The sending client should probably expect that each of</FONT>
<BR><FONT SIZE=2>the MX hosts would have its own certificate and the name</FONT>
<BR><FONT SIZE=2>in each certificate should match the MX host name.</FONT>
</P>

<P><FONT SIZE=2>Does this sound correct and does it match was existing</FONT>
<BR><FONT SIZE=2>implementations are doing?</FONT>
</P>

<P><FONT SIZE=2>Thanks in advance,</FONT>
<BR><FONT SIZE=2>Daryl Odnert</FONT>
<BR><FONT SIZE=2>Tumbleweed Communications</FONT>
<BR><FONT SIZE=2>Redwood City, California</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4338E.1C4E26BE--

Date: Thu, 6 May 2004 14:42:21 -0400
From: Keith Moore <[email-masked]>
To: "Daryl Odnert" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: SMTP/TLS: Authentication of an SMTP server's identity
Sender: [email-masked]

> RFC 3207 says that "a SMTP client would probably only
> want to authenticate an SMTP server whose server certificate
> has a domain name that is the domain name that the client
> thought it was connecting to."
> 
> I assume this means that sending clients should expect
> that the name in the certificate should match the name of
> the Mail eXchanger host, and not the domain name that
> was used to perform the MX lookup.  This makes sense
> because the MX host might be in a different domain than
> the one specified in the query.

That's the only way that makes sense.  If the SMTP client expected
the server's cert to match the domain in the email address
(the one used to query for MX records), it would not be feasible
to use the same SMTP server to accept mail for multiple MX domains.

this should probably go on the RFC editor's errata/clarifications
page for RFC 3207

--
Regime change 2004 - better late than never.

Date: Mon, 03 May 2004 15:54:15 -0500
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-hall-inline-dsn-01.txt]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------020304090008010106020905
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This version fixes an error and addresses the issues that Keith and John
raised, and makes the protocol much more reliable in general. These
changes are mostly in section 6.

I think that this will actually work, albeit only for ESMTP sessions.
Whether or not it is 'worth implementing' is a private issue at this
point. If folks are interested in pursuing it further, let me know and
we'll smooth out the text as needed.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--------------020304090008010106020905
Content-Type: message/rfc822;
 name="I-D ACTION:draft-hall-inline-dsn-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-hall-inline-dsn-01.txt"

To: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-hall-inline-dsn-01.txt
Date: Mon, 03 May 2004 15:54:40 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SMTP Service Extension for Inline DSNs
	Author(s)	: E. Hall
	Filename	: draft-hall-inline-dsn-01.txt
	Pages		: 11
	Date		: 2004-5-3
	
This memo describes a mechanism for the negotiation and transfer 
of per-recipient notification responses in SMTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hall-inline-dsn-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hall-inline-dsn-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hall-inline-dsn-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-hall-inline-dsn-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-hall-inline-dsn-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce

--------------020304090008010106020905--