Subject: YAM (Yet Another Mail) WG Meeting/BOF on Thursday
From: Tony Hansen <[email-masked]>
To: [email-masked], ietf-822 mailing list <[email-masked]>, IMAP Protocol Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>, EAI WG <[email-masked]>
Date: Sun, 22 Mar 2009 01:20:46 -0400
List-Id: <ietf-smtp.imc.org>

The YAM (Yet Another Mail) Working Group is having its first meeting
this Thursday at 3:10pm.

The first part of the charter is reproduced here. The full charter text
can be found at http://trac.tools.ietf.org/bof/trac/wiki/YamCharter

	Tony Hansen
	co-chair

YAM will focus strictly on advancing email-related specifications for
which the community already has some years of experience with deployment
and interoperability. Its function is not to reopen or reconsider
protocols -- if a specification is found to need significant technical
work, YAM will remove it from the WG's agenda, optionally making a
recommendation to the community about how, or if, it should be processed.

This charter's scope of work is the set of email-related RFCs that are
currently at Draft Standard. Each document will be examined, along with
its errata, and a recommendation made as to whether it should be
advanced to Full Standard, republished at Draft Standard or Proposed
Standard, or moved to Historic. This working group will not work further
on documents that are to be republished at Draft Standard or Proposed
Standard.

Date: Fri, 6 Mar 2009 09:33:23 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Cc: Ned Freed <[email-masked]>, Hector Santos <[email-masked]>, David MacQuigg <[email-masked]>, Dave CROCKER <[email-masked]>
Sender: [email-masked]

Hector Santos writes:
> Arnt Gulbrandsen wrote:
>> Hector Santos writes:
>>> Excuse me if I am not following you, but the compares are 
>>> implementation specific.  Like Finch pointed out, Sieve doesn't 
>>> care.
>>
>> Sieve suggests treating localparts case insensitively. Any user may 
>> follow the suggestion or explicitly choose something different from 
>> the default.
>>
>> This is not specific to any implementation: Any conforming sieve 
>> processor behaves this way.
>
> So what you are saying is that if we implement Sieve, to be Sieve 
> compliant, our implementation must provide user preferences in 
> regards to case?

Yes. And if the users copy the examples they'll find on the net, their 
scripts will be case-insensitive. To quote the last script snippet I 
saw:

if address :is :localpart "from" "zabbix" {
    fileinto "Zabbix";
}

Users who know how to (ha ha) can write case-sensitive code by adding 
:comparator "i;octet", so each script's case treatment is in principle 
implementation-specific.

All this doesn't contravene RFC 5321. But it does suggest that the 
overall email architecture doesn't treat localparts as completely 
opaque.

Arnt

Date: Thu, 05 Mar 2009 20:41:40 -0500
From: John C Klensin <[email-masked]>
To: [email-masked]
cc: Hector Santos <[email-masked]>, Ned Freed <[email-masked]>, David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Sender: [email-masked]

Ned,

No disagreement with anything you say below.  My only point was
that the situation is a little ambiguous, that the 5321 text can
be read in different ways, that getting into an "I'm holier than
thou" discussion around the definitions of the standards is not
a particularly productive activity, and that, unless we are
going to retool the protocol specifications and their
definitions in major ways (starting with 5321 but definitely not
limited to it), maybe a little ambiguity is a good thing.

    john

--On Thursday, March 05, 2009 15:35 -0800
[email-masked] wrote:

> 
>> --On Thursday, March 05, 2009 13:05 -0800
>> [email-masked] wrote:
> 
>> > ...
>> > That's wasn't Tony's point. His point was that Sieve breaks
>> > the RFC 5321 rule
>> > by allowing scripts to assign whatever semantics they like
>> > to local parts of
>> > external addresses. Sieve can be case-sensitive or
>> > case-insensitive (the latter
>> > is the default) and even has an extension for extracting
>> > subaddress information
>> > from arbitrary addresses.
> 
>> Ned,
> 
>> I think whether Sieve is complaint or not depends, as all of
>> these things traditionally have, on how you model the delivery
>> process and its relationship to it.
> 
> Sieve is specified as occuring around the time of final
> delivery. If it is applied just before final delivery, that
> puts it in the scope of SMTP.
> 
>> If I hang Sieve off of a relay in the middle of the network
>> and then start parsing and interpreting local parts, it would
>> clearly be non-compliant, but, to a certain extent, that
>> status is a definitional contradiction: a thing in the middle
>> of the network with a Sieve processor hanging off of it and
>> interpreting and acting on local parts (or any of several
>> other things), isn't a relay any more.
> 
> It isn't a conforming sieve implementation either. As such,
> while I suppose you could implement such a thing, I see little
> point in discussing it.
> 
>> Whether it is a gateway
>> between logical spheres of administrative influence, a "final
>> delivery" SMTP server at the boundary of some domain that has
>> its own internal mail classification and routing machinery, or
>> some other sort of odd beast is a separate question --one that
>> I'm not sure we improve the world by trying to answer-- but it
>> is definitely not a 5321-conformant relay whether it
>> interprets those addresses case-independently or not.
> 
> And by the same token neither is an autoforwarder that performs
> an authorization check on the MAIL FROM address by comparing
> it in a case-insensitive way with a authorized address list.
> 
> So is this a gateway too? It doesn't meet the definitoin in
> RFC 5321 - it's certainy not passing messages between
> different transport environments.  But let's ignore that for
> now. Suppose it is a gateway. You've just reclassified a
> significant fraction of the relays out there as being a
> gateway. Those are now joined by the ones that apply Sieve
> prior to final delivery, agents that employ various sorts of
> white and black list technologies, and lots of other stuff.
> 
> Travel much further down this path and the pure relays RFC
> 5321 spends so much time on aren't endangered, they're
> essentially extinct.
> 
>> If the Sieve process is either beyond whatever one considers
>> to be the final delivery server or is acting, with
>> authorization, on behalf of that server or a user beyond it,
>> the 5321 rules are really not being violated.
> 
>> All of this was a lot more clear when mail was delivered to an
>> SMTP server at the boundary of an enterprise which then
>> proceeded to interpret the addresses, rewrite the mail, and
>> deliver it using mail protocols that didn't work on the
>> Internet backbone.   Those days are, fortunately, long gone.
> 
> In fact with the advent of complex webmail systems, one can
> argue that these things are more popular than the various LAN
> email systems ever were. But that's really a different
> discussion for another day.
> 
> 				Ned
> 

Date: Thu, 05 Mar 2009 18:54:07 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Ned Freed <[email-masked]>
CC:  [email-masked], David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

