Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

From: SM <[email-masked]>
Date: Sun, 01 Mar 2009 19:29:23 -0800

At 10:10 26-02-2009, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Internet Mail Architecture '
>    <draft-crocker-email-arch-11.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the

Some of the terms in the draft are also used in RFC 5321/5322 which 
are on the Standards Track :-

email-arch Section 2.1:

    "The Author is responsible for creating the message, its contents, and
     its list of recipient addresses."

RFC 5322 Section 3.6.2:

    The "From:" field specifies the author(s) of the message,
    that is, the mailbox(es) of the person(s) or system(s) responsible
    for the writing of the message.

email-arch Section 2.2.2

   "The Relay performs MHS-level transfer-service routing and store-and-
    forward, by transmitting or retransmitting the message to its
    Recipients.  The Relay adds trace information [RFC2505] but does not
    modify the envelope information or the message content semantics.  It
    can modify message content representation, such as changing the form
    of transfer encoding from binary to text, but only as required to
    meet the capabilities of the next hop in the MHS."

RFC 5321 Section 2.3.10:

   "A "relay" SMTP
    system (usually referred to just as a "relay") receives mail from an
    SMTP client and transmits it, without modification to the message
    data other than adding trace information, to another SMTP server for
    further relaying or for delivery."

email-arch Section 2.2.3:

   "A Gateway is a hybrid of User and Relay that connects heterogeneous
    mail services.  Its purpose is to emulate a Relay and the closer it
    comes to this, the better.  A Gateway operates as a User when it
    needs the ability to modify message content.

RFC 5321 Section 2.3.10:

    A "gateway" SMTP system (usually referred to just as a "gateway")
    receives mail from a client system in one transport environment and
    transmits it to a server system in another transport environment.
    Differences in protocols or message semantics between the transport
    environments on either side of a gateway may require that the gateway
    system perform transformations to the message that are not permitted
    to SMTP relay systems.

As this draft is being considered as a Proposed Standard, will it be 
authoritative instead of RFC 5821/5322?

In Section 1.2 of the draft, RFC2822.From and RFC2821.MailFrom are 
used to refer
to structured fields of a message.  I prefer Header.From and 
SMTP.MailFrom as it doesn't require any changes if RFC 5321 and RFC 
5322 are updated.  There was a similar discussion  about the 
replacement for message/rfc822 in the EAI Working Group.

In the Security Considerations Section (6.1):

   "As mentioned in Section 4.1.4, it is common
    practice for components of this architecture to use the
    [RFC0791].SourceAddr to make policy decisions [RFC2505], although the
    address can be "spoofed"."

As the focus of the draft is email architecture, this doesn't fit 
under security considerations.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 01 Mar 2009 20:21:09 -0800

> authoritative instead of RFC 5821/5322?

This presumes that there are different semantics or syntax offered by them.

What inconsistencies are you seeing, specifically, so we can fix them.

Again, we should note that 5322 and 5321 have their own redundancies and
opportunities for inconsistencies.

Would that Postel and I had coordinated better for 821/822, but alas we didn't. 
At the time, I thought we did, but it's been clear for a long time that we didn't.

I remember wondering about that at the time, but certainly had no concept of the 
long-term hassles it would cause.

Kinda makes one appreciate the benefit of being more careful.  We probably 
should have taken another 10 or 15 years to figure it out...

> In Section 1.2 of the draft, RFC2822.From and RFC2821.MailFrom are used to
> refer to structured fields of a message.  I prefer Header.From and 
> SMTP.MailFrom as it doesn't require any changes if RFC 5321 and RFC 5322 are
> updated.  There was a similar discussion  about the replacement for 
> message/rfc822 in the EAI Working Group.

As I recall, the choice of "rfc#." versus "acronym." or "std#." was discussed 
during development of the draft.  Perhaps separately, but it has come up in 
recent years.

 From what I've seen, folks generally seem to prefer using the RFC number. 
Personally, I'd prefer acronym#, although the other side of not having to make 
changes when there's a new RFC is not being sure whether the meaning has 
changed...

> "As mentioned in Section 4.1.4, it is common practice for components of this
> architecture to use the [RFC0791].SourceAddr to make policy decisions
> [RFC2505], although the address can be "spoofed"."
> 
> As the focus of the draft is email architecture, this doesn't fit under 
> security considerations.

Email-arch discusses implications in various places.  From what I've seen, the 
IETF's security geeks vastly prefer having extra Security Considerations, rather 
than missing important ones.  And in terms of advising the community about 
security holes in email, more is definitely better.  So I'd rather see this 
tidbit retained.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: SM <[email-masked]>
Date: Mon, 02 Mar 2009 02:39:15 -0800

