Subject: Re: [Fwd: More information requested on publication status of draft-crocker-email-arch]
From: SM <[email-masked]>
To: Alexey Melnikov <[email-masked]>, [email-masked]
Cc: [email-masked]
Date: Fri, 29 May 2009 11:36:13 -0700
List-Id: <ietf-smtp.imc.org>

At 14:42 26-05-2009, Alexey Melnikov wrote:
>There have been two Last Call notices sent to the IETF for:
>
>    'Internet Mail Architecture' <draft-crocker-email-arch> as a 
> Proposed Standard
>
>The IESG has received a concern about the intended publication 
>status of this document and wishes to confirm the community's preferences.
>As the shepherding AD I would like to request more feedback on this 
>topic. Please send

It would disingenuous of me not to acknowledge and commend the effort 
by Dave in writing this draft about Internet Mail.

>Please indicate your preference for publishing the document as:
>
>    1. Proposed Standard, as queried in the two Last Call notices
>
>    2. Informational
>
>    3. Some other label
>
>    4. I have another opinion (please describe)
>
>Also please indicate your reason(s) for this choice.

There is an obsoleted "Request for Comments" (it's not a RFC) from 
the Network Working Group which was distributed to six people.  One 
of the six people is most likely subscribed to one of the mailing 
lists this message is addressed to.  I'll quote a few lines from the document:

   "Philosophical positions without examples or other specifics,
    specific suggestions or implementation techniques without
    introductory or background explication, and explicit questions
    without any attempted answers are all acceptable."

The document also stated that one of the reasons for the standards 
(or lack of them) is that:

   "There is a tendency to view a written statement as ipso facto
    authoritative, and we hope to promote the exchange and discussion of
    considerably less than authoritative ideas."

The discussions between various IETF participants about this draft 
highlight the philosophical differences about Internet Mail.  In 
spite of these philosophical differences, there has been "standards", 
Informational and Experimental documents about email.  Some of the 
standards have matured into Internet Standards.  The name may sound 
grand.  If you think about it, we rely on its acceptance by the 
Internet community.  Internet Mail share a similar characteristic in 
the sense that the message delivery relies on the acceptance by part 
of the Internet community, the broader the better.

Some people view published documents as authoritative.  If you say or 
do something wrong, someone might tell you "read the RFC" or "the RFC 
says so".  I prefer the former when the RFC contains a good 
explanation.  Sometimes an RFC doesn't explain why things are done in 
a particular way.  Over the years, most, if not all, of the authors I 
have come across have graciously explained the why when I sent in a question.

I don't adhere to the practice of using a "standard" as a bat as it 
is not a good way to promote ideas or to encourage adoption of the 
"standard".  It may be frustrating for those that have been around 
for a long time to hear the same questions and having to repeat the 
same answers over and over or to field off technically naive 
proposals.  I hope that the author of RFC 875 won't mind the minor 
change I made in quoting the following:

      Often, it's the Oral Tradition that matters; some RFCs, in their
      attempts to seem scholarly, offer the wrong levels of abstraction
      or, because of the backgrounds of their authors, are so
      ill-written as to fail to communicate well.  Sometimes, however,
      that which is truly relevant turns out to be unfindable by a
      conventional literature searcher because it isn't "in" the field
      of search.

Regards,
-sm 

Date: Wed, 27 May 2009 11:22:56 -0700
From: David MacQuigg <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Fwd: More information requested on publication status of    draft-crocker-email-arch]
Sender: [email-masked]

Pete Resnick wrote:
> This is an architecture document. We don't do these much anymore in 
> the IETF, and this one is particularly strange because it is 
> describing an architecture for a deployed service. However, I don't 
> think that means we should shy away from it. We in the email community 
> have needed this document for a *very* long time. We end up 
> re-discussing architectural issues in each new WG just to get our 
> terms straight and constrain solution spaces (cf. LEMONADE, MARID, 
> DKIM). And we need to have a document to point to so that newcomers 
> can couch their proposals in terms we understand without having to 
> re-argue the model every time. But in order for it to work in these 
> roles, and for it to have the ability to evolve over time, it really 
> needs to be a standards track document.

I agree with everything but that last statement.  We don't need to 
declare this one model as the Standard Model in order to use it in our 
discussions.  An Informational document should serve that purpose.   
Making it a standard will only discourage the development of better 
models in the future.  Surely, you can't think this is the only or even 
the best model we will ever have.

I too have been frustrated by futile arguments over terminology, but I 
believe this futility comes from the politics of the situation, not an 
inability to agree on terms for a discussion.  When people are not 
driven by politics, or some hidden corporate agenda, and are actually 
wanting to move a discussion forward, it is not hard to agree on a model 
and terminology, at least for that one discussion.  If people want to 
block progress in a discussion, then saying you MUST use the terms and 
models in this document will as likely help those who want to block 
progress as help those who want to move things forward.

Standards should constrain what we do in implementing protocols, not 
limit our thinking on models.  Standards are needed to ensure 
interoperability of these implementations, not try to get everyone to 
think the same.  Perhaps the few things in this document that need to be 
standardized should be labeled with MUST and SHOULD, and the rest 
clearly understood to be just a model.  The semantics of the Mail From 
address is certainly one of those things.  The ADMD diagram is not.

It may be that this model will be so widely used over the next few years 
that it becomes a defacto standard.  That's the way things work in 
science, anyway.  There are no committees to declare one or another 
scientist's theory as "the standard".   I think it has worked quite well.

> Yes, there will inevitably be differences between the overall 
> architecture of the system and the protocols that instantiate it. 
> There are simply pragmatics which make such compromise required, and 
> it is in fact a healthy tension. And yes, that fact means that some 
> people will do stupid things, like claiming that where the 
> architecture and protocols diverge, the architecture must win. There 
> will always be such folks who don't understand that sometimes 
> pragmatics prevail over architectural purity. But I think to not call 
> this document what it is (i.e., an evolving community consensus on the 
> email architecture) in fear of how it might be used is frankly a bit nuts.

It is already happening.  I have been in discussions where we have 
deadlocked over the words actor and agent.  I use them in their original 
plain-English meanings, as an individual or organization.  The person 
with whom I was attempting to have a discussion insisted, even after 
repeated clarification of this point, that everything I said was wrong.  
In his mind, agents are machines and cannot be anything else.

> Let's address the problems as they arise rather than further 
> diminishing the meaning of our document series.

What will most diminish the value of IETF standards?  I believe it is 
having those standards widely ignored.  That will happen if you 
over-reach with this document.

************************************************************     *
* David MacQuigg, PhD    email: macquigg at ece.arizona.edu   *  *
* Research Associate                phone: USA 520-721-4583   *  *  *
* ECE Department, University of Arizona                       *  *  *
*                                 9320 East Mikelyn Lane       * * *
* http://purl.net/macquigg        Tucson, Arizona 85710          *
************************************************************     *

Date: Wed, 27 May 2009 00:14:59 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Comments on draft-moonesamy-smtp-vrfy-ddds-00
Cc: [email-masked]
Sender: [email-masked]

Hi Ray,
At 04:27 26-05-2009, [email-masked] wrote:
>1.  AFAIK, the only "security problem" with SMTP VRFY was information
>leakage, i.e. that it provides a simple means to check which local parts
>are valid without actually sending an e-mail.  Your proposal does the
>same, and makes it even easier.  Is my understand correct, and if so,
>what's your intent?

Section 7.3 of RFC 5321 discusses about the "security problem" with 
SMTP VRFY.  As mentioned in the last paragraph of that section, "in 
many cases, RCPT commands can be
used to obtain the same information about address validity".  The 
mechanism proposed has less overhead and it makes it easier to 
distribute the information about valid local-parts.  There is more 
risk of information leakage.  Access to the DDDS database could be 
restricted by distributing the data on a private basis or by private 
tree arrangement.

>2.  There is no reference to the need to treat a '.' in the local part as
>part of the label, and not a label separator.  DNS guys know this, e-mail
>implementers may not...

Yes. From a DNS perspective, there are also some other issues that 
have to be covered.  DNS guys will likely point out that DNS is 
generally referred to as public DNS for a reason. :-)

Regards,
-sm 

Date: Tue, 26 May 2009 20:42:08 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SMTP Interest Group <[email-masked]>
Subject: Re: [Fwd: More information requested on publication status of    draft-crocker-email-arch]
Sender: [email-masked]

Alexey Melnikov wrote:
>    'Internet Mail Architecture' <draft-crocker-email-arch> as a Proposed 
> Standard
> 
> The IESG has received a concern about the intended publication status of 
> this document and wishes to confirm the community's preferences.

Folks,

As the document's author, my preference for its status is obvious.  But I
thought it worth commenting on the reason I believe a document of this type --
and this particular document -- warrants standardization.

Any protocol specification that we do standardize is a component of an
integrated service.  Standardizing a component, without standardizing the
context into which is it being used, is a bit like writing a precise contract
for a supply of screws or a heating element or bits of sheet metal, but not
specifying their integration into a toaster, or some other particular
(integrated) product.

The screws or heating elements might be used for a variety of other products.
There's nothing wrong with that.  Those other uses do not constitute a
"violation" of the toaster specification.  They're just different.

So it should be for an integrated service like Internet Mail.  We did not feel
compelled to do the specification long ago because back then the service began
in a kind of cottage industry within a small community. The systems
specification was informally shared.  The community, now, is much larger and
shares none of that original history.  This constantly causes confusion in
discussions about the integrated service.  So, that community needs to see a
specification for this particular service we call Internet Mail.

They need to see it as a standard for the same reason they need to see the
components as standards.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 26 May 2009 17:08:39 -0500
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [Fwd: More information requested on publication status of     draft-crocker-email-arch]
CC: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 5/26/09 at 10:42 PM +0100, Alexey Melnikov wrote:

>    'Internet Mail Architecture' <draft-crocker-email-arch> as a 
>Proposed Standard
>
>Please indicate your preference for publishing the document as:
>
>    1. Proposed Standard, as queried in the two Last Call notices

I believe it should be Proposed Standard.

>Also please indicate your reason(s) for this choice.

Restating something I sent to the IESG separately earlier:

This is an architecture document. We don't do these much anymore in 
the IETF, and this one is particularly strange because it is 
describing an architecture for a deployed service. However, I don't 
think that means we should shy away from it. We in the email 
community have needed this document for a *very* long time. We end up 
re-discussing architectural issues in each new WG just to get our 
terms straight and constrain solution spaces (cf. LEMONADE, MARID, 
DKIM). And we need to have a document to point to so that newcomers 
can couch their proposals in terms we understand without having to 
re-argue the model every time. But in order for it to work in these 
roles, and for it to have the ability to evolve over time, it really 
needs to be a standards track document.

Yes, there will inevitably be differences between the overall 
architecture of the system and the protocols that instantiate it. 
There are simply pragmatics which make such compromise required, and 
it is in fact a healthy tension. And yes, that fact means that some 
people will do stupid things, like claiming that where the 
architecture and protocols diverge, the architecture must win. There 
will always be such folks who don't understand that sometimes 
pragmatics prevail over architectural purity. But I think to not call 
this document what it is (i.e., an evolving community consensus on 
the email architecture) in fear of how it might be used is frankly a 
bit nuts. Let's address the problems as they arise rather than 
further diminishing the meaning of our document series.

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

Date: Tue, 26 May 2009 22:40:16 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: More information requested on publication status of draft-crocker-email-arch
Sender: [email-masked]

There have been two Last Call notices sent to the IETF for:

    'Internet Mail Architecture' <draft-crocker-email-arch> as a 
Proposed Standard

The IESG has received a concern about the intended publication status of 
this document and wishes to confirm the community's preferences.
As the shepherding AD I would like to request more feedback on this 
topic. Please send your answers by the end of June 3rd.
You can either reply to this message, send your response directly to 
[email-masked], or send it directly to me and Tony Hansen <[email-masked]>.

Please indicate your preference for publishing the document as:

    1. Proposed Standard, as queried in the two Last Call notices

    2. Informational

    3. Some other label

    4. I have another opinion (please describe)

Also please indicate your reason(s) for this choice.

To: [email-masked]
Cc: [email-masked]
Subject: Comments on draft-moonesamy-smtp-vrfy-ddds-00
From: [email-masked]
Date: Tue, 26 May 2009 12:27:36 +0100
Sender: [email-masked]

http://tools.ietf.org/html/draft-moonesamy-smtp-vrfy-ddds-00

I don't see this draft being discussed yet, but do have a couple of 
comments.

1.  AFAIK, the only "security problem" with SMTP VRFY was information 
leakage, i.e. that it provides a simple means to check which local parts 
are valid without actually sending an e-mail.  Your proposal does the 
same, and makes it even easier.  Is my understand correct, and if so, 
what's your intent?

2.  There is no reference to the need to treat a '.' in the local part as 
part of the label, and not a label separator.  DNS guys know this, e-mail 
implementers may not...

regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

Cc: Ned Freed <[email-masked]>, IETF SMTP list <[email-masked]>
From: Douglas Otis <[email-masked]>
To: John R Levine <[email-masked]>
Subject: Re: Email System Model
Date: Sun, 24 May 2009 20:59:27 -0700
Sender: [email-masked]