Ned Freed wrote:
>> >> Man, I really wish I understand you because I see no such prohibition
>> >> at all.  All it is saying is don't force it way way or another, keep
>> >> as is and hopefully before the entire process is complete.
>> >
>> > Well, all I can say is that I sure see such actions as prohibited by 
>> the
>> > current language. And it seems that most other people who have weighed
>> > in on this at least agree it can be interpreted that way. You choose 
>> not to, and
>> > that's certainly your perogative, but if it can be interpreted in a way
>> > that causes various common operations to be considered incompliant I 
>> see that
>> > as a problem.
> 
>> Ned, I'm grown tired of this attacks. Its funny that I could of
>> blabbed the same thing about you. So you beat me to it (although I
>> wasn't planning to) and labeled me the odd ball here. Fine, its par
>> for the course here.
> 
> And with that I'm done. I have spent a considerable amount of time 
> trying to explain this and now you accuse me of attacking you - which 
 > I did not do.
> I really should know better by now. But while I'm a slow learner, I do
> eventually get it. This will be my final response, and I apologize
> to everyone else on the list who has had to endure this.

All I am saying is that you spent a considerable amount of time as if 
this was my own mis-reading, that we would not be compliant (3 times) 
and it was my prerogative as to to blow me off.  That was becoming 
obvious and I was hoping you would stop and focus on the differences. 
Just consider I am not off base here - that first sentence "Explain 
this" as if I was clearly wrong and that last sentence of yours are 
all prime example of what you continue to do ALWAYS and exactly what I 
am saying - I'm the bad guy here. I created the "bandwidth" problem. I 
hope you would stop it.

All I wanted to know is what you were suggesting because it appeared 
to me that the alternative would create more harm, not less.  In fact, 
let it be known that I asked you off list for clarification - which 
you choose not to reply to but instead came back with this.

I'm the bad guy!

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 05 Mar 2009 15:35:17 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
To: John C Klensin <[email-masked]>
Cc: [email-masked], Hector Santos <[email-masked]>, Ned Freed <[email-masked]>, David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

> --On Thursday, March 05, 2009 13:05 -0800
> [email-masked] wrote:

> >...
> > That's wasn't Tony's point. His point was that Sieve breaks
> > the RFC 5321 rule
> > by allowing scripts to assign whatever semantics they like to
> > local parts of
> > external addresses. Sieve can be case-sensitive or
> > case-insensitive (the latter
> > is the default) and even has an extension for extracting
> > subaddress information
> > from arbitrary addresses.

> Ned,

> I think whether Sieve is complaint or not depends, as all of
> these things traditionally have, on how you model the delivery
> process and its relationship to it.

Sieve is specified as occuring around the time of final delivery. If it is
applied just before final delivery, that puts it in the scope of SMTP.

> If I hang Sieve off of a relay in the middle of the network and
> then start parsing and interpreting local parts, it would
> clearly be non-compliant, but, to a certain extent, that status
> is a definitional contradiction: a thing in the middle of the
> network with a Sieve processor hanging off of it and
> interpreting and acting on local parts (or any of several other
> things), isn't a relay any more.

It isn't a conforming sieve implementation either. As such, while I suppose you
could implement such a thing, I see little point in discussing it.

> Whether it is a gateway
> between logical spheres of administrative influence, a "final
> delivery" SMTP server at the boundary of some domain that has
> its own internal mail classification and routing machinery, or
> some other sort of odd beast is a separate question --one that
> I'm not sure we improve the world by trying to answer-- but it
> is definitely not a 5321-conformant relay whether it interprets
> those addresses case-independently or not.

And by the same token neither is an autoforwarder that performs
an authorization check on the MAIL FROM address by comparing
it in a case-insensitive way with a authorized address list.

So is this a gateway too? It doesn't meet the definitoin in RFC 5321 - it's
certainy not passing messages between different transport environments.  But
let's ignore that for now. Suppose it is a gateway. You've just reclassified a
significant fraction of the relays out there as being a gateway. Those are now
joined by the ones that apply Sieve prior to final delivery, agents that employ
various sorts of white and black list technologies, and lots of other stuff.

Travel much further down this path and the pure relays RFC 5321 spends so much
time on aren't endangered, they're essentially extinct.

> If the Sieve process is either beyond whatever one considers to
> be the final delivery server or is acting, with authorization,
> on behalf of that server or a user beyond it, the 5321 rules are
> really not being violated.

> All of this was a lot more clear when mail was delivered to an
> SMTP server at the boundary of an enterprise which then
> proceeded to interpret the addresses, rewrite the mail, and
> deliver it using mail protocols that didn't work on the Internet
> backbone.   Those days are, fortunately, long gone.

In fact with the advent of complex webmail systems, one can argue that these
things are more popular than the various LAN email systems ever were. But
that's really a different discussion for another day.

				Ned

Date: Thu, 05 Mar 2009 15:27:08 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
To: Hector Santos <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked], David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

> >> Man, I really wish I understand you because I see no such prohibition
> >> at all.  All it is saying is don't force it way way or another, keep
> >> as is and hopefully before the entire process is complete.
> >
> > Well, all I can say is that I sure see such actions as prohibited by the
> > current language. And it seems that most other people who have weighed
> > in on this at least agree it can be interpreted that way. You choose not to, and
> > that's certainly your perogative, but if it can be interpreted in a way
> > that causes various common operations to be considered incompliant I see that
> > as a problem.

> Ned, I'm grown tired of this attacks. Its funny that I could of
> blabbed the same thing about you. So you beat me to it (although I
> wasn't planning to) and labeled me the odd ball here. Fine, its par
> for the course here.

And with that I'm done. I have spent a considerable amount of time trying to
explain this and now you accuse me of attacking you - which I did not do. 

I really should know better by now. But while I'm a slow learner, I do
eventually get it. This will be my final response, and I apologize
to everyone else on the list who has had to endure this.

				Ned

Date: Thu, 05 Mar 2009 18:20:59 -0500
From: John C Klensin <[email-masked]>
To: [email-masked], Hector Santos <[email-masked]>
cc: Ned Freed <[email-masked]>, David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

--On Thursday, March 05, 2009 13:05 -0800
[email-masked] wrote:

>...
> That's wasn't Tony's point. His point was that Sieve breaks
> the RFC 5321 rule
> by allowing scripts to assign whatever semantics they like to
> local parts of
> external addresses. Sieve can be case-sensitive or
> case-insensitive (the latter
> is the default) and even has an extension for extracting
> subaddress information
> from arbitrary addresses.

Ned,

I think whether Sieve is complaint or not depends, as all of
these things traditionally have, on how you model the delivery
process and its relationship to it.

If I hang Sieve off of a relay in the middle of the network and
then start parsing and interpreting local parts, it would
clearly be non-compliant, but, to a certain extent, that status
is a definitional contradiction: a thing in the middle of the
network with a Sieve processor hanging off of it and
interpreting and acting on local parts (or any of several other
things), isn't a relay any more.    Whether it is a gateway
between logical spheres of administrative influence, a "final
delivery" SMTP server at the boundary of some domain that has
its own internal mail classification and routing machinery, or
some other sort of odd beast is a separate question --one that
I'm not sure we improve the world by trying to answer-- but it
is definitely not a 5321-conformant relay whether it interprets
those addresses case-independently or not.

If the Sieve process is either beyond whatever one considers to
be the final delivery server or is acting, with authorization,
on behalf of that server or a user beyond it, the 5321 rules are
really not being violated.

All of this was a lot more clear when mail was delivered to an
SMTP server at the boundary of an enterprise which then
proceeded to interpret the addresses, rewrite the mail, and
deliver it using mail protocols that didn't work on the Internet
backbone.   Those days are, fortunately, long gone.  But the
basic model hasn't changed even if our terminology for the
boundary machine isn't "enterprise mail gateway" any more (and
maybe if it is).

And, if the boundary/Sieve machine is sitting somewhere at the
boundary between an ISP and the rest of the network, operating
according to rules determined by the ISP and not by the end
user, we've got a classic "middlebox" problem and all of the
(often pointless) debates about who controls it and what that
means, but no real model change: the machine is still acting as
a delivery server with post-delivery SMTP-level resending
functions and doing so on behalf of the target user mailbox,
whether that user likes it or not.

    john

Date: Thu, 05 Mar 2009 15:03:57 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail   Architecture) to Proposed Standard
To: Hector Santos <[email-masked]>
Cc: [email-masked], Dave CROCKER <[email-masked]>, David MacQuigg <[email-masked]>, [email-masked]
Sender: [email-masked]

> [email-masked] wrote:

> >
> > I agree it falls into the mediator category. But it if falls into RFC 5321
> > gateway category, it ends up dragging almost everything else in there
> > with it.
> > And we're left with a document that goes to enormous trouble to specify
> > behavior something that for all intents and purposes doesn't exist.

> Ned, with all due respect, uou repeated this a few times and was going
> to leave it alone, but it appears that is being used as premise for
> change.

> Lets not confuse Gateways as being just some heterogeneous network
> transition point with two way transformations.

That's exacly what I'm opposed to doing.

> A gate would generally be just the final destination to a backend
> storage system.

Actually, that's quite different from RFC 5321's defnition, which talks about
gateway being a component between transport environments.

> It could be hosting in passthru fashion (old) or
> presenting it for users (active) - s system that has the fundamental
> components for electronic messages:

>     From:
>     To:
>     Subject
>     Date:
>     Body

> The backend could be a common framework for a myriad of networks.

> This is different from a SMTP relay which is homogeneous - the same
> network.

The definition of gateway in RFC 5421 doesn't mention different networks. Only
tranport environments. And in practice true gateways, such as SMTP/MIME to
X.400, often operate entirely on a single network.

> I guess, we can have a RELAY-GATE if you consider that the backend
> could be hosting and storing the reformatted passthru mail.

> That is whats "old" and what still remains is that the storage is
> available for reader as well.

> We still have customers that can read the mail online, but they can
> also be "small point", they can QWK, FIDONET into our backend servers
> to pick up/sent mail gated from 2822 based networks.

> To suggest this is all intents and purposes doesn't exist, well, its
> not only untrue but we are seeing a "rebirth" of different and
> traditional networking methods. e.g.; to lower the footprint for
> small-device communications, to purify mail, to reformat into other
> streams.

I'm suggesting no such thing. What I am saying is that if every time we come
across something a relay does that doesn't jibe with RFC 5321's relay
restrictions, instead of bringing RFC 5321 into line with reality, we instead
say, "Oh, that's not a relay, it's a gateway, and so rules for relays don't
apply", pretty soon everything will be a gateway and there won't be any relays
left. I don't think that's a desireable outcome.

> But that isn't the key point, whether is is or not.

> It should not be the premise to eliminate or change a specification
> regarding case.

Which nobody is proposing doing. All I'm arguing for is a change to RFC 5321 to
say that the MUST NOT apply semantics to local parts not apply to address
comparison operations.

				Ned

