>> A mailing list is a mediator (at the User level), not a relay at the SMTP
> 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
>> 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
> 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
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.
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"
- 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
Which, if you're talking about foriegn addresses, puts you in voilation of RFC