On May 22, 2009, at 3:28 AM, John R Levine wrote:
>> Actually, it works pretty well in practice. The main problem with  
>> secondary MXes is that spammers send messages to them even when the  
>> primary is up (which in most cases is 99+% of the time).
>
> This leads to the fairly obvious question: if the primary is up 99+%  
> of the time, what's the point of a secondary?  There was an era when  
> they were useful to deal with networks that didn't have routes to  
> some parts of the net, but I'd think that's a pretty small niche  
> now.  Unless your primary is down for a long time, days or longer,  
> any legitimate mail will just wait and retry and get delivered anyway.

After recently examining samples of DSN messages from systems  
carefully selected to represent legitimate MTAs, two configurations  
stood out as as potential sources issuing DSNs.  One being MS  
Exchange, presumably behind an MTA isolating Windows from directly  
interacting with the Internet, and a similar configuration where a  
filtering services like Baracuda was placed within the path of the  
protected MTA.  This tends to indicate that the major DSN problem  
today is not the result of backup MX systems.  While recipient hashes  
might be one solution, the general problem appears to be a need for a  
standardized way to share valid mail-box information between two  
systems, where each system depends upon different configuration  
practices.

-Doug

Date: Sat, 23 May 2009 11:10:48 -0400
From: John C Klensin <[email-masked]>
To: Alessandro Vesely <[email-masked]>, [email-masked]
Subject: Re: Backup MXes (was: Re: Email System Model
Sender: [email-masked]

--On Saturday, May 23, 2009 15:37 +0200 Alessandro Vesely
<[email-masked]> wrote:

> 
> I've tried and summarized the results of the thread in
> http://fixforwarding.org/wiki/Backup_MX

There is a third important case although "backup MX" may or may
not be the right terminology for it.  In that case, the target
host is basically not attached to the same network as
normal/public Internet-based senders -- the situation may not
involve an outage.  Examples:

	(1) The target host is on Mars and can be accessed,
	easily and normally, by other Martian hosts.  However,
	for a host on earth, the target host will rarely be
	reachable via a normal TCP/SMTP connection and the
	intermediate MX host may have the needed delay-tolerant
	machinery installed.

	(2) Similar situations apply with a server on a firewall
	(or equivalent) when the internal hosts still use public
	address space.   Then one might have
	       foo IN MX 0 bar.example.org.
	           IN MX 10 baz.example.net.
	where bar uses public address space but is not
	accessible from outside the "example.org" enterprise
	network and baz is public.
          
	(3) The developing country example you mention may be
	part of this case, rather than the "outage" one.

The article also seems to omit the important point that there is
no requirement that a backup MX use SMTP outbound.  Once it has
gotten the mail, it may use SMTP to get the mail to the delivery
server, but it may use any other mutually-acceptable transport
mechanism, including some batch or bucket procedure and, e.g.,
CDs in the post.

     john

Date: Sat, 23 May 2009 15:37:39 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Backup MXes (was: Re: Email System Model
Sender: [email-masked]

I've tried and summarized the results of the thread in 
http://fixforwarding.org/wiki/Backup_MX

Thanks to all

To: IETF SMTP list <[email-masked]>
Subject: Re: Email System Model
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 22 May 2009 16:50:39 -0700
Sender: [email-masked]

John R Levine <[email-masked]> writes:

> This leads to the fairly obvious question: if the primary is up 99+%
> of the time, what's the point of a secondary?  There was an era when
> they were useful to deal with networks that didn't have routes to some
> parts of the net, but I'd think that's a pretty small niche now.
> Unless your primary is down for a long time, days or longer, any
> legitimate mail will just wait and retry and get delivered anyway.

My primary is probably up 99% of the time since it only really goes down
every three years or so.  However, when it goes down, it's usually down
for days and I want control over the mail in the meantime.  I don't know
in advance when it's going to go down, and it may well be while I'm out
of the country or don't have Internet access.

I have control over queue retentions on my secondary and can hang on to
mail until I know I'll be around to address whatever problem is
happening.

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

Date: Fri, 22 May 2009 07:55:34 -0700 (PDT)
From: [email-masked]
Subject: Re: Email System Model
To: John R Levine <[email-masked]>
Cc: Ned Freed <[email-masked]>, IETF SMTP list <[email-masked]>
Sender: [email-masked]

> >> I understand about callforwards, but it seems to me that the backup MX
> >> is mostly going to get mail when the main MX isn't available, so I
> >> don't see how this would work very well in practice.
> >
> > Actually, it works pretty well in practice. The main problem with secondary
> > MXes is that spammers send messages to them even when the primary is up (which
> > in most cases is 99+% of the time).

> This leads to the fairly obvious question: if the primary is up 99+% of
> the time, what's the point of a secondary?

The point is, as the saying goes, that "past performance is not an indicator
of future results".

I have several machines here that have operated at three or even four 9s for
years. Doesn't mean I don't back them up regularly, because sooner or later
there's bound to be a catastrophic failure of one sort or another.

> There was an era when they
> were useful to deal with networks that didn't have routes to some parts of
> the net, but I'd think that's a pretty small niche now.

Yes, but asymmetric routing faults are still pretty common, especially in
developing countries. A fairly common setup I've seen is to have a secondary
somewhere else that has a backup link to get mail to the primary when regular
connectively isn't working.

> Unless your
> primary is down for a long time, days or longer, any legitimate mail will
> just wait and retry and get delivered anyway.

Prolonged primary outages are exactly the case having a secondary is mostly
concerned with these days.

And again note that the outages may be network, not server, related. I have no
idea if my experience is typical, but I've seen far more cases where a
secondary became important because of a prolonged network outage than because
of a server outage.

				Ned

Date: Fri, 22 May 2009 15:42:06 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Email System Model
Sender: [email-masked]

[email-masked] wrote:
>>>> Externally administered backup MXes run into backscattering because 
>>>> they don't maintain a copy of the users database.
>>>
>>> Some don't, many do.
>
>> Hm... would you expand on that, please? I browsed a few backup MX 
>> providers (DydDNS, ZoneEdit and Mailfail) and saw no evidence that 
>> they do.
>
> You're looking at commercial backup provision services. Historically this isn't 
> how backuup MX arrangements have worked. Most of them are simply one small site 
> helping out another. In such cases providing a copy of your address list often 
> isn't a big deal.

Offering backup MX services to a 98+% uptime server didn't require 
much resource allocation, at the time. Holding a cache copy of the 
users database may be slightly heavier.

> In fact there's even a suggested protocol for it. I don't recall the draft
> name, but it works by putting the address list in the DNS. You then use 
> zone transfer to move the data around and keep it up to date.

I only found "Minger", Expires: January 9, 2009
http://tools.ietf.org/html/draft-hathcock-minger
In short, it provides an UDP-based security-enhanced alternative to 
VRFY, and uses no DNS. It might have worked, but would have required a 
backup minger server...

>> in principle, users should be aware of what organizations 
>> take part in managing their data. Currently, that info is relegated to 
>> a non-machine readable ISP's policy page, if any.
>
> That's ... idealistc, I must say. I doubt very much if most administrators 
> agree that simply the list of active addresses, with no additional attached 
> data whatsoever, in their domains have such serious privacy implications.

Serious or not, it is what privacy laws require in several countries. 
While a policy page is enough for the law, I think privacy concerned 
users would appreciate the ability to retrieve the effective list of 
servers where their email addresses are stored. I agree it's an 
idealistic wish, and it will probably remain that way until some 
marketing function will say otherwise.

>> The rule to strip subaddresses is a good point. Apparently, a regex 
>> might suffice,
>
> At one point I suggested using NAPTR records as part of the address
> distribution protocol for secondaries in order to get exactly this effect.

Is it practical to use DNS at all for this purpose? Why not LDAP, SQL, 
rsync, or ...? Regexes could also be passed along with other metadata, 
such as agreements on DNSBLs, whitelists, etcetera (and what of that 
can be overridden by per-user flags.)

Date: Fri, 22 May 2009 14:34:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Email System Model
Sender: [email-masked]

John R Levine writes:
> This leads to the fairly obvious question: if the primary is up 99+% 
> of the time, what's the point of a secondary?

I keep repeating: The point of secondaries is to prevent those "delayed" 
DSNs that so confuse senders.

Not much of a point, I suppose.

Arnt

Date: Fri, 22 May 2009 11:28:04 +0100 (BST)
From: John R Levine <[email-masked]>
To: Ned Freed <[email-masked]>
cc: IETF SMTP list <[email-masked]>
Subject: Re: Email System Model
Cleverness: None detected
Sender: [email-masked]

>> I understand about callforwards, but it seems to me that the backup MX
>> is mostly going to get mail when the main MX isn't available, so I
>> don't see how this would work very well in practice.
>
> Actually, it works pretty well in practice. The main problem with secondary
> MXes is that spammers send messages to them even when the primary is up (which
> in most cases is 99+% of the time).

This leads to the fairly obvious question: if the primary is up 99+% of 
the time, what's the point of a secondary?  There was an era when they 
were useful to deal with networks that didn't have routes to some parts of 
the net, but I'd think that's a pretty small niche now.  Unless your 
primary is down for a long time, days or longer, any legitimate mail will 
just wait and retry and get delivered anyway.

Regards,
John Levine, [email-masked], Taughannock Networks, Cambridge UK
"I dropped the toothpaste", said Tom, crestfallenly.

Date: Thu, 21 May 2009 18:11:19 -0700 (PDT)
From: [email-masked]
Subject: Re: Email System Model
To: John Levine <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> >In fact there's even a suggested protocol for it. I don't recall the draft
> >name, but it works by putting the address list in the DNS. You then use zone
> >transfer to move the data around and keep it up to date.

> Remember the reference?  I was thinking of something like that, but if
> it's already done, all the better.

Sorry, I don't recall it and The Google seems to be singularly unhelpful
finding it.

In any case, I'm also very interested in this and would be happy to work
on it with you if you like.

> >There are also at least two, and probably more, "lookahead" milters that use
> >part of an SMTP transaction to perform early address validation. (I use one of
> >these myself as part of providing backup MX service for a couple of people.)

> I understand about callforwards, but it seems to me that the backup MX
> is mostly going to get mail when the main MX isn't available, so I
> don't see how this would work very well in practice.

Actually, it works pretty well in practice. The main problem with secondary
MXes is that spammers send messages to them even when the primary is up (which
in most cases is 99+% of the time). So even if this only provides effective
filtering when the primary is up, it's sufficient to prevent most blowback.

				Ned

P.S. One of the secondaries I provide is for a system that's connected via a
fairly long radio link. The link goes wonky when someone uses a cordless phone
near either end. But according to my stats, even that server manages 99.8%
uptime.

Date: 22 May 2009 00:05:39 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: Email System Model
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>In fact there's even a suggested protocol for it. I don't recall the draft
>name, but it works by putting the address list in the DNS. You then use zone
>transfer to move the data around and keep it up to date.

Remember the reference?  I was thinking of something like that, but if
it's already done, all the better.

>There are also at least two, and probably more, "lookahead" milters that use
>part of an SMTP transaction to perform early address validation. (I use one of
>these myself as part of providing backup MX service for a couple of people.)

I understand about callforwards, but it seems to me that the backup MX
is mostly going to get mail when the main MX isn't available, so I
don't see how this would work very well in practice.

R's,
John

Date: Thu, 21 May 2009 11:20:04 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Alessandro Vesely <[email-masked]>
CC:  [email-masked], [email-masked]
Subject: Re: Email System Model
Sender: [email-masked]

Hector Santos wrote:

> An example is:
> 
>     http://www.virtualconnect.net/
> 
> which has a specifications and format to help automate a process of 
> creating an export or update and emailing it to them.  Our utility uses 
> them as an example using a email template to send the a new list or 
> updated names.

I should note that this was circa 2003 time frame and it was before we 
got involved with the then new IETF avs, spoofing, phishing efforts. 
It was also the SORBIG emerge with its infamous dual blitz email 
attach strategy finally waking up and showing the world we had a 
serious spoofing and backscattering issue with ACCEPT/BOUNCE SMTP 
systems.

Since then we have our own AVS stuff so that might explain why we 
hardly hear from any of our customers needing to outsource some AVS MX 
relay host.

I would venture that this was a general trend as more and more systems 
began to take more responsibility of the crap coming into their system 
have their own built-in set or suite of SMTP based AVS measures - out 
of necessity and probably also to eliminate the cost of having to 
outsource this functionality.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 21 May 2009 08:04:11 -0700 (PDT)
From: [email-masked]
Subject: Re: Email System Model
To: Alessandro Vesely <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> [email-masked] wrote:
> >
> >> Externally administered backup MXes run into backscattering because
> >> they don't maintain a copy of the users database.
> >
> > Some don't, many do.

> Hm... would you expand on that, please? I browsed a few backup MX
> providers (DydDNS, ZoneEdit and Mailfail) and saw no evidence that
> they do.

You're looking at commercial backup provision services. Historically this isn't
how backuup MX arrangements have worked. Most of them are simply one small site
helping out another. In such cases providing a copy of your address list often
isn't a big deal.

In fact there's even a suggested protocol for it. I don't recall the draft
name, but it works by putting the address list in the DNS. You then use zone
transfer to move the data around and keep it up to date.

There are also at least two, and probably more, "lookahead" milters that use
part of an SMTP transaction to perform early address validation. (I use one of
these myself as part of providing backup MX service for a couple of people.)

> >> To amend that status
> >> of affairs implies that a user's email address will also be stored at
> >> an externally controlled backup MX. Such situation should interest the
> >> users, as those addresses are part of their personally identifiable
> >> information.
> >
> > Not necessarily. The obvious trick is to store hashes of valid addresses
> > along
> > with per-domain rules for how to strip stuff like subaddresses, prefix
> > characters, etc. Yes, a dictionary attack can be performed on this
> > information,
> > but you can also do that by whacking on the primary MX.

> More easily, a backup MX provider can just store each hit it finds.
> However, even if cute tricks may rule out any relevant information
> leakage, in principle, users should be aware of what organizations
> take part in managing their data. Currently, that info is relegated to
> a non-machine readable ISP's policy page, if any.

That's ... idealistc, I must say. I doubt very much if most administrators
agree that simply the list of active addresses, with no additional attached
data whatsoever, in their domains have such serious privacy implications.

> The rule to strip subaddresses is a good point. Apparently, a regex
> might suffice,

At one point I suggested using NAPTR records as part of the address
distribution protocol for secondaries in order to get exactly this effect.

> although in some cases passing the complete subaddress
> (or its hash) may be preferable.

It depends on what the rules are for unknown subaddresses. A site that limits
subaddresses to the specific ones a user allows would be better off passing the
whole thing. But if unknown subaddresses are simply ignored, as is often the
case, canonicalizing subaddresses away makes the most sense.

> What about honeypots?

A regex can be made general enough for those too, I think.

				Ned

Date: Thu, 21 May 2009 11:01:42 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Alessandro Vesely <[email-masked]>
CC:  [email-masked], [email-masked]
Subject: Re: Email System Model
Sender: [email-masked]

Alessandro Vesely wrote:
> 
> [email-masked] wrote:
>>
>>> Externally administered backup MXes run into backscattering because
>>> they don't maintain a copy of the users database.
>>
>> Some don't, many do.
> 
> Hm... would you expand on that, please? I browsed a few backup MX 
> providers (DydDNS, ZoneEdit and Mailfail) and saw no evidence that they do.

So therefore it doesn't exist.... hmmmmmm...

Some hosting system do or did more so in the past to provide service 
to smaller SMTP operators.  We provide an export utility for our SMTP 
operators who want to have a secondary host, MX Backup and/or a AVS MX 
relay at some host. It recreates the valid email names as it would 
apply to a connecting SMTP client to one of our SMTP servers during 
the RCPT validation check.

An example is:

     http://www.virtualconnect.net/

which has a specifications and format to help automate a process of 
creating an export or update and emailing it to them.  Our utility 
uses them as an example using a email template to send the a new list 
or updated names.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 21 May 2009 16:16:57 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Email System Model
Sender: [email-masked]

[email-masked] wrote:
> 
>> Externally administered backup MXes run into backscattering because
>> they don't maintain a copy of the users database.
> 
> Some don't, many do.

Hm... would you expand on that, please? I browsed a few backup MX 
providers (DydDNS, ZoneEdit and Mailfail) and saw no evidence that 
they do.

>> To amend that status
>> of affairs implies that a user's email address will also be stored at 
>> an externally controlled backup MX. Such situation should interest the 
>> users, as those addresses are part of their personally identifiable 
>> information.
>
> Not necessarily. The obvious trick is to store hashes of valid addresses 
> along 
> with per-domain rules for how to strip stuff like subaddresses, prefix 
> characters, etc. Yes, a dictionary attack can be performed on this 
> information, 
> but you can also do that by whacking on the primary MX.

More easily, a backup MX provider can just store each hit it finds. 
However, even if cute tricks may rule out any relevant information 
leakage, in principle, users should be aware of what organizations 
take part in managing their data. Currently, that info is relegated to 
a non-machine readable ISP's policy page, if any.

The rule to strip subaddresses is a good point. Apparently, a regex 
might suffice, although in some cases passing the complete subaddress 
(or its hash) may be preferable. What about honeypots?

Date: Wed, 20 May 2009 15:09:53 -0700 (PDT)
From: [email-masked]
Subject: Re: Email System Model
To: Alessandro Vesely <[email-masked]>
Cc: [email-masked], David MacQuigg <[email-masked]>
Sender: [email-masked]

> Externally administered backup MXes run into backscattering because
> they don't maintain a copy of the users database.

Some don't, many do.

> To amend that status
> of affairs implies that a user's email address will also be stored at
> an externally controlled backup MX. Such situation should interest the
> users, as those addresses are part of their personally identifiable
> information.

Not necessarily. The obvious trick is to store hashes of valid addresses along
with per-domain rules for how to strip stuff like subaddresses, prefix
characters, etc. Yes, a dictionary attack can be performed on this information,
but you can also do that by whacking on the primary MX.

				Ned

Date: Wed, 20 May 2009 13:44:21 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
CC: David MacQuigg <[email-masked]>
Subject: Re: Email System Model
Sender: [email-masked]

David MacQuigg wrote:
> Alessandro Vesely wrote:
>> I had hoped that a protocol for configuring forwarding would have 
>> smoothly lent itself to also configure secondary MXes
> 
> The model at http://open-mail.org/MHSmodels.html is an 
> administrative-level model, not a relay-level model.   We are modeling 
> Actors (Users and Agents) and their roles in an email system.  Backup 
> MXs are relays under the control of the Receiving Agent, even if they 
> are actually subcontracted to a hosting service in another city.

It only makes sense to reserve a place for backup MXes in a model if 
such modeling is aimed at bettering the mail system, rather than 
merely describing how it currently does [not] work.

> To add a Backup Agent to the model, I would need to see an example of 
> how this might make a difference to any Actor interacting with the 
> Receiving Agent.   Yes, there are many problems with backup MXs not 
> having current information on a sender's greylist status, not knowing 
> when the primary MX is back in operation, etc., but how is that 
> different than a Receiver Agent that simply fumbles its internal 
> operations?

Externally administered backup MXes run into backscattering because 
they don't maintain a copy of the users database. To amend that status 
of affairs implies that a user's email address will also be stored at 
an externally controlled backup MX. Such situation should interest the 
users, as those addresses are part of their personally identifiable 
information. I say /should/ because the same is true for forwarding. 
In both cases, Actors should provide means for exercising their users' 
rights.

Date: Tue, 19 May 2009 16:50:11 -0700
From: David MacQuigg <[email-masked]>
To: [email-masked]
CC: Alessandro Vesely <[email-masked]>
Subject: Re: Email System Model
Sender: [email-masked]

Alessandro Vesely wrote:
> David MacQuigg wrote:
>
>> I'm looking for constructive criticism.  If you believe the model is 
>> oversimplified, give me an example of an important system that the 
>> model should cover.
>
> Backup MXes. Nowadays, having good connections and much spam, backup 
> MXes are avoided by the organizations whose networks would require to 
> outsource them (while primary MXes are contracted in.) Should 
> connections worsen, e.g. for solar activity[1], war, or terrorism, 
> those organizations may be in for a hard surprise.
>
> I had hoped that a protocol for configuring forwarding would have 
> smoothly lent itself to also configure secondary MXes[2], so as to 
> kill both birds with one stone, but either I lack the brain resources 
> to see its simplicity, or it is by far more complicate than what I can 
> manage in my spare time :-(

The model at http://open-mail.org/MHSmodels.html is an 
administrative-level model, not a relay-level model.   We are modeling 
Actors (Users and Agents) and their roles in an email system.  Backup 
MXs are relays under the control of the Receiving Agent, even if they 
are actually subcontracted to a hosting service in another city.

To add a Backup Agent to the model, I would need to see an example of 
how this might make a difference to any Actor interacting with the 
Receiving Agent.   Yes, there are many problems with backup MXs not 
having current information on a sender's greylist status, not knowing 
when the primary MX is back in operation, etc., but how is that 
different than a Receiver Agent that simply fumbles its internal operations?

I also have suggestions (off list) to add a Mail Storage Agent and a 
Webmail Agent.  Again, I need to see an example where we cannot simply 
consider these as machines under the control of the Delivery Agent.  We 
want to keep the model simple, but not oversimplify to the point of 
missing something essential.

I went ahead and added Mediator to the Model.  A fully-automated 
Mediator could be treated as an Agent, but we will treat it as a special 
kind of User, one that Receives, Processes, and automatically Resends a 
message, perhaps to multiple new Recipients.  This doesn't add much 
complexity to our simple model.  A system with a Mediator can be shown 
as two simple systems connected at the User level by a Mediator 
(Recipient/Author).

I have suggestions (off list) to avoid the plain-English meaning of 
Actor and Agent, and use these words to mean only a machine or process.  
I don't have any suggested alternatives, however, and ADMD will not mean 
much to students.  My preference is to use these words first with their 
plain-English meaning, introducing the administrative-level model, then 
explain that an "Agent" can also be a machine, and the acronyms MSA, 
MTA, and MDA are commonly used for machines.  I don't see a problem in 
using the same name for a machine and an Agent operating that machine.  
The few places where there might be confusion can easily be avoided by 
spelling it out - MDA Agent, or MDA Relay.

I would like to avoid using the same name for *different* functions at 
different levels.  Thus, I would like to resolve a possible conflict 
over the word Receiver.  At the administrative level, a Receiver Agent 
has certain responsibilities, including authenticating the Transmitter 
Agent and other things related to its position at the Border (Edge of 
the Internet).  One Agent can perform both Receiving and Delivery roles, 
but often there are two separate Agents.  When that happens, the model 
must show the Receiving Agent ahead of the Delivery Agent.

This conflicts with the latest rev of email-arch, Figure 3.  The name of 
the final relay was changed from Destination to Receiver.  I don't 
recall any discussion on this change, but I may have missed it.  I think 
Destination is a good neutral word that won't conflict with future 
developments in email system modeling.

Many thanks to all who have made suggestions.

-- Dave

Date: Mon, 18 May 2009 10:58:30 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: David MacQuigg <[email-masked]>
CC:  [email-masked]
Subject: Re: Email System Model
Sender: [email-masked]

David,

These are my own technical writing methods and for this type of 
subject, this would be some of my initial inclinations as a first 
approach using a system engineering (component, blackbox, functional 
models, etc.) standpoint.

- Legends

   Very important to begin with a legend of well known
   acronyms representing components of the network.

    MTA, MUA (UA), MTA,MSA, MDA, etc, I would probably add MLS for
    Mail List Server, a very important part of the infrastructure,
    and MGS (Mail Gateway Server), etc.

- Message Structure

   I would do a basic overview of the fundamental common message
   structure in ALL networks, starting with the basic idea that
   every "Communication" system and with mail, five basic elements:

     From (Author)
     To: (Recipient)
     Subject: (TOPIC)
     Date: (Creation Date)
     Body: (content

   You can then introduce the extensions and variations to be
   discuss in more detail elsewhere.

- Transport Structure

   I would begin to talk how Messages are wrapped with Transport
   Networking layers, envelope idea, etc. which can lead to
   the next subject.

- Offline, Online, Store and Forward

   I would also touch based with these ideas as is related to
   topologies and how data is created, sent and delivered. I
   would break this down to three parts:

    - Message Creation
    - Message Transfer
    - Message Delivery

- Topologies or Functional Models

   I would then probably talk about topology and the various
   common ones, including maybe the history from centralization,
   distributed, to maybe even back to centralization. I would
   start with a general overview (like what you have),

       UA --> [ MODELS ] --> UA

   and then show expands of the various models, from simple routes
   to more interfacing domain complex.

- List of technologies

   Here I would begin to talk about the ideas that extend or
   help the process. You can list the IETF protocols here and begin
   to show these how they fit into the topologies and mail flow.

And so on, the exact order above could change of course.

If this may help, since you are targeting students, one of my first 
intros to the growing communications market, was a first edition book 
I read long ago that covered the technologies of the day (including 
BBSes) and the directions might be useful:

     Digital Communications
     Thomas C Bartee
     First Edition, 1986

Its chapter on Electronic Mail System architectures is still valid 
today, there are also discussions on email security still valid today 
(i.e. the issue of anonymous senders and the forging potential).

It might worth your time to see if there are newer editions or grab 
the old one and see how he approached the subject.

--

David MacQuigg wrote:
> 
> Hector Santos wrote:
>> In my view, you have an over simplification and Crocker's doc is 
>> attempt to model a more complex integrated world. Its one view abeit 
>> one that attempts to prescribe a model based on STDs and RFCs.  I 
>> think it could of been done in a more readable fashion, like a 
>> Requirements/Optional Grid to start work ala RFC 1153
> 
> Standard textbook models are much simpler than what I am proposing.  The 
> most popular book (Peterson & Davie, 4th ed.) has just a sequence of 
> "gateways", and no good explanation as to why so many are needed.  The 
> two reasons given are 1) The recipient does not want to disclose the 
> actual host on which he reads his email, and 2) The recipient's machine 
> may not always be running, and a "gateway" can hold the message until it 
> is ready to be delivered.
> 
> What I'm looking for is a model that is almost as simple, but a better 
> foundation to understanding real systems.  We have maybe half a week in 
> a 3-unit class on Computer Networks, so we clearly can't cover all the 
> details in email-arch.
> 
>> I do think, in my opinion, your first illustration is pretty 
>> fundamental and much easier to understand, grasp without reading the 
>> context.  IMO, Dave's doc is too overwhelming for MOST people to read 
>> - totally only useful for highly IETF trained geeks.
> 
> My primary goal is optimizing the model for students.  A secondary goal 
> is conformity with standards.  There is always a tradeoff.  If we 
> simplify too much, students will not learn how real systems work.  If we 
> add too much detail, or use jargon instead of plain English, students 
> will learn less of the fundamentals that are needed long after passing a 
> test.
> 
> I'm looking for constructive criticism.  If you believe the model is 
> oversimplified, give me an example of an important system that the model 
> should cover.  If you think you can improve on the terminology, give me 
> some specific alternatives.
> 
> The model is still work-in-progress, but the most complete description 
> is at http://open-mail.org/MHSmodels.html
> 

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Mon, 18 May 2009 10:54:00 +0200
From: Alessandro Vesely <[email-masked]>
To: David MacQuigg <[email-masked]>
CC: [email-masked]
Subject: Re: Email System Model
Sender: [email-masked]

David MacQuigg wrote:
> Hector Santos wrote:
>> I do think, in my opinion, your first illustration is pretty 
>> fundamental and much easier to understand, grasp without reading the 
>> context.

+1

> I'm looking for constructive criticism.  If you believe the model is 
> oversimplified, give me an example of an important system that the model 
> should cover.

Backup MXes. Nowadays, having good connections and much spam, backup 
MXes are avoided by the organizations whose networks would require to 
outsource them (while primary MXes are contracted in.) Should 
connections worsen, e.g. for solar activity[1], war, or terrorism, 
those organizations may be in for a hard surprise.

I had hoped that a protocol for configuring forwarding would have 
smoothly lent itself to also configure secondary MXes[2], so as to 
kill both birds with one stone, but either I lack the brain resources 
to see its simplicity, or it is by far more complicate than what I can 
manage in my spare time :-(

--
[1] http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm
[2] http://fixforwarding.org/wiki/boundary#Backup_MXes

Content-class: urn:content-classes:message
Subject: RE: Email System Model
Date: Sun, 17 May 2009 13:00:39 -0500
From: "Cheney, Austin" <[email-masked]>
To: "Hector Santos" <[email-masked]>, "David MacQuigg" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I am completely aware that if a model is too complicated for
understandability of the intended consuming audience it will be
completely ignored.  There are several standards, both on and off the
internet, where this has commonly occurred.  Perhaps the most well known
case is W3C's WAI2 standard, which produced much excessive whining
because of the complexity of practice required to achieve that standard.
Much of this whining was unfounded and did nothing, in this one case,
but extend the development process of the document.  The current ECMA
Script standard, however, is so complex that nobody seem to be capable
of adequately translating it to something that people new to the
language are capable of understanding.  This results in many books on
the subject that are wrong or miss necessary fundamentals.  As a result
people commonly ignore the recommended methods of writing the language
and do whatever the hell they want so long as it does not break
immediately in a single limited context, which will result in a break.

A standard must not, however, strive to limit the subject of its
description merely for the point of simplicity.  When limitation occurs
from such simplification innovation of otherwise unexplored approaches
is blocked even if the stated limitations were unintentional.  In my
opinion blocking innovation is supremely more harmful than a standard
which is ignored because that harm is immediately evident and not
commonly known opposed to harm from an ignored standard which is not
immediately evident but is well known and understood.

As a result I would rather the models be too complex for us mere mortals
to grasp so long as they are accurate and do not impose constraints that
not absolutely necessary.  I understand this is complicated work as such
constraints may appear as common usage and not viewed as a constraining
practice.

Thanks,
Austin Cheney

-----Original Message-----
From: Hector Santos [mailto:[email-masked]]=20
Sent: Sunday, May 17, 2009 9:27 AM
To: David MacQuigg
Cc: [email-masked]; Cheney, Austin
Subject: Re: Email System Model

In my view, you have an over simplification and Crocker's doc is=20
attempt to model a more complex integrated world. Its one view abeit=20
one that attempts to prescribe a model based on STDs and RFCs.  I=20
think it could of been done in a more readable fashion, like a=20
Requirements/Optional Grid to start work ala RFC 1153

I do think, in my opinion, your first illustration is pretty=20
fundamental and much easier to understand, grasp without reading the=20
context.  IMO, Dave's doc is too overwhelming for MOST people to read=20
- totally only useful for highly IETF trained geeks.

--=20
Sincerely

Hector Santos
http://www.santronics.com

David MacQuigg wrote:
>=20
> I'm splitting this off as a separate topic, so we don't distract from=20
> the discussion on email-arch.  In this thread, I welcome discussion of

> the validity of the model at
http://en.citizendium.org/wiki/Email_system.
>=20
> This model is focused on what happens at the administrative level in
one=20
> transit through the Mail Handling System, but it can easily extend to=20
> systems involving multiple transits.   To model the situation Austin=20
> describes, I would put two "one-transit" models in series.
>=20
> Author =3D=3D> MSA/Transmitter --> / --> Receiver/MDA =3D=3D> Mediator
>=20
> Mediator =3D=3D> MSA/Transmitter --> / --> Receiver/MDA =3D=3D> Author
>=20
> The Mediator is a separate user-level Actor, even if it is automated.

> The final Recipient is the original Author.
>=20
> I'm not sure if I fully understand Austin's concern, so I don't know
if=20
> more elaboration of the model will help.  A model is only as good as
its=20
> ability to clarify real-world systems, helping with questions like
"What=20
> happens if ...", or "How should I ...".
>=20
> Best Regards,
> David MacQuigg
>=20
>=20
> Cheney, Austin wrote:
>> David MacQuigg,
>>
>> One difference that I see is an inferred conceptual implementation
that
>> is explicitly not presumed in your model, while being completely
>> unmentioned or challenged in David Crocker's models.  This inferred
>> conceptual implementation is that a mail server is a mediator in the
>> communication process between author and intended recipient, but a
mail
>> server can become an participant if were acting as an application
>> response.
>>
>> Let me demonstrate this in the model of software as a service.
Suppose
>> I were communicating with a known destination, such as a retailer,
who
>> receives and replies to mail as an automated application system.  At
the
>> same time another content application system is installed on the
local
>> mail server of this intended recipient that is capable of
intercepting
>> communications, making decisions upon those communication, and
sending
>> automated responses that beg further communication from the initial
>> author.  In this model application programming and scripting can be
>> running in response to human supplied communications from the
>> originating author, while those same applications can also be
relaying
>> data relevant only to the distant end to the intended recipient for
>> status responses and session content details.
>>
>> In that model the mail server of the distant end transforms from a
>> mediator to an intermediate responding agent.  Such a model could
allow
>> things such as cloud computing or ecommerce.  It is not practiced by
>> anybody, because a definable characteristic that is uniformly
described
>> and universally understood would have to exist in the content to
provide
>> such a hook for application engagement.
>>
>> So, in summary, a mail transfer agent MUST NOT be presumed to be
>> separate from a designated point of intended receipt.  Crocker's
models
>> do not mention or challenge this concept, but your model does imply
such
>> a challenge.
>>
>> Thanks,
>> Austin Cheney
>>  =20
>=20
>=20
>=20

Date: Sun, 17 May 2009 10:22:51 -0700
From: David MacQuigg <[email-masked]>
To: [email-masked]
Subject: Email System Model
Sender: [email-masked]

Hector Santos wrote:
> In my view, you have an over simplification and Crocker's doc is 
> attempt to model a more complex integrated world. Its one view abeit 
> one that attempts to prescribe a model based on STDs and RFCs.  I 
> think it could of been done in a more readable fashion, like a 
> Requirements/Optional Grid to start work ala RFC 1153

Standard textbook models are much simpler than what I am proposing.  The 
most popular book (Peterson & Davie, 4th ed.) has just a sequence of 
"gateways", and no good explanation as to why so many are needed.  The 
two reasons given are 1) The recipient does not want to disclose the 
actual host on which he reads his email, and 2) The recipient's machine 
may not always be running, and a "gateway" can hold the message until it 
is ready to be delivered.

What I'm looking for is a model that is almost as simple, but a better 
foundation to understanding real systems.  We have maybe half a week in 
a 3-unit class on Computer Networks, so we clearly can't cover all the 
details in email-arch.

> I do think, in my opinion, your first illustration is pretty 
> fundamental and much easier to understand, grasp without reading the 
> context.  IMO, Dave's doc is too overwhelming for MOST people to read 
> - totally only useful for highly IETF trained geeks.

My primary goal is optimizing the model for students.  A secondary goal 
is conformity with standards.  There is always a tradeoff.  If we 
simplify too much, students will not learn how real systems work.  If we 
add too much detail, or use jargon instead of plain English, students 
will learn less of the fundamentals that are needed long after passing a 
test.

I'm looking for constructive criticism.  If you believe the model is 
oversimplified, give me an example of an important system that the model 
should cover.  If you think you can improve on the terminology, give me 
some specific alternatives.

The model is still work-in-progress, but the most complete description 
is at http://open-mail.org/MHSmodels.html

Best Regards,

************************************************************     *
* David MacQuigg, PhD    email: macquigg at ece.arizona.edu   *  *
* Research Associate                phone: USA 520-721-4583   *  *  *
* ECE Department, University of Arizona                       *  *  *
*                                 9320 East Mikelyn Lane       * * *
* http://purl.net/macquigg        Tucson, Arizona 85710          *
************************************************************     *

Date: Sun, 17 May 2009 10:26:40 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: David MacQuigg <[email-masked]>
CC:  [email-masked], "Cheney, Austin" <[email-masked]>
Subject: Re: Email System Model
Sender: [email-masked]

In my view, you have an over simplification and Crocker's doc is 
attempt to model a more complex integrated world. Its one view abeit 
one that attempts to prescribe a model based on STDs and RFCs.  I 
think it could of been done in a more readable fashion, like a 
Requirements/Optional Grid to start work ala RFC 1153

I do think, in my opinion, your first illustration is pretty 
fundamental and much easier to understand, grasp without reading the 
context.  IMO, Dave's doc is too overwhelming for MOST people to read 
- totally only useful for highly IETF trained geeks.

-- 
Sincerely

Hector Santos
http://www.santronics.com

David MacQuigg wrote:
> 
> I'm splitting this off as a separate topic, so we don't distract from 
> the discussion on email-arch.  In this thread, I welcome discussion of 
> the validity of the model at http://en.citizendium.org/wiki/Email_system.
> 
> This model is focused on what happens at the administrative level in one 
> transit through the Mail Handling System, but it can easily extend to 
> systems involving multiple transits.   To model the situation Austin 
> describes, I would put two "one-transit" models in series.
> 
> Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Mediator
> 
> Mediator ==> MSA/Transmitter --> / --> Receiver/MDA ==> Author
> 
> The Mediator is a separate user-level Actor, even if it is automated.  
> The final Recipient is the original Author.
> 
> I'm not sure if I fully understand Austin's concern, so I don't know if 
> more elaboration of the model will help.  A model is only as good as its 
> ability to clarify real-world systems, helping with questions like "What 
> happens if ...", or "How should I ...".
> 
> Best Regards,
> David MacQuigg
> 
> 
> Cheney, Austin wrote:
>> David MacQuigg,
>>
>> One difference that I see is an inferred conceptual implementation that
>> is explicitly not presumed in your model, while being completely
>> unmentioned or challenged in David Crocker's models.  This inferred
>> conceptual implementation is that a mail server is a mediator in the
>> communication process between author and intended recipient, but a mail
>> server can become an participant if were acting as an application
>> response.
>>
>> Let me demonstrate this in the model of software as a service.  Suppose
>> I were communicating with a known destination, such as a retailer, who
>> receives and replies to mail as an automated application system.  At the
>> same time another content application system is installed on the local
>> mail server of this intended recipient that is capable of intercepting
>> communications, making decisions upon those communication, and sending
>> automated responses that beg further communication from the initial
>> author.  In this model application programming and scripting can be
>> running in response to human supplied communications from the
>> originating author, while those same applications can also be relaying
>> data relevant only to the distant end to the intended recipient for
>> status responses and session content details.
>>
>> In that model the mail server of the distant end transforms from a
>> mediator to an intermediate responding agent.  Such a model could allow
>> things such as cloud computing or ecommerce.  It is not practiced by
>> anybody, because a definable characteristic that is uniformly described
>> and universally understood would have to exist in the content to provide
>> such a hook for application engagement.
>>
>> So, in summary, a mail transfer agent MUST NOT be presumed to be
>> separate from a designated point of intended receipt.  Crocker's models
>> do not mention or challenge this concept, but your model does imply such
>> a challenge.
>>
>> Thanks,
>> Austin Cheney
>>   
> 
> 
> 

Date: Fri, 15 May 2009 20:06:49 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SMTP Interest Group <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail 	Architecture) to Proposed Standard
Sender: [email-masked]