Date: Thu, 05 Mar 2009 18:13:40 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC:  [email-masked], Ned Freed <[email-masked]>, David MacQuigg <[email-masked]>, Dave CROCKER <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Hector Santos writes:
>> Excuse me if I am not following you, but the compares are 
>> implementation specific.  Like Finch pointed out, Sieve doesn't care.
> 
> Sieve suggests treating localparts case insensitively. Any user may 
> follow the suggestion or explicitly choose something different from the 
> default.
> 
> This is not specific to any implementation: Any conforming sieve 
> processor behaves this way.

So what you are saying is that if we implement Sieve, to be Sieve 
compliant, our implementation must provide user preferences in regards 
to case?

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 05 Mar 2009 18:04:51 -0500
From: John C Klensin <[email-masked]>
To: Dave CROCKER <[email-masked]>
cc: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail   Architecture) to Proposed Standard
Sender: [email-masked]

--On Thursday, March 05, 2009 13:24 -0800 Dave CROCKER
<[email-masked]> wrote:

> John C Klensin wrote:
>>      from a RFC 5321/SMTP perspective, any Message
>> Submission (RFC 4409) server clearly falls into Dave's
>> Mediator category. 
> 
> 
> Huh?  I don't see that at all.
> 
> How can something that defines the submission event "take
> delivery", which is one of the defining components of a
> Mediator?  MSA's do 'receive' the message from the MUA, but it
> ain't 'delivery'.

Depends on whether the MSA "receives" the message via some
private protocol or via SMTP.   If an MUA sends a complete
message to the MSA using SMTP, the submission server looks an
awful lot like an MTA (SMTP-receiver).  It differs from a
"normal" SMTP-receiver in only two respects: the MUA isn't a
full-service SMTP-sender because it doesn't maintain queues or
resolve MXs (but, in the general case, the MSA can't tell) and
it may have the ability to patch up broken/incomplete messages
(but those functions are not exercised if the submitted message
is complete and conforming).  

On the the other hand, it isn't clear to me that something is
"delivered", in the SMTP sense, to a gateway either.  To the
system sending something to a gateway over SMTP, the gateway
looks like a relay and there is no way to tell the difference
unless one deduces it heuristically from funky MX records.   As
with the MSA, the thing that makes a system a gateway (assuming
it speaks SMTP on both its receiving and sending sides) is the
functions it performs, not how the messages come in or go out.
Of course, that changes if either the low-level transports or
the mail-level ones are different, but that is also true of MSAs
in general (as distinct from ones that are strictly
4409-compliant).

   john

Date: Thu, 05 Mar 2009 18:01:57 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC: Dave CROCKER <[email-masked]>, David MacQuigg <[email-masked]>, [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail   Architecture) to Proposed Standard
Sender: [email-masked]

[email-masked] wrote:

> 
> I agree it falls into the mediator category. But it if falls into RFC 5321
> gateway category, it ends up dragging almost everything else in there 
> with it.
> And we're left with a document that goes to enormous trouble to specify
> behavior something that for all intents and purposes doesn't exist.

Ned, with all due respect, uou repeated this a few times and was going 
to leave it alone, but it appears that is being used as premise for 
change.

Lets not confuse Gateways as being just some heterogeneous network 
transition point with two way transformations.

A gate would generally be just the final destination to a backend 
storage system. It could be hosting in passthru fashion (old) or 
presenting it for users (active) - s system that has the fundamental 
components for electronic messages:

    From:
    To:
    Subject
    Date:
    Body

The backend could be a common framework for a myriad of networks.

This is different from a SMTP relay which is homogeneous - the same 
network.

I guess, we can have a RELAY-GATE if you consider that the backend 
could be hosting and storing the reformatted passthru mail.

That is whats "old" and what still remains is that the storage is 
available for reader as well.

We still have customers that can read the mail online, but they can 
also be "small point", they can QWK, FIDONET into our backend servers 
to pick up/sent mail gated from 2822 based networks.

To suggest this is all intents and purposes doesn't exist, well, its 
not only untrue but we are seeing a "rebirth" of different and 
traditional networking methods. e.g.; to lower the footprint for 
small-device communications, to purify mail, to reformat into other 
streams.

But that isn't the key point, whether is is or not.

It should not be the premise to eliminate or change a specification 
regarding case.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 5 Mar 2009 23:45:01 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Cc: Ned Freed <[email-masked]>, Hector Santos <[email-masked]>, David MacQuigg <[email-masked]>, Dave CROCKER <[email-masked]>
Sender: [email-masked]

Hector Santos writes:
> Excuse me if I am not following you, but the compares are 
> implementation specific.  Like Finch pointed out, Sieve doesn't care.

Sieve suggests treating localparts case insensitively. Any user may 
follow the suggestion or explicitly choose something different from the 
default.

This is not specific to any implementation: Any conforming sieve 
processor behaves this way.

Arnt

Date: Thu, 05 Mar 2009 14:06:06 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail   Architecture) to Proposed Standard
To: Dave CROCKER <[email-masked]>
Cc: David MacQuigg <[email-masked]>, [email-masked]
Sender: [email-masked]

> David MacQuigg wrote:
> > At 03:02 AM 3/5/2009 -0800, Ned Freed wrote:
> >
> >>> So yes, this may be an example of an SMTP relay violating RFC-5321.  The
> >>> quote above was from a paragraph in 5321 talking about recipient
> >>> addresses, however.
> >> The quote in question is from section "2.3.11 Mailbox and address" and
> >> that's under the SMTP terminology heaing. It is in no way specific to
> >> recipient addresses.
> >
> > OK, if we interpret the MUST in section 2.3.11 to mean all email addresses,
> > then something should be fixed.  The prohibition on SMTP relays changing or
> > re-interpreting local parts should apply only to recipient addresses.
> > Changing a Mail From address should be allowed.  I do that so as to redirect
> > any bounces back to my domain where I can deal with them summarily.  I
> > suspend the recipient's account immediately, and wait until he tells me the
> > problem is fixed.  Any other policy could get me on some blacklist.

> I think the exchange you are having with Ned hinges on a couple of oints of
> disconnection:

>     1)  Implementation versus architecture.

>     2)  Relay vs. Mediator

> An implementation can be a mixture of architectural functions.  Many
> implementations that we think of as "Relays" are actually Mediators -- the mess
> with the message and, therefore, take on some significant responsibility for it.

THat's a distinction that exists in the email architecture document only. RFC
5321 doesn't follow this convention, preferring instead the older relay vs
gateway distrinction.

The problem with the old relay versus gateway distinction is that it is so
coarse grained that if you use it as a loophole for every implementation that,
say, does case-insensitive address comparisons, you quickly find that
everything is a gateway and you've spent a huge amount of time specifying
precise behavior for essentially nothing.

(This reminds me of an amusing math story. A few years back a bunch of papers
were written about a particular family of sets, sorry, I forget the exact set
of properties but it included paracompact and maybe semimetrizable. Then along
came a paper that proved the only set in the family was the empty set. Oops.)

> Note, for example, the "Alias" role:

> <http://bbiw.net/specifications/draft-crocker-email-arch-11.html#rfc.section.5.1>

> This was wrestled with, over the course of the email-arch draft development.

> The message is, in fact, delivered to the Alias Mediator.  The Alias Mediator
> then re-posts the message to the alias address.  That this service is typically
> implemented in software we generally think of as an MTA is confusing.  But for
> this function, the MTA is actually a Mediator, not a relay.

> SMTP (RFC 5321) makes the distinction between relay and gateway, where I read
> the latter as matching the Mediator construct in email-arch.  And it is rather
> specific about the functional distinctions.  What you are describing doing
> clearly falls into the camp of gateway/mediator.

I agree it falls into the mediator category. But it if falls into RFC 5321
gateway category, it ends up dragging almost everything else in there with it.
And we're left with a document that goes to enormous trouble to specify
behavior something that for all intents and purposes doesn't exist.

				Ned

Date: Thu, 05 Mar 2009 17:21:20 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Ned Freed <[email-masked]>
CC:  [email-masked], David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

Ned Freed wrote:
> 
> RIght, and that's exactly the point. Right now RFC 5321 says they can't be.
> 
>  Like Finch pointed out, Sieve doesn't care.
> 
> That's wasn't Tony's point. His point was that Sieve breaks the RFC 5321 
> rule by allowing scripts to assign whatever semantics they like to local 
> parts of external addresses. 

This is so odd.

> Sieve can be case-sensitive or case-insensitive (the 
> latter is the default) and even has an extension for 
 > extracting subaddress information from arbitrary addresses.

All of which would not be possible if SMTP did not preserve the 
address case.

>> What you are saying, I think, you know of a procedure that does care
>> what the input is. Right?
> 
> Nope. I'm saying that there's all sorts of stuff out there busily 
> comparing the local parts of addresses they don't own using all sorts 
 > of different rules.

Again, all of which would not be possible if SMTP did not preserve the 
address case.

> And that stuff is in clear violation of RFC 5321.

If SMTP did touch it, then it would be in violation or it might cause 
problems for software that may WISH to look at the case.

