ietf-smtp
[Top] [All Lists]

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

2009-03-05 06:39:20

ned+ietf-smtp(_at_)mrochek(_dot_)com 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 ietf-smtp(_at_)imc(_dot_)org, 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 ietf-smtp(_at_)imc(_dot_)org, 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 ietf-smtp(_at_)imc(_dot_)org 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" <name(_at_)domain(_dot_)com>
    "First Last"      <--> "First Last" <first(_dot_)last(_at_)domain(_dot_)com>
    "First I. Last"   <--> "First I. Last" 
<first(_dot_)I_last(_at_)domain(_dot_)com>

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

    "OLD USER"      <--> "OLD USER" <old(_dot_)user(_at_)domain(_dot_)com>

   - 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

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