FYI,

> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-crocker-email-arch-13

and the usual pretty stuff (and diff) are at:

   <http://bbiw.net/recent.html#emailarch>

d/

-------- Original Message --------
Subject: New Version Notification for draft-crocker-email-arch-13
Date: Fri, 15 May 2009 19:57:43 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]

A new version of I-D, draft-crocker-email-arch-13.txt has been successfuly
submitted by Dave Crocker and posted to the IETF repository.

Filename:	 draft-crocker-email-arch
Revision:	 13
Title:		 Internet Mail Architecture
Creation_date:	 2009-05-15
WG ID:		 Independent Submission
Number_of_pages: 54

Abstract:
Over its thirty-five year history, Internet Mail has changed
significantly in scale and complexity, as it has become a global
infrastructure service.  These changes have been evolutionary, rather
than revolutionary, reflecting a strong desire to preserve both its
installed base and its usefulness.  To collaborate productively on
this large and complex system, all participants must work from a
common view of it and use a common language to describe its
components and the interactions among them.  But the many differences
in perspective currently make it difficult to know exactly what
another participant means.  To serve as the necessary common frame of
reference, this document describes the enhanced Internet Mail
architecture, reflecting the current service.

The IETF Secretariat.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 15 May 2009 20:04:54 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SMTP Interest Group <[email-masked]>
Subject: [Fwd: New Version Notification for draft-crocker-email-arch-13]
Sender: [email-masked]

> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-crocker-email-arch-13

and the usual pretty stuff (and diff) are at:

   <http://bbiw.net/recent.html#emailarch>

d/

-------- Original Message --------
Subject: New Version Notification for draft-crocker-email-arch-13
Date: Fri, 15 May 2009 19:57:43 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]

A new version of I-D, draft-crocker-email-arch-13.txt has been successfuly 
submitted by Dave Crocker and posted to the IETF repository.

Filename:	 draft-crocker-email-arch
Revision:	 13
Title:		 Internet Mail Architecture
Creation_date:	 2009-05-15
WG ID:		 Independent Submission
Number_of_pages: 54

Abstract:
Over its thirty-five year history, Internet Mail has changed
significantly in scale and complexity, as it has become a global
infrastructure service.  These changes have been evolutionary, rather
than revolutionary, reflecting a strong desire to preserve both its
installed base and its usefulness.  To collaborate productively on
this large and complex system, all participants must work from a
common view of it and use a common language to describe its
components and the interactions among them.  But the many differences
in perspective currently make it difficult to know exactly what
another participant means.  To serve as the necessary common frame of
reference, this document describes the enhanced Internet Mail
architecture, reflecting the current service.

The IETF Secretariat.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 15 May 2009 13:47:46 -0700 (PDT)
From: [email-masked]
Subject: Re: orcpt=x;y
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> [email-masked] writes:
> >> This seems odd.
> >
> > I fail to see anything odd about it.