So I am really having a hard time understanding what you are talking 
about - or rather what you are proposing to see happen.

> The word "case" isn't even mentioned in the text in question, so I fail 
> to see  how you can possible get such a reading out of it.

Come on Ned, see section 2.4.

>> I have a perfect example.  Due the age of our software, there could be
>> versions out there that export mail and SMTP reads and sends mail out:
> 
>>      MAIL FROM:<[email-masked]>
>>      MAIL FROM:<[email-masked]>
>>      MAIL FROM:<[email-masked]>
> 
>> What is the receiver system to assume here?
> 
> Well, you'd better hope it doesn't follow RFC 5321 rules, because 
 > that would imply a case-sensitive comparison be done against any
 > stored authorized address list. And that's going to cause at least
 > one of these to fail no matter what's on the authorized list.

But thats presuming there are significant # of mail-bots are still 
looking for specific case.

Would you should this the the norm? passe?

I will venture most systems have learn not to do case sensitive 
compares, including us.

> In practice, of course, pretty much every autoforwarder, list server, 
> and so on out there does a case-insensitive comparison. 

I fail to see the conflict then. But you do make implementation 
assumptions that should be out of scope.  What if there are 
auto-forwarders, list servers that do case sensitive compare?  You are 
probably right, low chance. But SMTP should not be assuming one way or 
another in order to fix those that may be working with lower or upper 
case or not doing case-insensitive compares.  It should not be SMTP 
concern.

I can only begin to better understand your point better if you are 
suggesting SMTP should be forcing a case - maybe to the common 
dominator of lower case addresses.

 > And it isn't at all uncommmon to ignore subaddresses too.
> 
>>     Should it lower, upper, keep case before passing it to
>>     should avs, shim, script, acl queue?
> 
>> I think SMTP is saying to KEEP is the best policy.
> 
> Of course it should keep the case. Again, modification of the address isn't
> at issue.

Right, what is at issue is how you wish SMTP semantics to be changed 
to one that probably isn't very realistic.

>> Man, I really wish I understand you because I see no such prohibition
>> at all.  All it is saying is don't force it way way or another, keep
>> as is and hopefully before the entire process is complete.
> 
> Well, all I can say is that I sure see such actions as prohibited by the
> current language. And it seems that most other people who have weighed 
> in on this at least agree it can be interpreted that way. You choose not to, and
> that's certainly your perogative, but if it can be interpreted in a way 
> that causes various common operations to be considered incompliant I see that 
> as a problem.

Ned, I'm grown tired of this attacks. Its funny that I could of 
blabbed the same thing about you. So you beat me to it (although I 
wasn't planning to) and labeled me the odd ball here. Fine, its par 
for the course here.

But we are handling it right and that is all that matters - we are 
preserving it - at the SMTP level. So whether you believe 5321 is 
incorrect,  as it was yesterday 2821 and today 5321, we are compliant.

What you have yet to explain is why it is important or broken for some 
specific auto-forwarder?

The reality is as clear you implied:

     Most systems do a case-insensitive compare

so its really a practical moot point.

It sounds like you are assuming all auto-forwarders with some "access 
controls" (whatever that means and doesn't matter) behave with the 
same logic and you know that is not true.

So this is an implementation issue, not an architectural issue and to 
assume that it is, is to presume that the entire network is operating 
under some specific constant level - which is not reality.

The architectural recommendation is preservation.  That has always 
been the best policy across the board.

That does not mean you have to do case [in]sensitive compares. Thats 
out of scope and up to you.

Anyway, I don't see a problem with 5321 wrt to this issue.

So -1 on changing it.

-
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 05 Mar 2009 13:24:47 -0800
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail   Architecture) to Proposed Standard
Sender: [email-masked]

John C Klensin wrote:
>      from a RFC 5321/SMTP perspective, any Message
> Submission (RFC 4409) server clearly falls into Dave's Mediator
> category. 

Huh?  I don't see that at all.

How can something that defines the submission event "take delivery", which is 
one of the defining components of a Mediator?  MSA's do 'receive' the message 
from the MUA, but it ain't 'delivery'.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 05 Mar 2009 16:19:32 -0500
From: John C Klensin <[email-masked]>
To: Dave CROCKER <[email-masked]>, David MacQuigg <[email-masked]>
cc: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail   Architecture) to Proposed Standard
Sender: [email-masked]

--On Thursday, March 05, 2009 11:44 -0800 Dave CROCKER
<[email-masked]> wrote:

>...
> SMTP (RFC 5321) makes the distinction between relay and
> gateway, where I read the latter as matching the Mediator
> construct in email-arch.  And it is rather specific about the
> functional distinctions.  What you are describing doing
> clearly falls into the camp of gateway/mediator.

And, FWIW, from a RFC 5321/SMTP perspective, any Message
Submission (RFC 4409) server clearly falls into Dave's Mediator
category.  If I recall, Randy and I spent some time trying to
get the terminology in 2476 right to avoid getting crossways of
the Gateway/Relay distinction.

    john

Date: Thu, 05 Mar 2009 13:05:20 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
To: Hector Santos <[email-masked]>
Cc: [email-masked], Ned Freed <[email-masked]>, David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

> [email-masked] wrote:

>  > This isn't about any of that. This is about the operations an SMTP
>  > server is allowed to perform on the addresses associated with other
>  > domains that appear in MAIL FROM and header fields. RFC 5321 says
>  > the only thing you can do with such address is copy them around
>  > untouched. But the reality is these addresses are *compared*.

> Excuse me if I am not following you, but the compares are
> implementation specific.

RIght, and that's exactly the point. Right now RFC 5321 says they can't be.

  Like Finch pointed out, Sieve doesn't care.

That's wasn't Tony's point. His point was that Sieve breaks the RFC 5321 rule
by allowing scripts to assign whatever semantics they like to local parts of
external addresses. Sieve can be case-sensitive or case-insensitive (the latter
is the default) and even has an extension for extracting subaddress information
from arbitrary addresses.

> What you are saying, I think, you know of a procedure that does care
> what the input is. Right?

Nope. I'm saying that there's all sorts of stuff out there busily comparing the
local parts of addresses they don't own using all sorts of different rules. And
that stuff is in clear violation of RFC 5321.

>  > we're not talking about any sort of modification - with
>  > other addresses in ways which, like it or not, assign
>  > specific semantics to local parts. And RFC 5321 says that's
>  > not allowed.

> I am not reading it that way.  I am reading it should not ASSUME a
> case for the purpose of some unknown or out of scope process.
> Preservation is the best policy.

The word "case" isn't even mentioned in the text in question, so I fail to see
how you can possible get such a reading out of it.

> I have a perfect example.  Due the age of our software, there could be
> versions out there that export mail and SMTP reads and sends mail out:

>      MAIL FROM:<[email-masked]>
>      MAIL FROM:<[email-masked]>
>      MAIL FROM:<[email-masked]>

> What is the receiver system to assume here?

Well, you'd better hope it doesn't follow RFC 5321 rules, because that would
imply a case-sensitive comparison be done against any stored authorized address
list. And that's going to cause at least one of these to fail no matter what's
on the authorized list.

In practice, of course, pretty much every autoforwarder, list server, and so on
out there does a case-insensitive comparison. And it isn't at all uncommmon to
ignore subaddresses too.

>     Should it lower, upper, keep case before passing it to
>     should avs, shim, script, acl queue?

> I think SMTP is saying to KEEP is the best policy.

Of course it should keep the case. Again, modification of the address isn't
at issue.

> >> I'm not sure what you are getting too but consider the alternative:
> >
> >>     - rule that states its one case over another and that all systems
> >>       MUST compare, store and render displays in one case?
> >
> > No, I'm not saying anything like that. I want systems to have the
> > freedom to perform whatever comparison operation they believe are
>  > appropriate, including ones that assume case sensitivity, or
>  > insensitivity, or which attempt to strip common subaddress forms,
>  > and so on. Right now they are prohited from doing any of that.

> Man, I really wish I understand you because I see no such prohibition
> at all.  All it is saying is don't force it way way or another, keep
> as is and hopefully before the entire process is complete.

Well, all I can say is that I sure see such actions as prohibited by the
current language. And it seems that most other people who have weighed in on
this at least agree it can be interpreted that way. You choose not to, and
that's certainly your perogative, but if it can be interpreted in a way that
causes various common operations to be considered incompliant I see that as a
problem.

				Ned

Date: Thu, 05 Mar 2009 15:44:29 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC: Ned Freed <[email-masked]>, David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

[email-masked] wrote:

 > This isn't about any of that. This is about the operations an SMTP
 > server is allowed to perform on the addresses associated with other
 > domains that appear in MAIL FROM and header fields. RFC 5321 says
 > the only thing you can do with such address is copy them around
 > untouched. But the reality is these addresses are *compared*.

