ietf-smtp
[Top] [All Lists]

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

2009-03-05 08:01:37

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

<Prev in Thread] Current Thread [Next in Thread>