> Don't you think it's odd to explictly allow labeling non-822 addresses
> as rfc822?

No. It's a question of priorities. THey're supposed to be valid RFC 822
addresses, but having an accurate indication of the original address - legal or
not - trumps the desire for syntactic conformity, especially when enforcing
that conformity has the very real possibility of breaking the key function
this field provides.

I note in passing that we do this sort of thing with names all the time. Just
as one exmaple, a message/rfc822 MIME object doesn't have to conform to all the
rules RFC 822 imposes.

> I mean, I see the argument for allowing anything, but to then label that
> rfc822 seems very odd.

The name provides an indication of what it should look like. I see that as
having value in and of itself.

				Ned

Date: Fri, 15 May 2009 21:49:13 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: orcpt=x;y
Cc: [email-masked]
Sender: [email-masked]

[email-masked] writes:
>> This seems odd.
>
> I fail to see anything odd about it.

Don't you think it's odd to explictly allow labeling non-822 addresses 
as rfc822?

I mean, I see the argument for allowing anything, but to then label that 
rfc822 seems very odd.

> So "hands off" really is the best policy here.

(JFYI, I wasn't suggesting anything else. My actual problem came up 
while comparing addresses. Is this address equal to that, is this 
address in that set, that kind of thing.)

> I will say that if there are agents out there that are sufficiently up 
> to date to generate ORCPT but still don't know how to present a 
> syntactially valid RCPT TO, well, that's pretty unfortunate.

Such is the world.

Arnt

Date: Fri, 15 May 2009 10:47:56 -0700 (PDT)
From: [email-masked]
Subject: Re: orcpt=x;y
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> RFCs 1891 and 3461 both talk about address types and the original
> address. I quote 3461 at length:

>     The "addr-type" portion MUST be an IANA-registered electronic mail
>     address-type (as defined in [3]), while the "xtext" portion contains
>     an encoded representation of the original recipient address using the
>     rules in section 5 of this document.  The entire ORCPT parameter MAY
>     be up to 500 characters in length.

> I found http://www.iana.org/assignments/mail-parameters, which contains
> «MAIL SYSTEM NAMES and ADDRESS TYPES», but that registry only contains
> one entry, mcimail. Is that the right registry at all?

>     When initially submitting a message via SMTP, if the ORCPT parameter
>     is used, it MUST contain the same address as the RCPT TO address
>     (unlike the RCPT TO address, the ORCPT parameter will be encoded as
>     xtext).  Likewise, when a mailing list submits a message via SMTP to
>     be distributed to the list subscribers, if ORCPT is used, the ORCPT
>     parameter MUST match the new RCPT TO address of each recipient, not
>     the address specified by the original sender of the message.)

>     The "addr-type" portion of the original-recipient-address is used to
>     indicate the "type" of the address which appears in the ORCPT
>     parameter value.  However, the address associated with the ORCPT
>     keyword is NOT constrained to conform to the syntax rules for that
>     "addr-type".

>     Ideally, the "xtext" portion of the original-recipient-address should
>     contain, in encoded form, the same sequence of characters that the
>     sender used to specify the recipient.  However, for a message
>     gatewayed from an environment (such as X.400) in which a recipient
>     address is not a simple string of printable characters, the
>     representation of recipient address must be defined by a
>     specification for gatewaying between DSNs and that environment.

> In other words, if someone connects to localhost port 587 and says
> something like

>     RCPT TO:<fred> ORCTP=rfc822;fred

Which of course is a syntax error (the RCPT TO parameter, not the ORCPT
parameter), which RFC 4409 says SHOULD be rejected (section 5.1). So by
accepting this you are already operating outside of documented best practice.

A more interesting example is actually:

      RCPT TO:<fred@shortform> ORCPT=rfc822;fred@shortform

> then the submit server may turn around and send the mail onwards using either

>     RCPT TO:<[email-masked]> ORCTP=rfc822;fred

> or

>     RCPT TO:<[email-masked]> ORCPT=rfc822;fred

> but not

>     RCPT TO:<[email-masked]> ORCPT=rfc822;[email-masked]

> ?

> This seems odd.

I fail to see anything odd about it. The purpose of the orcpt parameter is to
track original address forms so that nondelivery reports will contaiin
something that can be correlated with whatever the originating  agent
specified. So this is effectively a replace-only field, and the main case where
replacement uccors is when a list expands and replaces the list address with
one or more list recipient addresses in the envelope.

To be sure, it is entirely possible that a submittor that generates addresses
consisting solely of a local part, or addresses containing shortform domain
names, has created something that, when returned in a DSN, won't be
correlatable. But there is in general no way for downstream agents to know that
or to know what fixups, if any, are applicable. So "hands off" really is the
best policy here.

I will say that if there are agents out there that are sufficiently up to date
to generate ORCPT but still don't know how to present a syntactially valid RCPT
TO, well, that's pretty unfortunate.

				Ned

Date: Fri, 15 May 2009 09:11:51 -0700
From: David MacQuigg <[email-masked]>
To: [email-masked]
CC: "Cheney, Austin" <[email-masked]>
Subject: Email System Model
Sender: [email-masked]

I'm splitting this off as a separate topic, so we don't distract from 
the discussion on email-arch.  In this thread, I welcome discussion of 
the validity of the model at http://en.citizendium.org/wiki/Email_system.

This model is focused on what happens at the administrative level in one 
transit through the Mail Handling System, but it can easily extend to 
systems involving multiple transits.   To model the situation Austin 
describes, I would put two "one-transit" models in series.

Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Mediator

Mediator ==> MSA/Transmitter --> / --> Receiver/MDA ==> Author

The Mediator is a separate user-level Actor, even if it is automated.  
The final Recipient is the original Author.

I'm not sure if I fully understand Austin's concern, so I don't know if 
more elaboration of the model will help.  A model is only as good as its 
ability to clarify real-world systems, helping with questions like "What 
happens if ...", or "How should I ...".

Best Regards,
David MacQuigg

Cheney, Austin wrote:
> David MacQuigg,
>
> One difference that I see is an inferred conceptual implementation that
> is explicitly not presumed in your model, while being completely
> unmentioned or challenged in David Crocker's models.  This inferred
> conceptual implementation is that a mail server is a mediator in the
> communication process between author and intended recipient, but a mail
> server can become an participant if were acting as an application
> response.
>
> Let me demonstrate this in the model of software as a service.  Suppose
> I were communicating with a known destination, such as a retailer, who
> receives and replies to mail as an automated application system.  At the
> same time another content application system is installed on the local
> mail server of this intended recipient that is capable of intercepting
> communications, making decisions upon those communication, and sending
> automated responses that beg further communication from the initial
> author.  In this model application programming and scripting can be
> running in response to human supplied communications from the
> originating author, while those same applications can also be relaying
> data relevant only to the distant end to the intended recipient for
> status responses and session content details.
>
> In that model the mail server of the distant end transforms from a
> mediator to an intermediate responding agent.  Such a model could allow
> things such as cloud computing or ecommerce.  It is not practiced by
> anybody, because a definable characteristic that is uniformly described
> and universally understood would have to exist in the content to provide
> such a hook for application engagement.
>
> So, in summary, a mail transfer agent MUST NOT be presumed to be
> separate from a designated point of intended receipt.  Crocker's models
> do not mention or challenge this concept, but your model does imply such
> a challenge.
>
> Thanks,
> Austin Cheney
>   

Date: Fri, 15 May 2009 09:11:16 -0700
From: David MacQuigg <[email-masked]>
To: [email-masked]
Subject: Re: email-arch intro
Sender: [email-masked]

Pete Resnick wrote:
> On 5/14/09 at 3:11 PM -0700, David MacQuigg wrote:
>> On 5/14/09 Pete Resnick wrote:
>>
>>> We want the architecture to be prescriptive insofar as *any* IETF 
>>> document is prescriptive in that it helps interoperability.

>> My first reaction to Pete's intro was - Yea, that's great, says it 
>> all.  Now I'm not sure what it means.  Upon careful reading, it looks 
>> like it is intending to protect protocols and implementations (but 
>> not anything else) from anyone wanting to wield this document as a 
>> "club".  Why not just say "This document is intended to describe a 
>> complex real-world system, and provide a model and terminology that 
>> will improve our understanding of that system.  It is not intended to 
>> add additional requirements to regular IETF standards, or enforce 
>> conformity in any way."  If the model is useful, as I believe it is, 
>> it will be widely used.  If not, it won't become an impediment to 
>> development of other models.
>> [...]
>> What I worry about is a document like this becoming a basis for 
>> obstructive arguments over terminology.  I would like to say in some 
>> future discussion - "Let's use the terminology from RFC-<whatever 
>> number it gets assigned>, but with the following differences:"  Then 
>> add a few definitions appropriate to the topic at hand.
>
> So, I'm going to try and split a relatively fine hair here, so bear 
> with me:
>
> - I *don't* want this document to be used as a club against 
> well-established (and well-understood) protocols. To use a personal 
> favorite example, RFC 5321 and current implementations have a lot of 
> "nuance" when it comes to address correction , forwarding, aliasing, 
> etc. Some examples are "ReSender", or "Gateway", or "Alias", or 
> "Mailing List" from email-arch, and some simply don't fit cleanly in 
> one of those architectural categories. However, RFC 5321 explains how 
> implementations are to deal with each of them and describes the edge 
> cases. It is not reasonable to say, "RFC 5321 must be corrected so 
> that it agrees with the architecture down to the last detail." Where 
> they disagree, the protocol with the explanation wins the day.
>
> - I *do* want this document to be used as a club against proposed 
> protocols, especially when they have no implementation base, if those 
> protocols differ significantly from the architecture *without any 
> explanation*. When someone comes along and writes a protocol or 
> implementation that assumes that the RFC5321.MailFrom is the author of 
> the text of the message, I want to be able to say, "Look dude! That's 
> not what RFC5321.MailFrom is for. Go read the bloody architecture and 
> get your mind right, or give me a long interesting explanation about 
> how the state of the world you live in is different than what the 
> architecture says and convince me that your use is reasonable."

I understand the need to set a high hurdle for proposed protocols which 
differ significantly from existing standards, and  your example of the 
MailFrom address is a good one.  A clear standard on the purpose of this 
address would have avoided a major debate with supporters of the SPF 
protocol.