Excuse me if I am not following you, but the compares are 
implementation specific.  Like Finch pointed out, Sieve doesn't care.
What you are saying, I think, you know of a procedure that does care 
what the input is. Right?

 > we're not talking about any sort of modification - with
 > other addresses in ways which, like it or not, assign
 > specific semantics to local parts. And RFC 5321 says that's
 > not allowed.

I am not reading it that way.  I am reading it should not ASSUME a 
case for the purpose of some unknown or out of scope process. 
Preservation is the best policy.

I have a perfect example.  Due the age of our software, there could be 
versions out there that export mail and SMTP reads and sends mail out:

     MAIL FROM:<[email-masked]>
     MAIL FROM:<[email-masked]>
     MAIL FROM:<[email-masked]>

What is the receiver system to assume here?

    Should it lower, upper, keep case before passing it to
    should avs, shim, script, acl queue?

I think SMTP is saying to KEEP is the best policy.

> 
>> I'm not sure what you are getting too but consider the alternative:
> 
>>     - rule that states its one case over another and that all systems
>>       MUST compare, store and render displays in one case?
> 
> No, I'm not saying anything like that. I want systems to have the 
> freedom to perform whatever comparison operation they believe are 
 > appropriate, including ones that assume case sensitivity, or
 > insensitivity, or which attempt to strip common subaddress forms,
 > and so on. Right now they are prohited from doing any of that.

Man, I really wish I understand you because I see no such prohibition 
at all.  All it is saying is don't force it way way or another, keep 
as is and hopefully before the entire process is complete.

>> Preservation - leaving it alone is the base way to handle this, even
>> if you not modifying.
> 
>> Here's the difference:
> 
>>   1 - SMTP.ADDRESS -> FORCECASE(SMTP.ADDRESS) -> SHIM -> COMPARE
>>   2 - SMTP.ADDRESS -> SHIM -> FORCECASE(LOCAL STACK ADDRESS) -> COMPARE
> 
>> The first one opens the door to having a single storage where the case
>> has been modified (ie. you need to pass a copy to preserve it).
> 
> These are implementation details. Sure, if you implement comparison 
> operations incorrectly you'll end up modifying the addresses, which 
 > would be bad. But hopefully coders can manage to make a copy of the
 > field they're interesting in comparing before
 > performing canonicalization operatioions on it.

I believe SMTP is closely modeling #2.  It is not going to force the 
case for SIEVE or any other shim process to work.  mail bot developers 
SHOULD NOT presume their input will be pre-pre-prepared one way or 
another.  In fact, I would state these mail bots should make it clear 
that they might need originality to be preserve.  Sieve apparently 
does. Most similar systems today are case insensitive operations. But 
SMTP is helping this part by telling SMTP developers to please 
preserve it regardless of what the input is.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 05 Mar 2009 11:59:24 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
To: David MacQuigg <[email-masked]>
Cc: Ned Freed <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

> At 03:02 AM 3/5/2009 -0800, Ned Freed wrote:

> >> So yes, this may be an example of an SMTP relay violating RFC-5321.  The
> >> quote above was from a paragraph in 5321 talking about recipient addresses,
> >> however.
> >
> >The quote in question is from section "2.3.11 Mailbox and address" and that's
> >under the SMTP terminology heaing. It is in no way specific to recipient
> >addresses.

> OK, if we interpret the MUST in section 2.3.11 to mean all email addresses,

Given that it's in a general terminology section, I don't see how we have
a choice.

> then something should be fixed.  The prohibition on SMTP relays changing or
> re-interpreting local parts should apply only to recipient addresses.

But that goes much too far. For example, I don't want externai systems forcing
my addresses to lower case (or upper case) on a whim.

I'm with Hector on this - you shouldn't be allowed to modify addresses you
don't own, nno matter where they appear.

> Changing a Mail From address should be allowed.

Changing it from one address to another, yes, absolutely. But changing, say,
[email-masked] to [email-masked] because you happen to like
mixed case is not OK. Who knows, external.com might just be using
case-sensitive local parts. (The more fool they if they are, not because
software out there diddles witt case a lot - as a rule it doesn't - but rather
because people are pretty sloppy about case when they enter addresses
manually.)

Now, an interesting corner case is something like SRS, where
[email-masked] becomes something like

    SRS0=P+D=7E=external.com=[email-masked]

But this actually isn't dependent on understanding local part semantics in any
way - it only operates on overall address syntax. 

> I do that so as to redirect any bounces back to my domain where I can deal
> with them summarily.  I suspend the recipient's account immediately, and
> wait until he tells me the problem is fixed.  Any other policy could get me
> on some blacklist.

Yeah, we are all forced to dance these sorts of dances.

				Ned

Date: Thu, 05 Mar 2009 11:44:00 -0800
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: David MacQuigg <[email-masked]>
CC: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail   Architecture) to Proposed Standard
Sender: [email-masked]

David MacQuigg wrote:
> At 03:02 AM 3/5/2009 -0800, Ned Freed wrote:
> 
>>> So yes, this may be an example of an SMTP relay violating RFC-5321.  The 
>>> quote above was from a paragraph in 5321 talking about recipient
>>> addresses, however.
>> The quote in question is from section "2.3.11 Mailbox and address" and
>> that's under the SMTP terminology heaing. It is in no way specific to
>> recipient addresses.
> 
> OK, if we interpret the MUST in section 2.3.11 to mean all email addresses,
> then something should be fixed.  The prohibition on SMTP relays changing or
> re-interpreting local parts should apply only to recipient addresses.
> Changing a Mail From address should be allowed.  I do that so as to redirect
> any bounces back to my domain where I can deal with them summarily.  I
> suspend the recipient's account immediately, and wait until he tells me the
> problem is fixed.  Any other policy could get me on some blacklist.

I think the exchange you are having with Ned hinges on a couple of oints of 
disconnection:

    1)  Implementation versus architecture.

    2)  Relay vs. Mediator

An implementation can be a mixture of architectural functions.  Many 
implementations that we think of as "Relays" are actually Mediators -- the mess 
with the message and, therefore, take on some significant responsibility for it.

Note, for example, the "Alias" role:

<http://bbiw.net/specifications/draft-crocker-email-arch-11.html#rfc.section.5.1>

This was wrestled with, over the course of the email-arch draft development.

The message is, in fact, delivered to the Alias Mediator.  The Alias Mediator 
then re-posts the message to the alias address.  That this service is typically 
implemented in software we generally think of as an MTA is confusing.  But for 
this function, the MTA is actually a Mediator, not a relay.

SMTP (RFC 5321) makes the distinction between relay and gateway, where I read 
the latter as matching the Mediator construct in email-arch.  And it is rather 
specific about the functional distinctions.  What you are describing doing 
clearly falls into the camp of gateway/mediator.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 05 Mar 2009 10:31:56 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
To: Hector Santos <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked], David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

> Ned Freed wrote:
> > That's effectively what section 5.3.11 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.
> >
> > When you perform a case-insensitive or subaddress-stripped comparison
> > with a stored address, you are assigning semantics to the local-part
>  > of that address. And you're not the host specified in the
>  > domain part.

> I read that to mean to accept as it and decide how you need to use it.

I have no idea what you mean by this.

>     For example, there is no rule that email address formats MUST be
> lowercase, therefore your down link software should not be assuming it
> would all be lower case.

I fail to see the relevance.

> But that might be exactly how it wants it which only your
> implementation would know about because it would be your own
> implementation detail.

You keep talking about the fact that local part handling is implementation
specific. That's completely true and only relevant in that it is this fact that
makes not modifying addresses so important.

But again, the issue here isn't how particular implementations structure their
handling of local parts. It is understood that they are free to be
case-sensitive or case-insensitive, or interpret various different characters
as subaddress delimiters, etc. etc.

This isn't about any of that. This is about the operations an SMTP server is
allowed to perform on the addresses associated with other domains that appear
in MAIL FROM and header fields. RFC 5321 says the only thing you can do with
such address is copy them around untouched. But the reality is these addresses
are *compared* - we're not talking about any sort of modification - with other
addresses in ways which, like it or not, assign specific semantics to local
parts. And RFC 5321 says that's not allowed.

> >> Its not just about compares, but rendering as well, as well as replies.
> >
> > Again, nobody is talkng about allowing addresses to be modified.

> But that is what the statement implies.

No it isn't. The statement is about assigning semantics. Now, it goes without
saying that if you modify the local part you've assumed certain semantics. But
comparison operations also assume certain semantics.

> Like I pointed out, we had a
> history of forcing the freaking case when it was gated outside of
> 282x/532x so there would be no violation as you may to put it.

You're again talking about modifying addresses. THis is not the issue on the
table.

> The problem was the reverse, reply system.

> > The semantics you've chosen to define for your own addresses are
> > irrelevant. We're talking about what sorts  of interpretation you're
>  > allowed to make of addresses you do not own.
> >
> >> But on the inbound side, it is all preserved but all compares are case
> >> in-sensitive.
> >
> > Which, if you're talking about foriegn addresses, puts you in voilation
> > of RFC 5221.