At 20:21 01-03-2009, Dave CROCKER wrote:
>>As this draft is being considered as a Proposed Standard, will it 
>>be authoritative instead of RFC 5821/5322?
>

I'm replying to this point separately so that it does not get 
confused with the rest of my comments.

If there isn't an authoritative reference and there are differences 
in semantics or syntax between the draft and RFC5321/5322 or future 
revisions of these documents, it can lead to serious 
issues.  Standards Track documents are around years.  The documents 
may be edited by different authors as they get updated.  Errors can 
happen; the documents can diverge.

In my opinion, it is better to clarify that now or else we will end 
up having discussions ten years from now to determine which 
interpretation is correct or which standard to follow.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 02 Mar 2009 07:49:09 -0800

For the content that overlaps in RFC5322 and RFC5321, which one is authoritative?

d/

SM wrote:
> I'm replying to this point separately so that it does not get confused 
> with the rest of my comments.
> 
> If there isn't an authoritative reference and there are differences in 
> semantics or syntax between the draft and RFC5321/5322 or future 
> revisions of these documents, it can lead to serious issues.  Standards 
> Track documents are around years.  The documents may be edited by 
> different authors as they get updated.  Errors can happen; the documents 
> can diverge.
> 
> In my opinion, it is better to clarify that now or else we will end up 
> having discussions ten years from now to determine which interpretation 
> is correct or which standard to follow.

-- 

   Dave Crocker

---

From: Dave Cridland <[email-masked]>
Date: Mon, 02 Mar 2009 15:57:58 +0000

> For the content that overlaps in RFC5322 and RFC5321, which one is  
Whichever is cited by the document referencing the content, of course.

Alternately, we could have a public food fight between Klensin,  
Resnick, and Crocker. If this does happen in SF, can someone ensure  
it gets filmed for posterity?

Thanks,

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 02 Mar 2009 08:05:16 -0800

> Whichever is cited by the document referencing the content, of course.

That sounds pretty unstable, since it produces context-dependent resolution.

> Alternately, we could have a public food fight between Klensin, Resnick, 
> and Crocker. If this does happen in SF, can someone ensure it gets 
> filmed for posterity?

Pete usually has too much class to engage in these, publicly.  John and I get 
into public food fights all the time, using food for thought.  We're in the 
middle of one now, on these same lists, and I have to tell you, it's neither 
pretty nor interesting.  Save your film.

d/

-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Mon, 02 Mar 2009 08:15:27 -0800

email-arch Section 2.2.2

RFC 5321 Section 2.3.10:

   "A "relay" SMTP

The draft says that a relay can modify message content representation 
whereas RFC 5321 says that a relay does not do any modification to 
the message data other than adding trace information.

Regards,
-sm

---

From: [email-masked]
Date: Mon, 02 Mar 2009 08:26:25 -0800 (PST)

> the message data other than adding trace information.

Another place where RFC 5321 is at odds with reality, I'm afraid. MIME
downgrading is the obvious example where relays alter message content and such
alterations are explicltly condoned by other standards. 

The customary fig leaf we try and draw over this is that systems that perform
such alterations are gateways, not relays. But this particular fig leaf
has gotten awfully small and thin over time.

In any case, this is one where I think the email-arch document is right,
RFC 5321 is wrong, and we should fix RFC 5321.

				Ned

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Mar 2009 17:38:42 +0100

Maybe Dave you should add an Updates tag to your draft?

Eliot

On 3/2/09 5:26 PM, [email-masked] wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Hector Santos <[email-masked]>
Date: Mon, 02 Mar 2009 12:34:28 -0500

[email-masked] wrote:
> downgrading is the obvious example where relays alter message content 
> and such alterations are explicltly condoned by other standards.

Which ones?  With middle ware?

> The customary fig leaf we try and draw over this is that systems that 
> perform such alterations are gateways, not relays. But this particular fig leaf

+1.

> RFC 5321 is wrong, and we should fix RFC 5321.

-1.

I hate middle ware, passthrus, relays, routers, what have you, that 
alter the original mail integrity. It should be against the law. 
hmmmmmmmmmm, in fact, if push came to shove there might be some legal 
(US) precedence for such mail tampering claims.

I know society has been molded to believe that we can SNIFF 
transmissions, but alterations within a homogeneous network should not 
be encourage, nor tolerated.  Be very careful to [further] open 
Pandora's Box here.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: Dave Cridland <[email-masked]>
Date: Mon, 02 Mar 2009 18:48:01 +0000