What I don't understand is the need for a new standard to re-state what 
should be in the existing standards.  I would rather see the purpose of 
MailFrom clarified in RFC-5321, and not worry about the exact wording in 
email-arch.  (It's still not clear.)  If we can't get it clear in the 
primary standard relating to this protocol, slipping clarifications into 
lesser-known standards might only add more confusion, and not resolve 
the issue.

We can avoid this problem by keeping the document as a best effort to 
explain "the way things are", rather than what I am hearing now for the 
first time, "the way things ought to be".  The vast majority of 
Forwarders do not re-write the MailFrom address, contrary to the 
expectations of the SPF community.  You can state that as a fact, 
without saying "and that's the way it should be".

I value email-arch for its explanation of the way email systems work, 
not its effort to standardize things that have been unclear.  Perhaps I 
am misunderstanding what it is you are wanting to standardize.  If it is 
models and terminology, I think that would be a mistake.  Better models 
for email systems are still being developed.

Best Regards,
David MacQuigg

Date: Fri, 15 May 2009 10:46:14 -0400
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: orcpt=x;y
Sender: [email-masked]

--On Friday, May 15, 2009 12:39 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

>...
>> I am still trying to figure out what kind of animal "mcimail"
>> is and  whether it needs to be added to this registry as well.
> 
> MCImail was a proprietary thing maybe 20 years ago. I don't
> know when it disappeared for good, but it's gone now so I
> think not adding it is fair, no matter what the purpose of the
> entry once was.
>...

It was an X.400 ADMD (with some considerable traffic in that
role) as well as a proprietary email and email to paper and fax
system).  As an X.400 ADMD, it was capable of routing X.400 mail
to and from other X.400 systems as well as accepting and sending
X.400 traffic for its own PRMD and organizational customers.
I'm not sure whether one can dismiss X.400-compliant systems as
"proprietary" -- it didn't use MUAs that were visibly compliant
to those parts of the X.400 specs, but almost no one else did
either.  It also had an Internet gateway (one of the first from
a commercial email system) which, during at least most of its
life, went via the X.400 interface and syntax (probably the RFC
987ff specs, rather than the MIXER one).  It disappeared for
good in the last half of the 90s.   Perhaps ironically, Dave
Crocker had a design role in getting it set up and initiated and
I had some role in the eventual shutdown.

The service is gone, the ADMD is gone operationally, and MCI is
gone so, on that basis, it would be safe to treat the
registration as historic.   On the other hand, I doubt that the
ADMD was ever formally de-registered and, whether they know it
or not, that registration probably passed to either Cable and
Wireless (as part of the internetMCI deal) or Verizon (as part
of acquisition of what was left of MCI after the WorldCom
debacle).  So, in principle, if X.400 ever had a resurgence, the
ADMD might reappear although it would surprise me.

That should answer the "what sort of beast" question.  Whether
it should be moved to the newer registry depends on what one
thinks of the future (or even the present) of X.400 systems as
participants in Internet message handling.

   john

Date: Fri, 15 May 2009 11:55:39 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: orcpt=x;y
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Use <http://www.iana.org/assignments/dsn-types/dsn-types.xhtml>
>
> Oh, now I see it. I looked in the "mail" section of=20
> http://www.iana.org/protocols/, not the "dsn" section.
>
>> I am still trying to figure out what kind of animal "mcimail" is and=20
>> whether it needs to be added to this registry as well.
>
> MCImail was a proprietary thing maybe 20 years ago. I don't know when=20
> it disappeared for good, but it's gone now so I think not adding it is=20
> fair, no matter what the purpose of the entry once was.

I've asked my boss (who wrote MIXER RFCs) for clarifications.

>>>    Ideally, the "xtext" portion of the original-recipient-address   =20
>>> should contain, in encoded form, the same sequence of characters   =20
>>> that the sender used to specify the recipient.
>>>    ...
>>
> ...
>
>> Hmm. I can see how you came to this conclusion. But I think in your=20
>> example the original email address isn't valid and was fixed by the=20
>> submission server. So I don't see any problem with fixing the=20
>> corresponding ORCPT at the same time.
>
> I don't see a problem with that either, but in my reading the RFC=20
> recommends that people don't, and I wonder why.
>
> (I ran across this when someone's code forwarded without adding a=20
> domain, and much later, my code said, =ABuh, I have a lone localpart=20
> here and no scope for it=BB.)

Actually, I remembered that there is a rule in one of DSN documents=20
saying that if you can't parse an ORCPT value, you should just leave it=20
as is.
So leaving "rfc822;fred" is Ok. Maybe it is even better, as ORCPT is=20
supposed to preserve the original value as received by the server.

Date: Fri, 15 May 2009 12:39:09 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: orcpt=x;y
Sender: [email-masked]

Alexey Melnikov writes:
> Use <http://www.iana.org/assignments/dsn-types/dsn-types.xhtml>

Oh, now I see it. I looked in the "mail" section of=20
http://www.iana.org/protocols/, not the "dsn" section.

> I am still trying to figure out what kind of animal "mcimail" is and=20
> whether it needs to be added to this registry as well.

MCImail was a proprietary thing maybe 20 years ago. I don't know when it=20
disappeared for good, but it's gone now so I think not adding it is=20
fair, no matter what the purpose of the entry once was.

>>    Ideally, the "xtext" portion of the original-recipient-address=20
>>    should contain, in encoded form, the same sequence of characters=20
>>    that the sender used to specify the recipient.
>>    ...
...
> Hmm. I can see how you came to this conclusion. But I think in your=20
> example the original email address isn't valid and was fixed by the=20
> submission server. So I don't see any problem with fixing the=20
> corresponding ORCPT at the same time.

I don't see a problem with that either, but in my reading the RFC=20
recommends that people don't, and I wonder why.

(I ran across this when someone's code forwarded without adding a=20
domain, and much later, my code said, =ABuh, I have a lone localpart =
here=20
and no scope for it=BB.)

Arnt

Date: Fri, 15 May 2009 11:12:26 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: orcpt=x;y
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> RFCs 1891 and 3461 both talk about address types and the original=20
> address. I quote 3461 at length:
>
>    The "addr-type" portion MUST be an IANA-registered electronic mail
>    address-type (as defined in [3]), while the "xtext" portion contains
>    an encoded representation of the original recipient address using the
>    rules in section 5 of this document.  The entire ORCPT parameter MAY
>    be up to 500 characters in length.
>
> I found http://www.iana.org/assignments/mail-parameters, which=20
> contains =ABMAIL SYSTEM NAMES and ADDRESS TYPES=BB, but that registry only=
=20
> contains one entry, mcimail. Is that the right registry at all?

No, it isn't.
Use <http://www.iana.org/assignments/dsn-types/dsn-types.xhtml>

I am still trying to figure out what kind of animal "mcimail" is and=20
whether it needs to be added to this registry as well.

>    When initially submitting a message via SMTP, if the ORCPT parameter
>    is used, it MUST contain the same address as the RCPT TO address
>    (unlike the RCPT TO address, the ORCPT parameter will be encoded as
>    xtext).  Likewise, when a mailing list submits a message via SMTP to
>    be distributed to the list subscribers, if ORCPT is used, the ORCPT
>    parameter MUST match the new RCPT TO address of each recipient, not
>    the address specified by the original sender of the message.)
>
>    The "addr-type" portion of the original-recipient-address is used to
>    indicate the "type" of the address which appears in the ORCPT
>    parameter value.  However, the address associated with the ORCPT
>    keyword is NOT constrained to conform to the syntax rules for that
>    "addr-type".
>
>    Ideally, the "xtext" portion of the original-recipient-address should
>    contain, in encoded form, the same sequence of characters that the
>    sender used to specify the recipient.  However, for a message
>    gatewayed from an environment (such as X.400) in which a recipient
>    address is not a simple string of printable characters, the
>    representation of recipient address must be defined by a
>    specification for gatewaying between DSNs and that environment.
>
> In other words, if someone connects to localhost port 587 and says=20
> something like
>
>    RCPT TO:<fred> ORCTP=3Drfc822;fred
>
> then the submit server may turn around and send the mail onwards using=20
> either
>
>    RCPT TO:<[email-masked]> ORCTP=3Drfc822;fred
>
> or
>
>    RCPT TO:<[email-masked]> ORCPT=3Drfc822;fred
>
> but not
>
>    RCPT TO:<[email-masked]> ORCPT=3Drfc822;[email-masked]
>
> ?

Hmm. I can see how you came to this conclusion. But I think in your=20
example the original email address isn't valid and was fixed by the=20
submission server. So I don't see any problem with fixing the=20
corresponding ORCPT at the same time.

> This seems odd.

Date: Fri, 15 May 2009 09:55:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: orcpt=x;y
Sender: [email-masked]

RFCs 1891 and 3461 both talk about address types and the original=20
address. I quote 3461 at length:

    The "addr-type" portion MUST be an IANA-registered electronic mail
    address-type (as defined in [3]), while the "xtext" portion contains
    an encoded representation of the original recipient address using the
    rules in section 5 of this document.  The entire ORCPT parameter MAY
    be up to 500 characters in length.

I found http://www.iana.org/assignments/mail-parameters, which contains=20
=ABMAIL SYSTEM NAMES and ADDRESS TYPES=BB, but that registry only =
contains=20
one entry, mcimail. Is that the right registry at all?

    When initially submitting a message via SMTP, if the ORCPT parameter
    is used, it MUST contain the same address as the RCPT TO address
    (unlike the RCPT TO address, the ORCPT parameter will be encoded as
    xtext).  Likewise, when a mailing list submits a message via SMTP to
    be distributed to the list subscribers, if ORCPT is used, the ORCPT
    parameter MUST match the new RCPT TO address of each recipient, not
    the address specified by the original sender of the message.)

    The "addr-type" portion of the original-recipient-address is used to
    indicate the "type" of the address which appears in the ORCPT
    parameter value.  However, the address associated with the ORCPT
    keyword is NOT constrained to conform to the syntax rules for that
    "addr-type".

    Ideally, the "xtext" portion of the original-recipient-address should
    contain, in encoded form, the same sequence of characters that the
    sender used to specify the recipient.  However, for a message
    gatewayed from an environment (such as X.400) in which a recipient
    address is not a simple string of printable characters, the
    representation of recipient address must be defined by a
    specification for gatewaying between DSNs and that environment.

In other words, if someone connects to localhost port 587 and says=20
something like

    RCPT TO:<fred> ORCTP=3Drfc822;fred

then the submit server may turn around and send the mail onwards using =
either

    RCPT TO:<[email-masked]> ORCTP=3Drfc822;fred

or

    RCPT TO:<[email-masked]> ORCPT=3Drfc822;fred

but not

    RCPT TO:<[email-masked]> ORCPT=3Drfc822;[email-masked]

?

This seems odd.

Arnt

Date: Fri, 15 May 2009 01:14:42 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Pete Resnick <[email-masked]>
CC: David MacQuigg <[email-masked]>, [email-masked], SM <[email-masked]>, [email-masked]
Subject: Re: email-arch intro
Sender: [email-masked]

Pete Resnick wrote:
> 

> - I *do* want this document to be used as a club against proposed 
> protocols, especially when they have no implementation base, if those 
> protocols differ significantly from the architecture *without any 
> explanation*. When someone comes along and writes a protocol or 
> implementation that assumes that the RFC5321.MailFrom is the author of 
> the text of the message, I want to be able to say, "Look dude! That's 
> not what RFC5321.MailFrom is for. Go read the bloody architecture and 
> get your mind right, or give me a long interesting explanation about how 
> the state of the world you live in is different than what the 
> architecture says and convince me that your use is reasonable."

Architecturally (flow chart wise), the document is fine, but I think 
the better "billy club example" for what clearly sticks out is the 
high potential when someone says based on it:

        "Dude, aren't you sending a DSN?"
        or
        "Dude, aren't you using Sieve?"
        "Dude, why did your Sieve process reject my mail?"

and you says:

       "Dude, we am not using any of those."

We had a support call just the other day that touch base with it. A 
company who walks, talks, smells like a spammer who didn't know about 
protocols and methods but was asked by a receiver to give more details 
showing why he was being blocked by them (no 200 response was what we 
finally find out).  What details did he want when they both didn't 
even understand that no one was answering the door. Yet, they were 
throwing buzz words out like DSN, at each other and at us.  What he 
got from our smtp server was an exhausted 72 attempts retry bounce 
message.

It also curious to me what he blurted out.

     "I've been told for the last two years or say, reputation
      is becoming more important. Is there anything we can do
      in the software to improve it?"

So is the document architecturally dated for this new era of this sort 
of mindset?

Don't get me wrong, the document is useful and needed. My only real 
nit (if there is one) is that it can be used as a checklist even 
against the well established, maybe not by your definition of "well 
established," but established nonetheless.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 14 May 2009 16:50:03 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
CC: SM <[email-masked]>
Subject: Re: email-arch intro
Sender: [email-masked]

Pete Resnick wrote:
> - I *do* want this document to be used as a club against proposed 
> protocols, 
...
>     I want to be able to say, "Look dude! That's 
> not what RFC5321.MailFrom is for. Go read the bloody architecture and 
> get your mind right, or give me a long interesting explanation about how 
> the state of the world you live in is different than what the 
> architecture says and convince me that your use is reasonable."