> But that is exactly the point of the comments.  Preservation is the
> recommendation, especially when it isn't your domain - like a reply
> address.

You keep going round and round and round about things that would modify
addresses. I really don't know how to say it any plainer - this is NOT my
concern. I have no issue with saying that addresses not be modified.  In fact I
would strongly object to any change that allowed modification of addresses in
domains you aren't responsible for.

> I'm not sure what you are getting too but consider the alternative:

>     - rule that states its one case over another and that all systems
>       MUST compare, store and render displays in one case?

No, I'm not saying anything like that. I want systems to have the freedom to
perform whatever comparison operation they believe are appropriate, including
ones that assume case sensitivity, or insensitivity, or which attempt to strip
common subaddress forms, and so on. Right now they are prohited from doing any
of that.

> Preservation - leaving it alone is the base way to handle this, even
> if you not modifying.

> Here's the difference:

>   1 - SMTP.ADDRESS -> FORCECASE(SMTP.ADDRESS) -> SHIM -> COMPARE
>   2 - SMTP.ADDRESS -> SHIM -> FORCECASE(LOCAL STACK ADDRESS) -> COMPARE

> The first one opens the door to having a single storage where the case
> has been modified (ie. you need to pass a copy to preserve it).

These are implementation details. Sure, if you implement comparison operations
incorrectly you'll end up modifying the addresses, which would be bad. But
hopefully coders can manage to make a copy of the field they're interesting in
comparing before performing canonicalization operatioions on it.

				Ned

Date: Thu, 5 Mar 2009 13:48:59 +0000
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Ned Freed <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Sender: [email-masked]

On Wed, 4 Mar 2009, Arnt Gulbrandsen wrote:
> Ned Freed writes:
>
> > 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.

Sieve also ignores the differing case-sensitivity requirements for domains
and local parts, and uses case-insensitive macthing by default.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Date: Thu, 05 Mar 2009 07:48:07 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Ned Freed <[email-masked]>
CC:  [email-masked], David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

Ned Freed wrote:
> That's effectively what section 5.3.11 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.
> 
> When you perform a case-insensitive or subaddress-stripped comparison 
> with a stored address, you are assigning semantics to the local-part 
 > of that address. And you're not the host specified in the
 > domain part.

I read that to mean to accept as it and decide how you need to use it. 
    For example, there is no rule that email address formats MUST be 
lowercase, therefore your down link software should not be assuming it 
would all be lower case.

But that might be exactly how it wants it which only your 
implementation would know about because it would be your own 
implementation detail.

>> Its not just about compares, but rendering as well, as well as replies.
> 
> Again, nobody is talkng about allowing addresses to be modified.

But that is what the statement implies. Like I pointed out, we had a 
history of forcing the freaking case when it was gated outside of 
282x/532x so there would be no violation as you may to put it.

The problem was the reverse, reply system.

> The semantics you've chosen to define for your own addresses are 
> irrelevant. We're talking about what sorts  of interpretation you're 
 > allowed to make of addresses you do not own.
> 
>> But on the inbound side, it is all preserved but all compares are case
>> in-sensitive.
> 
> Which, if you're talking about foriegn addresses, puts you in voilation 
> of RFC 5221.

But that is exactly the point of the comments.  Preservation is the 
recommendation, especially when it isn't your domain - like a reply 
address.

I'm not sure what you are getting too but consider the alternative:

    - rule that states its one case over another and that all systems
      MUST compare, store and render displays in one case?

Preservation - leaving it alone is the base way to handle this, even 
if you not modifying.

Here's the difference:

  1 - SMTP.ADDRESS -> FORCECASE(SMTP.ADDRESS) -> SHIM -> COMPARE
  2 - SMTP.ADDRESS -> SHIM -> FORCECASE(LOCAL STACK ADDRESS) -> COMPARE

The first one opens the door to having a single storage where the case 
has been modified (ie. you need to pass a copy to preserve it).

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 05 Mar 2009 03:11:45 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
To: Hector Santos <[email-masked]>
Cc: [email-masked], David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

> [email-masked] wrote:

> >> A mailing list is a mediator (at the User level), not a relay at the SMTP
> >> level.
> >
> > THen what about autoforwarders with access controls?
> >
> >> It *is* the "host specified in the domain part of the address".  So it should
> >> interpret the local part.
> >
> > Of the recipient address, sure. But not the originator address.
> >
> >> When I send this message to [email-masked], only imc.org knows how to
> >> interpret the local part.  RFC 5321 is not in conflict with reality, at least
> >> in this example.
> >
> > When you send mail to [email-masked], a check is made to see if you're a
> > subscriber to the list. I doubt that your address is in imc.org and that check
> > is probably done in a case-insensitive way.
> >
> > Replace [email-masked] with an autoforwarder with access control, and now
> > RFC 5321 *is* in conflict with reality.

> Ned, I am not quite following.

> Isn't this implementation specific?

If you're referring to case sensitivity, of course it is.

> I think the "smith" vs "Smith" idea is old, but I think the key idea
> is about preservation as stated in 2.4:

>     Therefore, SMTP implementations MUST take care to preserve the case
>     of mailbox local-parts.

That's not the part in question and this is not about modifying addresses in
any way.

> The SMTP receiver should not be forcing it one way or another - just
> store as is up to the point where it doesn't matter any more.

THat would be address modification again, which is not the issue.

> But it
> still implementation specific and I don't see where in 5321 it says a
> "comparison" must be case sensitive.  That wouldn't be reality.

That's effectively what section 5.3.11 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.

When you perform a case-insensitive or subaddress-stripped comparison with a
stored address, you are assigning semantics to the local-part of that address.
And you're not the host specified in the domain part.

> Its not just about compares, but rendering as well, as well as replies.

Again, nobody is talkng about allowing addresses to be modified.

> For our system this was all very important as our old school online
> hosting system started out as a local hosting system only (a BBS).

> So we still have

>    - single name vs first last name account system.

>      older setups still force names upper case.

>    - default dot/undot formatting

>     "name"            <--> "name" <[email-masked]>
>     "First Last"      <--> "First Last" <[email-masked]>
>     "First I. Last"   <--> "First I. Last" <[email-masked]>

>    - Some remaining parts of the software and many of the
>      3rd party tools still used upper case user names.

>     "OLD USER"      <--> "OLD USER" <[email-masked]>

>    - Some mail readers STILL force upper case, like an still
>      popular 16 bit reader that forces the TO/FROM to uppercase
>      in the wire transmission.

>    - Some of the older multi-network gating force the case.

The semantics you've chosen to define for your own addresses are irrelevant.
We're talking about what sorts  of interpretation you're allowed to make of
addresses you do not own.

> But on the inbound side, it is all preserved but all compares are case
> in-sensitive.

Which, if you're talking about foriegn addresses, puts you in voilation of RFC
5221.

				Ned

Date: Thu, 05 Mar 2009 03:02:05 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
To: David MacQuigg <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

> So yes, this may be an example of an SMTP relay violating RFC-5321.  The
> quote above was from a paragraph in 5321 talking about recipient addresses,
> however.

The quote in question is from section "2.3.11 Mailbox and address" and that's
under the SMTP terminology heaing. It is in no way specific to recipient
addresses.

>  The way I read it, it seems to be saying "If you are not sure about a
> local-part, don't try to be helpful, just leave it alone."

I disagree. I don't think that's a reasonable interpretation.

>  If I were the agent in charge of this "autoforwarder", I wouldn't even
> read 5321 on this question. I would be quite sure of my policy on return
> addresses.

But the fact of the matter is others can and do read and apply it.

				Ned

Date: Thu, 05 Mar 2009 05:46:10 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC: David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

Hector Santos wrote:

>   - Some remaining parts of the software and many of the
>     3rd party tools still used upper case user names.
> 
>    "OLD USER"      <--> "OLD USER" <[email-masked]>

Sorry, I also meant to add:

      "OLD USER"      <--> "OLD USER" <[email-masked]>

where the case is carried on and/or forced upper case.

What is interesting is that if we look at our user database and those 
our long time customers, the pattern would be:

    1985 to 1992   user accounts all uppercase, server enforced,
                   no email "user ids", email storage in local
                   format.

                   JOE SMITH
                   MARY WHATEVER

    1993 to 1998   beginning of mix by tools, server did not
                   enforce uppercase, (no email formats), Preserve
                   Mime storage user preference, low usage.

                   JOE SMITH
                   MARY WHATEVER
                   Larry The Plumber
                   sex goddess

    1999 to 2004   Undocumented allowance for email ids
                   stock software/tools do not uppercase, Preserve
                   Mime storage user preference becomes more
                   prevalent with the growth of POP3/EXCHANGE.

                   JOE SMITH
                   MARY WHATEVER
                   Larry The Plumber
                   sex goddess
                   [email-masked]
                   [email-masked]       <-- 3rd party signup tool?

    2005 to today  preservation is the key consideration, case
                   insensitive compares in all cases. Preserve
                   Mime is fundamental as people like HTML mail
                   and POP3/EXCHANGE.

                   JOE SMITH
                   MARY WHATEVER
                   Larry The Plumber
                   sex goddess
                   [email-masked]
                   [email-masked]       <-- 3rd party signup tool?

                   new account names preserved
                   with extended record for optional email id.