> That sounds pretty unstable, since it produces context-dependent  
It is unstable, yes, but I'm not convinced that's a bad thing - it's  
stable per document, at least.

What it means is that if a document says "Relay (as defined in  
[MAIL-ARCH])", or a more generic and sweeping "Terms are as defined  
in [MAIL-ARCH]", then it's absolutely obvious which definition is  
being used, and if there is doubt, the reference can be checked.

That the terms differ is, of course, important to resolve in and of  
itself, but I'm not clear that a definition of a term - which *will*  
need a citation and reference anyway - needs to have a particular  
definition set in stone right here and now.

To get consensus behind a single definition requires rather a lot of  
work, and one simple method of finding the consensus (if one exists)  
is to have two definitions out there and see which is cited in  
practise.

>> Resnick, and Crocker. If this does happen in SF, can someone  
>> ensure it gets filmed for posterity?
> 
> 
> Pete usually has too much class to engage in these, publicly.  John  
> and I get into public food fights all the time, using food for  
> thought

Yes, well those aren't half as much fun. Don't use food for thought,  
use custard pies.

Dave.

---

From: SM <[email-masked]>
Date: Mon, 02 Mar 2009 17:20:05 -0800

>For the content that overlaps in RFC5322 and RFC5321, which one is 

There are several possible answers:

  1. The author of the draft chooses the email-arch draft

  2. The author of the draft chooses RFC 5321 and RFC 5332

  3. Have the people listed in the author field for these documents 
make the choice

  4. The author of the draft makes a choice based on the Last Call comments

  5. Leave it to the IESG to decide

  6. Ignore the question

Regards,
-sm

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 3 Mar 2009 10:44:12 +0100

[email-masked] writes:
> revisions of these documents, it can lead to serious issues.  
> Standards Track documents are around years.  The documents may be 
> edited by different authors as they get updated.  Errors can happen; 
> the documents can diverge.
>
> having discussions ten years from now to determine which 

So. RFC 3501 (page 50-51), says that the localpart of a From: address is 
matched case-insensitively when IMAP servers process SEARCH or UID 
SEARCH commands. RFC 5321 says that SMTP servers process localparts 
case-sensitively. Both rules go back essentially unchanged to very old 
RFCs.

Do we need to discuss which is correct or which standard to follow? I 
fail to see any conflict.

Arnt

---

From: [email-masked]
Date: Tue, 03 Mar 2009 09:42:12 -0800 (PST)

> case-sensitively. Both rules go back essentially unchanged to very old

But that's the problem - this is not what RFC 5321 says. It says:

   Consequently, and due to a
   long history of problems when intermediate hosts have attempted to
   optimize transport by modifying them, the local-part MUST be
   interpreted and assigned semantics only by the host specified in the
   domain part of the address.

SMTP server do stuff like expand lists all the time. For those tests to be 
done competently some amount of interpretation of local parts may be needed,
such as ignoring the possibility that the local part is case sensitive.

Now, if RFC 5321 instead said that interpretation of local parts MUST be
limited to comparison operations, and local parts MUST NOT be modified, the
problem mostly goes away. (There are probably still some odd corner cases left
for gateways, but after thinking about it some more I think we can ignore
those.)

> fail to see any conflict.

I have to disagree. While there may not be any conflict between RFC 3501 and
RFC 5321 since they deal with separate components, the fact remains that
there's a conflict between what real world implementations do and what RFC 5321
says must not be done.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 4 Mar 2009 11:14:25 +0100

Ned Freed writes:
> But that's the problem - this is not what RFC 5321 says.

It's not what 3501 says either ;) More of a one-sentence simplification 
than a full and exact description.

> ...
>
> SMTP server do stuff like expand lists all the time. For those tests 
> to be done competently some amount of interpretation of local parts 
> may be needed, such as ignoring the possibility that the local part 
> is case sensitive.

Oh, this makes sense. I wasn't aware of that. I ran into the same issue 
whem implementing "group reply" in a MUA, but hadn't realised that MTAs 
could run into that.

> While there may not be any conflict between RFC 3501 and RFC 5321 
> since they deal with separate components, the fact remains that 
> there's a conflict between what real world implementations do and 
> what RFC 5321 says must not be done.

I agree with that. Email-arch, however, deals with both, and attempts to 
describe the running code too, so IMO it can't just cite 5321. That 
would be overly simplistic.

Arnt