Yup.

> The architecture will develop, it will be refined over time, and it 
> ought to be prescriptive for how to write an interoperable protocol in 
> the land of email. That sounds to me like a standards-track document. 

Yup.

> That's OK. We like rough edges.

Yup.

> That's what I'm hoping that intro expresses.

drum roll.

Exactly!

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Content-class: urn:content-classes:message
Subject: RE: email-arch intro
Date: Thu, 14 May 2009 18:23:17 -0500
From: "Cheney, Austin" <[email-masked]>
To: "David MacQuigg" <[email-masked]>, <[email-masked]>
Cc: "Pete Resnick" <[email-masked]>, "SM" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

David MacQuigg,

One difference that I see is an inferred conceptual implementation that
is explicitly not presumed in your model, while being completely
unmentioned or challenged in David Crocker's models.  This inferred
conceptual implementation is that a mail server is a mediator in the
communication process between author and intended recipient, but a mail
server can become an participant if were acting as an application
response.

Let me demonstrate this in the model of software as a service.  Suppose
I were communicating with a known destination, such as a retailer, who
receives and replies to mail as an automated application system.  At the
same time another content application system is installed on the local
mail server of this intended recipient that is capable of intercepting
communications, making decisions upon those communication, and sending
automated responses that beg further communication from the initial
author.  In this model application programming and scripting can be
running in response to human supplied communications from the
originating author, while those same applications can also be relaying
data relevant only to the distant end to the intended recipient for
status responses and session content details.

In that model the mail server of the distant end transforms from a
mediator to an intermediate responding agent.  Such a model could allow
things such as cloud computing or ecommerce.  It is not practiced by
anybody, because a definable characteristic that is uniformly described
and universally understood would have to exist in the content to provide
such a hook for application engagement.

So, in summary, a mail transfer agent MUST NOT be presumed to be
separate from a designated point of intended receipt.  Crocker's models
do not mention or challenge this concept, but your model does imply such
a challenge.

Thanks,
Austin Cheney

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David MacQuigg
Sent: Thursday, May 14, 2009 5:11 PM
To: [email-masked]
Cc: Pete Resnick; SM; [email-masked]
Subject: Re: email-arch intro

On 5/14/09 Pete Resnick wrote:
> On 5/14/09 at 6:36 AM -0700, SM wrote:
>> One of the "problems" with the email-arch is that the document does=20
>> not constrain itself to the higher level only.  It would have made=20
>> matters easier if the document was descriptive instead of
prescriptive.
> I disagree, and that is one of the reasons for this intro: We want the

> architecture to be prescriptive insofar as *any* IETF document is=20
> prescriptive in that it helps interoperability.
My first reaction to Pete's intro was - Yea, that's great, says it all.

Now I'm not sure what it means.  Upon careful reading, it looks like it=20
is intending to protect protocols and implementations (but not anything=20
else) from anyone wanting to wield this document as a "club".  Why not=20
just say "This document is intended to describe a complex real-world=20
system, and provide a model and terminology that will improve our=20
understanding of that system.  It is not intended to add additional=20
requirements to regular IETF standards, or enforce conformity in any=20
way."  If the model is useful, as I believe it is, it will be widely=20
used.  If not, it won't become an impediment to development of other
models.

Perhaps an example will help.  I have been developing an=20
"administrative-level" model for email systems, which I view as an=20
extension of Dave's Figure 4.  See=20
http://en.citizendium.org/wiki/Email_system for a more complete=20
description.  I have tried to conform with Dave's terminology, but found

it inadequate to fully describe what is happening at the administrative=20
level.  This doesn't mean Dave's model is wrong, just that it is more=20
focused on the Relay-level, and provides only a very general description

of the "ADMD level".  For a textbook presentation, we need something=20
more than Figure 4, but less than what is in Dave's draft.

What I worry about is a document like this becoming a basis for=20
obstructive arguments over terminology.  I would like to say in some=20
future discussion - "Let's use the terminology from RFC-<whatever number

it gets assigned>, but with the following differences:"  Then add a few=20
definitions appropriate to the topic at hand.

Maybe my worries are un-necessary.  Let's find out now, rather than=20
later.  Is there anyone here who thinks the differences between my model

and Dave's are a problem?  Can you suggest improvements in either model?

Best Regards,

David MacQuigg, PhD
Research Associate
ECE Department, University of Arizona
http://purl.net/macquigg

Date: Thu, 14 May 2009 16:22:54 -0700
To: David MacQuigg <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: email-arch intro
CC: <[email-masked]>, SM <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 5/14/09 at 3:11 PM -0700, David MacQuigg wrote:

>On 5/14/09 Pete Resnick wrote:
>
>>We want the architecture to be prescriptive insofar as *any* IETF 
>>document is prescriptive in that it helps interoperability.
>
>My first reaction to Pete's intro was - Yea, that's great, says it 
>all.  Now I'm not sure what it means.  Upon careful reading, it 
>looks like it is intending to protect protocols and implementations 
>(but not anything else) from anyone wanting to wield this document 
>as a "club".  Why not just say "This document is intended to 
>describe a complex real-world system, and provide a model and 
>terminology that will improve our understanding of that system.  It 
>is not intended to add additional requirements to regular IETF 
>standards, or enforce conformity in any way."  If the model is 
>useful, as I believe it is, it will be widely used.  If not, it 
>won't become an impediment to development of other models.
>[...]
>What I worry about is a document like this becoming a basis for 
>obstructive arguments over terminology.  I would like to say in some 
>future discussion - "Let's use the terminology from RFC-<whatever 
>number it gets assigned>, but with the following differences:"  Then 
>add a few definitions appropriate to the topic at hand.

So, I'm going to try and split a relatively fine hair here, so bear with me:

- I *don't* want this document to be used as a club against 
well-established (and well-understood) protocols. To use a personal 
favorite example, RFC 5321 and current implementations have a lot of 
"nuance" when it comes to address correction , forwarding, aliasing, 
etc. Some examples are "ReSender", or "Gateway", or "Alias", or 
"Mailing List" from email-arch, and some simply don't fit cleanly in 
one of those architectural categories. However, RFC 5321 explains how 
implementations are to deal with each of them and describes the edge 
cases. It is not reasonable to say, "RFC 5321 must be corrected so 
that it agrees with the architecture down to the last detail." Where 
they disagree, the protocol with the explanation wins the day.

- I *do* want this document to be used as a club against proposed 
protocols, especially when they have no implementation base, if those 
protocols differ significantly from the architecture *without any 
explanation*. When someone comes along and writes a protocol or 
implementation that assumes that the RFC5321.MailFrom is the author 
of the text of the message, I want to be able to say, "Look dude! 
That's not what RFC5321.MailFrom is for. Go read the bloody 
architecture and get your mind right, or give me a long interesting 
explanation about how the state of the world you live in is different 
than what the architecture says and convince me that your use is 
reasonable."

The architecture will develop, it will be refined over time, and it 
ought to be prescriptive for how to write an interoperable protocol 
in the land of email. That sounds to me like a standards-track 
document. But like everything else we do here (unlike some other 
standards organizations we all know and love), there are going to be 
rough edges in both protocols and architectures that make them not 
completely align. That's OK. We like rough edges.

That's what I'm hoping that intro expresses.

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

Date: Thu, 14 May 2009 15:11:12 -0700
From: David MacQuigg <[email-masked]>
To: [email-masked]
CC: Pete Resnick <[email-masked]>, SM <[email-masked]>, [email-masked]
Subject: Re: email-arch intro
Sender: [email-masked]

On 5/14/09 Pete Resnick wrote:
> On 5/14/09 at 6:36 AM -0700, SM wrote:
>> One of the "problems" with the email-arch is that the document does 
>> not constrain itself to the higher level only.  It would have made 
>> matters easier if the document was descriptive instead of prescriptive.
> I disagree, and that is one of the reasons for this intro: We want the 
> architecture to be prescriptive insofar as *any* IETF document is 
> prescriptive in that it helps interoperability.
My first reaction to Pete's intro was - Yea, that's great, says it all.  
Now I'm not sure what it means.  Upon careful reading, it looks like it 
is intending to protect protocols and implementations (but not anything 
else) from anyone wanting to wield this document as a "club".  Why not 
just say "This document is intended to describe a complex real-world 
system, and provide a model and terminology that will improve our 
understanding of that system.  It is not intended to add additional 
requirements to regular IETF standards, or enforce conformity in any 
way."  If the model is useful, as I believe it is, it will be widely 
used.  If not, it won't become an impediment to development of other models.

Perhaps an example will help.  I have been developing an 
"administrative-level" model for email systems, which I view as an 
extension of Dave's Figure 4.  See 
http://en.citizendium.org/wiki/Email_system for a more complete 
description.  I have tried to conform with Dave's terminology, but found 
it inadequate to fully describe what is happening at the administrative 
level.  This doesn't mean Dave's model is wrong, just that it is more 
focused on the Relay-level, and provides only a very general description 
of the "ADMD level".  For a textbook presentation, we need something 
more than Figure 4, but less than what is in Dave's draft.

What I worry about is a document like this becoming a basis for 
obstructive arguments over terminology.  I would like to say in some 
future discussion - "Let's use the terminology from RFC-<whatever number 
it gets assigned>, but with the following differences:"  Then add a few 
definitions appropriate to the topic at hand.

Maybe my worries are un-necessary.  Let's find out now, rather than 
later.  Is there anyone here who thinks the differences between my model 
and Dave's are a problem?  Can you suggest improvements in either model?

Best Regards,

David MacQuigg, PhD
Research Associate
ECE Department, University of Arizona
http://purl.net/macquigg

From: "Siegel, Ellen" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 14 May 2009 17:40:31 -0400
Subject: Re: email-arch intro
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Jeff Macdonald wrote:

> Since this seems to be the first document of this type for the IETF, I
> suspect it will take some time to perfect the type of language such a
> document should have. But we have to start from somewhere and I believe
> this is excellent start.

> So +1 to Pete's text.

+1

Having a clear architectural framework and shared terminology should help i=
nform future specifications, and will also help provide context and guidanc=
e to people trying to understand, develop and deploy existing email-related=
 protocol standards.=20

-----
Ellen Siegel
[email-masked]=20

Date: Thu, 14 May 2009 13:11:40 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Jeff Macdonald <[email-masked]>
CC: SM <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: email-arch intro
Sender: [email-masked]

Jeff Macdonald wrote:

>> If I understand correctly, the last part of the last sentence excludes 
>> existing protocols from having to explain the variance.  What you are 
>> proposing is to have designers explain the differences between the 
>> architecture and core protocol documents.  That presumes that the 
>> designers have a good understanding of these documents.  The documents 
>> are already quite lengthy and I think that we will see more 
>> inconsistencies once we go down that path.
> 
> Since this seems to be the first document of this type for the IETF, I
> suspect it will take some time to perfect the type of language such a
> document should have. But we have to start from somewhere and I believe
> this is excellent start.
> 
> So +1 to Pete's text.

To me, this document doesn't excite me, especially when it 
*prescribes* about technology not everyone uses.

Now what would really excite me is the a new updated version of the 
holy bible:

       Requirements for Internet Hosts -- Application and Support
       RFC 1123

That is what help put it all together.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 14 May 2009 10:09:23 -0700
To: SM <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: email-arch intro
CC: <[email-masked]>
Sender: [email-masked]

On 5/14/09 at 6:36 AM -0700, SM wrote:

>One of the "problems" with the email-arch is that the document does 
>not constrain itself to the higher level only.  It would have made 
>matters easier if the document was descriptive instead of 
>prescriptive.

I disagree, and that is one of the reasons for this intro: We want 
the architecture to be prescriptive insofar as *any* IETF document is 
prescriptive in that it helps interoperability. What we don't want is 
for the document to be used to prevent interoperability by forbidding 
reasonable protocol choices. We are not going to completely prevent 
people from being idiots, but it would be nice to use this document 
to say to folks with new protocols, "Get with the program. If you're 
not going to conform to this architecture you better tell us why!" 
while still being able to point to this section and say, "No, we're 
not going to rewrite SMTP just because it does not fully conform to 
the architecture."

I may be a bit more sanguine than you (or Klensin) about this stuff, 
but I think this paragraph addresses those issues.

>>Failure to precisely follow an architecture is not a failure of the 
>>protocol, nor is failure to precisely cast a protocol a failure of 
>>the architecture. Where a protocol varies from the architecture, it 
>>should of course explain the reason for the variance. However, such 
>>variance is not a mark against a protocol: Happily, the IETF 
>>prefers running code to architectural purity.
>
>According to the above paragraph, the protocols (RFC 5321 and RFC 
>5322) should explain why they vary from the architecture.

And they do. There are many places where they describe that they have 
made compromise choices.

>>To different extents, email protocols will conform to this 
>>architecture more or less well. Insofar as this architecture 
>>differs from those protocols, the reasons are generally well 
>>understood and are required for interoperation. The differences are 
>>not a sign that protocols need to be fixed. However, this 
>>architecture is a best attempt at a logical model of Internet 
>>email, and insofar as new protocol development varies from this 
>>architecture, it is necessary for designers to understand those 
>>differences and explain them carefully.
>
>If I understand correctly, the last part of the last sentence 
>excludes existing protocols from having to explain the variance.