So at least for us, the statement in 5321 2.3.11

    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.

and 2.4

    Therefore, SMTP implementations MUST take care to preserve the case
    of mailbox local-parts.

are very applicable.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 05 Mar 2009 05:18:37 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC: David MacQuigg <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

[email-masked] wrote:

>> A mailing list is a mediator (at the User level), not a relay at the SMTP
>> level.
> 
> THen what about autoforwarders with access controls?
> 
>> It *is* the "host specified in the domain part of the address".  So it should
>> interpret the local part.
> 
> Of the recipient address, sure. But not the originator address.
> 
>> When I send this message to [email-masked], only imc.org knows how to
>> interpret the local part.  RFC 5321 is not in conflict with reality, at least
>> in this example.
> 
> When you send mail to [email-masked], a check is made to see if you're a
> subscriber to the list. I doubt that your address is in imc.org and that check
> is probably done in a case-insensitive way.
> 
> Replace [email-masked] with an autoforwarder with access control, and now
> RFC 5321 *is* in conflict with reality.

Ned, I am not quite following.

Isn't this implementation specific?

I think the "smith" vs "Smith" idea is old, but I think the key idea 
is about preservation as stated in 2.4:

    Therefore, SMTP implementations MUST take care to preserve the case
    of mailbox local-parts.

The SMTP receiver should not be forcing it one way or another - just 
store as is up to the point where it doesn't matter any more.  But it 
still implementation specific and I don't see where in 5321 it says a 
"comparison" must be case sensitive.  That wouldn't be reality.

Its not just about compares, but rendering as well, as well as replies.

For our system this was all very important as our old school online 
hosting system started out as a local hosting system only (a BBS).

So we still have

   - single name vs first last name account system.

     older setups still force names upper case.

   - default dot/undot formatting

    "name"            <--> "name" <[email-masked]>
    "First Last"      <--> "First Last" <[email-masked]>
    "First I. Last"   <--> "First I. Last" <[email-masked]>

   - Some remaining parts of the software and many of the
     3rd party tools still used upper case user names.

    "OLD USER"      <--> "OLD USER" <[email-masked]>

   - Some mail readers STILL force upper case, like an still
     popular 16 bit reader that forces the TO/FROM to uppercase
     in the wire transmission.

   - Some of the older multi-network gating force the case.

But on the inbound side, it is all preserved but all compares are case 
in-sensitive.    What happens after that, depends on what the software 
is, how old, if its a 3rd party etc.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Wed, 04 Mar 2009 20:24:33 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
To: David MacQuigg <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

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

> A mailing list is a mediator (at the User level), not a relay at the SMTP
> level.

THen what about autoforwarders with access controls?

> It *is* the "host specified in the domain part of the address".  So it should
> interpret the local part.

Of the recipient address, sure. But not the originator address.

> When I send this message to [email-masked], only imc.org knows how to
> interpret the local part.  RFC 5321 is not in conflict with reality, at least
> in this example.

When you send mail to [email-masked], a check is made to see if you're a
subscriber to the list. I doubt that your address is in imc.org and that check
is probably done in a case-insensitive way.

Replace [email-masked] with an autoforwarder with access control, and now
RFC 5321 *is* in conflict with reality.

				Ned

Date: Wed, 4 Mar 2009 11:14:25 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Cc: Ned Freed <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Tue, 03 Mar 2009 09:42:12 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> [email-masked] writes:
> > 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.

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

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.)

> Do we need to discuss which is correct or which standard to follow? I
> 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 

Date: Tue, 3 Mar 2009 10:44:12 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Cc: [email-masked], [email-masked]
Sender: [email-masked]

[email-masked] writes:
> 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.

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

Date: Mon, 02 Mar 2009 17:20:05 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet	Mail	Architecture) to Proposed Standard
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 07:49 02-03-2009, Dave CROCKER wrote:
>For the content that overlaps in RFC5322 and RFC5321, which one is 
>authoritative?

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 

Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Date: Mon, 02 Mar 2009 18:48:01 +0000
From: Dave Cridland <[email-masked]>
To: Dave CROCKER <[email-masked]>
Cc: IETF-Discussion <[email-masked]>, <[email-masked]>, SM <[email-masked]>
Sender: [email-masked]

On Mon Mar  2 16:05:16 2009, Dave CROCKER wrote:
> 
> 
> Dave Cridland wrote:
>> On Mon Mar  2 15:49:09 2009, Dave CROCKER wrote:
>>> For the content that overlaps in RFC5322 and RFC5321, which one  
>>> is authoritative?
> >
>> Whichever is cited by the document referencing the content, of  
>> course.
> 
> That sounds pretty unstable, since it produces context-dependent  
> resolution.
> 
> 
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.

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

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

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

Date: Mon, 02 Mar 2009 12:34:28 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC: SM <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet	Mail	Architecture) to Proposed Standard
Sender: [email-masked]

[email-masked] wrote:
> 
>> At 20:21 01-03-2009, Dave CROCKER wrote:
>> >What inconsistencies are you seeing, specifically, so we can fix them.
> 
>> 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."
> 
>> 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.
> 
> 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.

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
> has gotten awfully small and thin over time.

+1.

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

-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

Date: Mon, 02 Mar 2009 17:38:42 +0100
From: Eliot Lear <[email-masked]>
To: [email-masked]
CC: SM <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet	Mail	Architecture) to Proposed Standard
Sender: [email-masked]

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

Eliot

On 3/2/09 5:26 PM, [email-masked] wrote:
>> At 20:21 01-03-2009, Dave CROCKER wrote:
>> >What inconsistencies are you seeing, specifically, so we can fix them.
>
>> 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."
>
>> 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.
>
> 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
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

Date: Mon, 02 Mar 2009 08:26:25 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet	Mail	Architecture) to Proposed Standard
To: SM <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> At 20:21 01-03-2009, Dave CROCKER wrote:
> >What inconsistencies are you seeing, specifically, so we can fix them.

> 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."

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

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

Date: Mon, 02 Mar 2009 08:15:27 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail	Architecture) to Proposed Standard
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 20:21 01-03-2009, Dave CROCKER wrote:
>What inconsistencies are you seeing, specifically, so we can fix them.

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."

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 

Date: Mon, 02 Mar 2009 08:05:16 -0800
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Dave Cridland <[email-masked]>
CC: IETF-Discussion <[email-masked]>, [email-masked], SM <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Sender: [email-masked]

Dave Cridland wrote:
> On Mon Mar  2 15:49:09 2009, Dave CROCKER wrote:
>> For the content that overlaps in RFC5322 and RFC5321, which one is 
>> authoritative?
 >
> 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
   Brandenburg InternetWorking
   bbiw.net

Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Date: Mon, 02 Mar 2009 15:57:58 +0000
From: Dave Cridland <[email-masked]>
To: Dave CROCKER <[email-masked]>
Cc: IETF-Discussion <[email-masked]>, <[email-masked]>, SM <[email-masked]>
Sender: [email-masked]

On Mon Mar  2 15:49:09 2009, Dave CROCKER wrote:
> For the content that overlaps in RFC5322 and RFC5321, which one is  
> authoritative?
> 
> 
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

Date: Mon, 02 Mar 2009 07:49:09 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SM <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet	Mail	Architecture) to Proposed Standard
Sender: [email-masked]

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

d/

SM wrote:
> 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?
>>
>> This presumes that there are different semantics or syntax offered by 
>> them.
> 
> 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
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 02 Mar 2009 02:39:15 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail	Architecture) to Proposed Standard
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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?
>
>This presumes that there are different semantics or syntax offered by them.

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 

Date: 2 Mar 2009 12:00:16 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: draft-crocker-email-arch: snapshot or wish list?
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>My position on this is that the email-arch document is attempting to describe
>the overall architecture we've standardized. It is not a place for making new
>rules about the interpretation of local parts or anything else for that matter.
>As such, the text that's there seems fine. If we're going to mess with this -
>and in spite of the issues I'm not convinced we should - it needs to happen in
>the context of RFC 5321bis, or better still, in a separate draft.

I haven't heard anyone (other than perhaps you) argue that we should
fix the interpretation of local parts here. Dave's language describes
the current situation reasonably well, the spec says they're case
sensitive, the reality is that they're not.

I'm also not averse to future work to adjust the spec to agree with
reality, but it's a swamp.  One issue is i18n, since we'd doubtless
get requests to plan for whatever i18n addresses turn out to be, and
it's a rare language with case folding rules as simple as English.

If we tried to go further and standardize subaddresses, that would be
a much worse swamp.  There are at least two delimiters for
subaddresses, plus and minus, in common use, and I'm also aware of
implementations that put part of the address into the domain, such as
[email-masked] -> [email-masked].  Subaddresses also have IPR
issues particularly if used to do spam filtering or sorting, real
ones, patents whose owners have a history of asserting them.

So let's get this out of the way now, and put on the waders later.

R's,
John

Date: Sun, 01 Mar 2009 20:21:09 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SM <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail	Architecture) to Proposed Standard
Sender: [email-masked]

SM wrote:
> As this draft is being considered as a Proposed Standard, will it be 
> 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...

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

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

Date: Sun, 01 Mar 2009 19:29:23 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture)  to Proposed Standard 
Cc: [email-masked]
Sender: [email-masked]

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 

Date: Sun, 01 Mar 2009 17:01:59 -0800 (PST)
From: [email-masked]
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
To: Dave CROCKER <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Folks,

> [Local-part. Case sensitivity.  Globally opaque.  Where to interpret.]

> I'm fixing the email-arch draft, according to the various notes that point out
> errors, confusion or poor wording.  But I'm stymied by the several notes on the
> topic of local-part, some of which discussed language or issues that seem to
> differ from what is in email-arch.

> Anyhow, here's what exists now:

> RFC 5321
> --------

> > 2.3.11. Mailbox and Address
> >
> > ...the local-part MUST be
> >    interpreted and assigned semantics only by the host specified in the
> >    domain part of the address.

This is, I regret to say, is a case similar to that of the issue of bare CRs
and bare LFs - it's a rule that's guaranteed to be broken no matter what our
standards say.

A common case where this currently gets ignored is mailing list membership
checks. If I'm subscribed to a list as [email-masked], I can't be 
counted on to remember to use that address when posting. (Actually, in my own
case it is not a problem becxaue my MUA remembers for me. But very few MUAs
have this feature AFAIK.) So when a list manager does a "is he a member of this
list", it makes all sorts of sense to drop the common forms of subaddresses
when doing the comparison. And since this is for comparison purposes only,
aside from the minescule risk of someone taking advantage of this to get around
access restrictions, this hurts nobody.

Now, perhaps the subaddress case is too obscure to matter. But what about lcoal
parts in different cases? Any mailing list access check that treats
[email-masked] as the same as [email-masked] is in technical violation of
this rule. And how many mailing list managers perform a case-sensitive
comparison on local parts of external domains? Not many, I'um sure - ours
certainly doesn't.

OTOH, the problem with dropping this rule entirely is that doing so allows all
sorts of bad stuff to happen, such as the nonsense that was one part of the
X,400 mapping specifications that basically said if a local part begins with a
"/" it's OK to drop the domain and treat what's left as an X.400 address. But
trying to come up with a more precise rule that allows the good and prevents
the bad looks fairly challenging to me.

> /////

> > 2.4. General Syntax Principles and Transaction Model
> >
> >
> >    Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
> >    and extension name keywords) are not case sensitive, with the sole
> >    exception in this specification of a mailbox local-part
> ...
> >    The local-part of a mailbox MUST BE treated as case sensitive.
> >    Therefore, SMTP implementations MUST take care to preserve the case
> >    of mailbox local-parts.  In particular, for some hosts, the user
> >    "smith" is different from the user "Smith".  However, exploiting the
> >    case sensitivity of mailbox local-parts impedes interoperability and
> >    is discouraged.

A bit of anecdotal information here FWIW: I've dealt with thousands of
customers over the years, and I can think of exactly one engagement where
someone insisted on case sensitive local parts. And after dealing with them on
this and several other issues, it became pretty clear it was all due to one guy
there who was nuttier than a fruitcake. 

> RFC 5322
> --------

> > 3.4.1. Addr-Spec Specification
> >
> >    The local-part portion is a domain-dependent string.  In addresses,
> >    it is simply interpreted on the particular host as a name of a
> >    particular mailbox.
> >

Can't say I much like the use of the term "host" here, but that's an issue for
another day.

> email-arch
> ----------

> > <t>The portion to the left of the at&nbhy;sign contains a
> > 	string that is globally opaque and is called the
> >  	&lt;local&nbhy;part&gt;. It is to be
> >  	interpreted only by the entity specified by the address's
> >  	domain name. Except as noted later in this section all
> >  	other entities MUST treat the
> >  	&lt;local&nbhy;part&gt; as an uninterpreted
> >  	literal string and MUST preserve all of its original
> >  	details. As such its public distribution is equivalent to
> >  	sending a Web browser "cookie" that is only interpreted
> >  	upon being returned to its creator.</t>

> I think the current text in the draft accurately reflects the scope and formal
> semantics of local-part.  The draft does not confront the apparent contradiction
> between "MUST BE treated as case sensitive" and "case sensitivity of mailbox
> local-parts impedes interoperability and is discouraged" in RFC 5321.

Well, this seems to me to be in pretty close agreement with what's in RFC 5321,
which of course means it has the same issues.

> Since the latter is not explicitly normative, I thought it acceptable for
> email-arch to stick with the formal view.

> If someone thinks email-arch should have different text on this topic, please
> suggest some.

My position on this is that the email-arch document is attempting to describe
the overall architecture we've standardized. It is not a place for making new
rules about the interpretation of local parts or anything else for that matter.
As such, the text that's there seems fine. If we're going to mess with this -
and in spite of the issues I'm not convinced we should - it needs to happen in
the context of RFC 5321bis, or better still, in a separate draft.

				Ned

Date: Sun, 01 Mar 2009 15:31:59 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

Folks,

[Local-part. Case sensitivity.  Globally opaque.  Where to interpret.]

I'm fixing the email-arch draft, according to the various notes that point out 
errors, confusion or poor wording.  But I'm stymied by the several notes on the 
topic of local-part, some of which discussed language or issues that seem to 
differ from what is in email-arch.

Anyhow, here's what exists now:

RFC 5321
--------

> 2.3.11. Mailbox and Address
> 
> ...the local-part MUST be
>    interpreted and assigned semantics only by the host specified in the
>    domain part of the address.

/////

> 2.4. General Syntax Principles and Transaction Model
> 
> 
>    Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
>    and extension name keywords) are not case sensitive, with the sole
>    exception in this specification of a mailbox local-part
...
>    The local-part of a mailbox MUST BE treated as case sensitive.
>    Therefore, SMTP implementations MUST take care to preserve the case
>    of mailbox local-parts.  In particular, for some hosts, the user
>    "smith" is different from the user "Smith".  However, exploiting the
>    case sensitivity of mailbox local-parts impedes interoperability and
>    is discouraged.

RFC 5322
--------

> 3.4.1. Addr-Spec Specification
> 
>    The local-part portion is a domain-dependent string.  In addresses,
>    it is simply interpreted on the particular host as a name of a
>    particular mailbox.
> 

email-arch
----------

> <t>The portion to the left of the at&nbhy;sign contains a
> 	string that is globally opaque and is called the
>  	&lt;local&nbhy;part&gt;. It is to be
>  	interpreted only by the entity specified by the address's
>  	domain name. Except as noted later in this section all
>  	other entities MUST treat the
>  	&lt;local&nbhy;part&gt; as an uninterpreted
>  	literal string and MUST preserve all of its original
>  	details. As such its public distribution is equivalent to
>  	sending a Web browser "cookie" that is only interpreted
>  	upon being returned to its creator.</t>

I think the current text in the draft accurately reflects the scope and formal 
semantics of local-part.  The draft does not confront the apparent contradiction 
between "MUST BE treated as case sensitive" and "case sensitivity of mailbox 
local-parts impedes interoperability and is discouraged" in RFC 5321.

Since the latter is not explicitly normative, I thought it acceptable for 
email-arch to stick with the formal view.

If someone thinks email-arch should have different text on this topic, please 
suggest some.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sun, 01 Mar 2009 15:58:04 +0100
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: VHLO I-D and possible 5321 nits
Sender: [email-masked]

I've tried and drawn the consequences of defining VHLO (verified 
hello) or IAGG (I'm a good guy) as an SMTP extension, as John 
suggested a while ago. The I-D is at

http://www.ietf.org/internet-drafts/draft-vesely-vhlo-00.txt

Incidentally, writing the I-D I've found a pair of possible nits for 
5321bis, which may be worth amending:

* The extension definition in section 2.2.2 (lines 534-561 in the 
numbered draft) don't mention that each extension should explicitly 
specify if it is valid on the Submission port.

* There is no IANA registry of all defined MAIL (or RCPT) parameters: 
it may become a problem for future extensions authors willing to check 
that a new parameter doesn't conflict with existing ones...