No, it's simply saying that new protocols will have to understand why 
they're differing and explain it. It would certainly be nice for 
existing protocols to have those explanations, and as I said earlier, 
they do in many instances (albeit in a "pre-hoc" way).

>What you are proposing is to have designers explain the differences 
>between the architecture and core protocol documents.  That presumes 
>that the designers have a good understanding of these documents. 
>The documents are already quite lengthy and I think that we will see 
>more inconsistencies once we go down that path.

(*Shrug*) I think you underestimate what we can expect from folks.

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

Date: Thu, 14 May 2009 12:52:12 -0400
From: Tony Hansen <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: email-arch intro
Sender: [email-masked]

+1

	Tony Hansen
	[email-masked]

Pete Resnick wrote:
> 
> ...
> So, I think the architecture document needs an intro somewhere saying as
> much. Here's an attempt taken from my conversations with both of them:
> ...

Date: Thu, 14 May 2009 10:29:12 -0600
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Subject: Re: email-arch intro
Sender: [email-masked]

Jeff Macdonald wrote:

> So +1 to Pete's text.

+1

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: 14 May 2009 15:29:37 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: email-arch intro
Organization: 
Cc: [email-masked]
Sender: [email-masked]

> The architecture presented in the document is a model under which we
>believe our protocols work, but there is always a difference between
>architecture and implementation and sometimes it is perfectly fine
>for protocols to break with the architecture.

Your proposed text looks fine.  I hope we don't have to worry about
people appointing themselves as architecture purity police, but this
is a reasonable explanation of why anyone so inclined needn't bother.

R's,
John

Date: Thu, 14 May 2009 10:51:14 -0400
From: Jeff Macdonald <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: transaction commands, errors and 'same state'
Sender: [email-masked]

On Thu, May 07, 2009 at 09:05:47PM -0700, SM wrote:

> If there is an error for RCPT, e.g. invalid recipient, the server must be 
> kept in the same state.  The "state" refers to the command sequence.  The 
> paragraph you are referring to covers MAIL, RCPT and DATA.  See section 
> 3.3 too as that section discusses about mail transactions.
>
>> Would clarifying this be acceptable? Or am I nit picking?
>
> If you can come up with better text, please send it.

I will. May take some time, but I will.

-- 
Jeff Macdonald
[email-masked]

Date: Thu, 14 May 2009 10:15:40 -0400
From: Jeff Macdonald <[email-masked]>
To: SM <[email-masked]>
Cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: email-arch intro
Sender: [email-masked]

On Thu, May 14, 2009 at 06:36:30AM -0700, SM wrote:

<snip>

> One of the "problems" with the email-arch is that the document does not 
> constrain itself to the higher level only.  It would have made matters 
> easier if the document was descriptive instead of prescriptive.
>

<snip>

> If I understand correctly, the last part of the last sentence excludes 
> existing protocols from having to explain the variance.  What you are 
> proposing is to have designers explain the differences between the 
> architecture and core protocol documents.  That presumes that the 
> designers have a good understanding of these documents.  The documents 
> are already quite lengthy and I think that we will see more 
> inconsistencies once we go down that path.

Since this seems to be the first document of this type for the IETF, I
suspect it will take some time to perfect the type of language such a
document should have. But we have to start from somewhere and I believe
this is excellent start.

So +1 to Pete's text.

-- 
Jeff Macdonald
[email-masked]

Date: Thu, 14 May 2009 06:36:30 -0700
To: Pete Resnick <[email-masked]>
From: SM <[email-masked]>
Subject: Re: email-arch intro
Cc: [email-masked]
Sender: [email-masked]

Hi Pete,
At 20:23 13-05-2009, Pete Resnick wrote:
>In among all of the other balls I have been juggling (or dropping 
>depending on your view of it), I've definitely let this one get far 
>too close to the ground. I've been talking to Klensin about his 
>earlier expressed concerns regarding the doc, and found talking to 
>Crocker who (shock of all shocks) seems to agree with the 
>overarching concern. What it

I'm glad to hear that you agree with each other.

>  comes down to is that the email-arch doc ought not turn into a 
> club with which to beat other standards (or the applications that 
> implement them). The architecture presented in
>  the document is a model under which we believe our protocols work, 
> but there is always a difference between architecture and 
> implementation and sometimes it is perfectly fine for protocols to 
> break with the architecture.

One of the reasons not to have a rigid architecture (after that fact) 
is that the protocols won't be an exact fit.

>So, I think the architecture document needs an intro somewhere 
>saying as much. Here's an attempt taken from my conversations with 
>both of them:
>
>1.3 The Role of This Architecture
>
>An Internet service is an integration of related capabilities among 
>two or more participating nodes. The capabilities are accomplished 
>across the Internet by one or more protocols. What connects a 
>protocol to a service is an architecture. An architecture specifies 
>how the protocols implement the service by defining the logical 
>components of a service and the relationships among them. From that 
>logical view, a service defines what is being done, an architecture 
>defines where the pieces are (in relation to each other) and a 
>protocol defines how particular capabilities are performed.
>
>As such, an architecture will more formally describe a service at a 
>relatively high level. A protocol which implement some portion of a 
>service will conform to the

One of the "problems" with the email-arch is that the document does 
not constrain itself to the higher level only.  It would have made 
matters easier if the document was descriptive instead of prescriptive.

>architecture to a greater or lesser extent, depending on the 
>pragmatic tradeoffs they make when trying to implement the 
>architecture in the context of real-world constraints. Failure to 
>precisely follow an architecture is not a failure of the protocol, 
>nor is failure to precisely cast a protocol a failure of the 
>architecture. Where a protocol varies from the architecture, it 
>should of course explain the reason for the variance. However, such 
>variance is not a mark against a protocol: Happily, the IETF prefers 
>running code to architectural purity.

According to the above paragraph, the protocols (RFC 5321 and RFC 
5322) should explain why they vary from the architecture.

>In this particular case, this architecture attempts to define the 
>logical components of Internet email and does so post hoc, trying to 
>capture the architectural principles that the current email 
>protocols embody. To different extents, email protocols will conform 
>to this architecture more or less well. Insofar as this architecture 
>differs from those protocols, the reasons are generally well 
>understood and are required for interoperation. The differences are 
>not a sign that protocols need to be fixed. However, this 
>architecture is a best attempt at a logical model of Internet email, 
>and insofar as new protocol development varies from this 
>architecture, it is necessary for designers to understand those 
>differences and explain them carefully.

If I understand correctly, the last part of the last sentence 
excludes existing protocols from having to explain the 
variance.  What you are proposing is to have designers explain the 
differences between the architecture and core protocol 
documents.  That presumes that the designers have a good 
understanding of these documents.  The documents are already quite 
lengthy and I think that we will see more inconsistencies once we go 
down that path.

Regards,
-sm 

Date: Thu, 14 May 2009 05:38:36 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: email-arch intro
Sender: [email-masked]

Pete Resnick wrote:
> In among all of the other balls I have been juggling (or dropping 
> depending on your view of it), I've definitely let this one get far too 
> close to the ground. 

Folks,

Alexey is including email-arch in the next IESG telechat.  Unfortunately, this 
means that he needs me to submit a revised, post-last call version by tomorrow, 
Friday.  So we have only today to discuss the text that Pete has circulated. 
Fortunately, the text is non-normative.

Also fortunately, I think the draft that Pete circulated does its job pretty 
well.  I think the IETF really does not have all that much experience producing 
architecture documents and explaining their role in relation to the service they 
describe or the protocols they engender.  So as a community, we do not have a 
lot of shared perspective or language for this sort of exercise.

That said, I think that the text does serve to help the reader understand the 
place that this sort of document should occupy amongst a set of technical 
specifications -- both the uses and the limits.

Given the time limit, I'll ask folk to draw a very sharp distinction between 
major objections -- problems with the text that are so serious the text MUST NOT 
be used in its current form -- versus minor ones -- tweaks that could make it 
better.

For major objections, please make very clear why you think disaster will befall 
the Internet if we use the text.  (Of course, suggestions for remedying this are 
solicited.)

For minor concerns, please also mark them clearly, and do send them -- feel free 
to send them to me privately, to keep the mailing list channel more open.  I'll 
fold suggestions in as best I can.  (The IETF Last Call, including impressively 
careful additional GenArts and SecDir reviews already produced a number of such 
fixes.)

Thanks!

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 13 May 2009 20:23:51 -0700
To: <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: email-arch intro
Sender: [email-masked]

Hi all,

In among all of the other balls I have been juggling (or dropping 
depending on your view of it), I've definitely let this one get far 
too close to the ground. I've been talking to Klensin about his 
earlier expressed concerns regarding the doc, and found talking to 
Crocker who (shock of all shocks) seems to agree with the overarching 
concern. What it comes down to is that the email-arch doc ought not 
turn into a club with which to beat other standards (or the 
applications that implement them). The architecture presented in the 
document is a model under which we believe our protocols work, but 
there is always a difference between architecture and implementation 
and sometimes it is perfectly fine for protocols to break with the 
architecture.

So, I think the architecture document needs an intro somewhere saying 
as much. Here's an attempt taken from my conversations with both of 
them:

---
1.3 The Role of This Architecture

An Internet service is an integration of related capabilities among 
two or more participating nodes. The capabilities are accomplished 
across the Internet by one or more protocols. What connects a 
protocol to a service is an architecture. An architecture specifies 
how the protocols implement the service by defining the logical 
components of a service and the relationships among them. From that 
logical view, a service defines what is being done, an architecture 
defines where the pieces are (in relation to each other) and a 
protocol defines how particular capabilities are performed.

As such, an architecture will more formally describe a service at a 
relatively high level. A protocol which implement some portion of a 
service will conform to the architecture to a greater or lesser 
extent, depending on the pragmatic tradeoffs they make when trying to 
implement the architecture in the context of real-world constraints. 
Failure to precisely follow an architecture is not a failure of the 
protocol, nor is failure to precisely cast a protocol a failure of 
the architecture. Where a protocol varies from the architecture, it 
should of course explain the reason for the variance. However, such 
variance is not a mark against a protocol: Happily, the IETF prefers 
running code to architectural purity.

In this particular case, this architecture attempts to define the 
logical components of Internet email and does so post hoc, trying to 
capture the architectural principles that the current email protocols 
embody. To different extents, email protocols will conform to this 
architecture more or less well. Insofar as this architecture differs 
from those protocols, the reasons are generally well understood and 
are required for interoperation. The differences are not a sign that 
protocols need to be fixed. However, this architecture is a best 
attempt at a logical model of Internet email, and insofar as new 
protocol development varies from this architecture, it is necessary 
for designers to understand those differences and explain them 
carefully.
---

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

Date: Thu, 07 May 2009 21:05:47 -0700
To: Jeff Macdonald <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: transaction commands, errors and 'same state'
Sender: [email-masked]

Hi Jeff,
At 19:31 07-05-2009, Jeff Macdonald wrote:
>I was reviewing 5321 and I see that it states for HELO/EHLO and MAIL
>that if there is an error, that the server must stay in the same state
>(section 4.1.4). This paragraph starts talking about MAIL (well, I
>think it is):

That section is about the "order of commands".

>If the transaction beginning command argument is not acceptable, a 501
>failure reply MUST be returned and the SMTP server MUST stay in the
>same state.  If the commands in a transaction are out of order to the
>degree that they cannot be processed by the server, a 503 failure reply
>MUST be returned and the SMTP server MUST stay in the same state.
>
>
>but the last sentence seems to be talking about RCPT & DATA and only
>says stay in the same state regarding command sequence. But an error
>for RCPT should also keep the server in the 'same state' too, right?
>Perhaps this is mentioned else where, but the words 'same state' are
>only used in section 4.1.4.

If there is an error for RCPT, e.g. invalid recipient, the server 
must be kept in the same state.  The "state" refers to the command 
sequence.  The paragraph you are referring to covers MAIL, RCPT and 
DATA.  See section 3.3 too as that section discusses about mail transactions.

>Would clarifying this be acceptable? Or am I nit picking?

If you can come up with better text, please send it.

Regards,
-sm 

Date: Thu, 7 May 2009 22:31:41 -0400
From: Jeff Macdonald <[email-masked]>
To: [email-masked]
Subject: transaction commands, errors and 'same state'
Sender: [email-masked]

I was reviewing 5321 and I see that it states for HELO/EHLO and MAIL
that if there is an error, that the server must stay in the same state
(section 4.1.4). This paragraph starts talking about MAIL (well, I
think it is):

If the transaction beginning command argument is not acceptable, a 501
failure reply MUST be returned and the SMTP server MUST stay in the
same state.  If the commands in a transaction are out of order to the
degree that they cannot be processed by the server, a 503 failure reply
MUST be returned and the SMTP server MUST stay in the same state.

but the last sentence seems to be talking about RCPT & DATA and only
says stay in the same state regarding command sequence. But an error
for RCPT should also keep the server in the 'same state' too, right?
Perhaps this is mentioned else where, but the words 'same state' are
only used in section 4.1.4.

Would clarifying this be acceptable? Or am I nit picking?

-- 
Jeff Macdonald
[email-masked]